[issue46730] Please consider mentioning property without setter when an attribute can't be set
Alexander added the comment: Indeed, the error message does not help to identify the problem. Moreover, it collides with similar errors in namedtuple and DynamicClassAttribute which may lead to even more confusion. I made a draft patch that could help with it (https://github.com/Alex-Blade/cpython/commit/06df3a72dfe462c8fe4eac60dce0ef059b1738f8), but I have a concern related to backwards compatibility (that's why no PR). I don't really understand if according to PEP 387 a change in an exception message should be considered compatibility breaking? -- nosy: +Alex-Blade ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46730] Please consider mentioning property without setter when an attribute can't be set
Change by Alexander : -- keywords: +patch pull_requests: +29472 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31311 ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46730] Please consider mentioning property without setter when an attribute can't be set
Alexander added the comment: Added the PR. (I have signed the CLA, just haven't got the response yet, doesn't affect the discussion I guess) -- ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13082] Can't open new window in python
New submission from Alexander : When I try to open a new window in python to actually type a program and not just make single python instructions (this is while running on IDLE), python stops working and I have to force quit -- assignee: ronaldoussoren components: Macintosh messages: 144711 nosy: Reason2Rage, ronaldoussoren priority: normal severity: normal status: open title: Can't open new window in python type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue13082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Alexander added the comment: > It sounds like the early consensus on python-dev is that html5 support is a > good thing. Yeah... But wait another 8 years untill these guys decides that there is enough tests and other cool stuff. -- ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12759] "(?P=)" input for Tools/scripts/redemo.py throw an exception
New submission from Alexander : Run: python /Tools/scripts/redemo.py Enter "(?P=)" in entry field. See unhandled exception occures. There is special text field in example for such cases. It should be used to show error messages, not a console. -- components: Demos and Tools files: redemo.py.png messages: 142186 nosy: fredeom priority: normal severity: normal status: open title: "(?P=)" input for Tools/scripts/redemo.py throw an exception type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file22908/redemo.py.png ___ Python tracker <http://bugs.python.org/issue12759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12759] "(?P=)" input for Tools/scripts/redemo.py raises unnhandled exception
Alexander added the comment: I would like to make a patch. -- ___ Python tracker <http://bugs.python.org/issue12759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Alexander added the comment: This is small patch for related bug issue9577 which actually is not related to this bug. -- nosy: +friday Added file: http://bugs.python.org/file21045/cdata_patch.diff ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Alexander added the comment: And this patch fix the both bugs in more elegant way -- Added file: http://bugs.python.org/file21046/cdata_patch.diff ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream
Alexander added the comment: Hi, This issue was also confirmed by a Verge3D user (Python 3.7.7) https://www.soft8soft.com/topic/export-gltf-error -- nosy: +alexkowel ___ Python tracker <https://bugs.python.org/issue33935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25297] max_help_position is not works in argparse library
New submission from Alexander:
Hi colleagues I have the code (max_help_position is 2000):
formatter_class=lambda prog: argparse.HelpFormatter(prog,
max_help_position=2000)
parser = argparse.ArgumentParser(formatter_class=formatter_class)
subparsers = parser.add_subparsers(title="Commands", metavar="")
cmd_parser = subparsers.add_parser('long_long_long_long_long_long_long',
help='- jksljdalkjda',
formatter_class=formatter_class)
args = parser.parse_args(['-h'])
print args
Result:
we have
optional arguments:
-h, --help show this help message and exit
Commands:
long_long_long_long_long_long_long
- jksljdalkjda
small - descr
instead
optional arguments:
-h, --help show this help message and exit
Commands:
long_long_long_long_long_long_long - jksljdalkjda
small - descr
The code:
class MyFormatter(argparse.HelpFormatter):
def __init__(self, prog):
super(MyFormatter, self).__init__(prog, max_help_position=2000,
width=2000)
self._max_help_position = 2000
self._action_max_length += 4
got same result.
The strings like:
formatter_class = lambda prog: argparse.HelpFormatter(prog,
max_help_position=2000, width=2000)
formatter_class = lambda prog: argparse.HelpFormatter(prog,
max_help_position=1000, width=2000)
formatter_class = lambda prog: argparse.HelpFormatter(prog,
max_help_position=2000, width=1000)
got same result: we always have new line after command.
--
components: Library (Lib)
messages: 252093
nosy: morden2k
priority: normal
severity: normal
status: open
title: max_help_position is not works in argparse library
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue25297>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25297] max_help_position is not works in argparse library
Alexander added the comment: Problem also described on http://stackoverflow.com/questions/3215/ -- ___ Python tracker <http://bugs.python.org/issue25297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task
Alexander Hartl added the comment: I just found this PR when a task of mine spontaneously crashed with a "Task was destroyed but it is pending" in the middle of program execution. I think the warning should be added to `loop.create_task()`, too. Not sure if `loop.call_later()` and `loop.call_at()` are also affected? I think it would be a good idea to add the fire-and-forget example that @bernat gave. At the moment, stackoverflow is full of suggestions to just use `create_task()` in this case, ignoring the return value. Actually, I think it is a true shortcoming that asyncio doesn't provide a fire-and forget functionality by itself. -- nosy: +alexhartl ___ Python tracker <https://bugs.python.org/issue44665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Golubev Alexander added the comment: Any reasons the PR still not merged? -- nosy: +Fat-Zer ___ Python tracker <https://bugs.python.org/issue24053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1244] Error on 'raise' does not show correct line number and Traceback message
New submission from Alexander Shirokov:
Please run debracket.py
It halts immediately and the message
explains the problem.
Regards
Alex
--
files: debracket.py
messages: 56265
nosy: alexander.shirokov
severity: normal
status: open
title: Error on 'raise' does not show correct line number and Traceback message
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1244>
__#!/usr/bin/python
import os, sys, xml.dom.minidom
a = '\(\(\(1/\(4959476121600 a1^7 a2^7 r^2\)\)\((-r^14 + 14 a1^13 heavi[a1-5*a2-r^2]^2 )\)\)\)'
# Convert the brackets into XML tokens
a = a.replace(r'\(','\n')
a = a.replace(r'\)','\n')
a = a.replace('(','\n')
a = a.replace(')','\n')
# Enclose the document
a = '\n'+a+'\n\n'
# Parse the XML document
dom = xml.dom.minidom.parseString(a)
def convert_node_to_strlist(dom):
try:
#print "tagName=",dom.tagName
dom.tagName
except:
None
a = []
for d in dom.childNodes:
if d.nodeType == d.TEXT_NODE:
t = str(d.data).strip()
if len(t):
a += [t]
else:
a += convert_node_to_strlist(d)
return a
m = convert_node_to_strlist(dom)
#print m
if len(m) != 3 and len(m) != 4: raise
def extract_nom_denom(m):
if len(m) == 3:
if m[0] == '1/':
nom = m[2]
denom = m[1]
elif m[1] == '/':
nom = m[0]
denom = m[2]
else:
raise
elif len(m) == 4:
if m[0] == '-' and m[1] == '1/':
denom = m[0]+m[2]
nom = m[3]
else:
raise
return nom, denom
nom,denom = extract_nom_denom(m)
a = nom
a = a.replace(' + ', '\n+')
a = a.replace(' - ', '\n-')
# Make sure the first token is a signed integer coefficient
q = []
a0 = a.split('\n')
for a in a0:
if len(a) == 0: continue
#print "<<", a
b = a.split()
test_int = 1
#print "|"
try:
c = int(b[0])
except:
test_int = 0
if test_int:
repl = '%+d %s' % ( c, ' '.join(b[1:]))
else:
w = b[0]
if w[0] == '+':
c = 1
w = ''.join(list(w[1:]))
elif w[0] == '-':
c = -1
w = ''.join(list(w[1:]))
else:
c = 1
repl = '%+d %s %s' % ( c, w, ' '.join(b[1:]))
#print '>>', repl
q += [repl]
a = '\n'.join(q)
token='heavi'
# Pad the powers
pad=2
b0 = []
a0 = a.split('\n')
for l in a0:
#print 'l=',l
o0 = []
l0 = l.split()
#print 'l0=',l0
for w in l0:
s = w.split('^')
# This is an ordinary word
if len(s) == 1:
o = w
# This is a power
elif len(s) == 2:
bs = s[0]
pw = int(s[1])
if bs.find(token) == 0:
if pw == 0: raise
o = bs
else:
pw = "%0*d" % ( pad, pw )
o = bs+'^'+pw
else:
print "A. Shirokov: The error occurs with 'raise' in line 154"
print " but Python does not report the line number correctly, by only saying 'File \"./debracket.py\", line 91'"
print " The stack of error messages may have some problem"
print ""
raise
o0 += [o]
b0 += [ ' '.join(o0) ]
a = '\n'.join(b0);
print "Done3"
fh = file(fb,"w")
fh.write(a)
fh.close()
print "Done4"
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1244] Error on 'raise' does not show correct line number and Traceback message
Alexander Shirokov added the comment:
Dear Georg,
Thank you for reply. Sorry, I thought it was a real bug.
Best Regards,
Alex
On Mon, 8 Oct 2007, Georg Brandl wrote:
>
> Georg Brandl added the comment:
>
> The raise statement without any arguments re-raises the last raised
> exception, complete with traceback, see
> http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement.
>
> Therefore your usage of the raise statement is incorrect; you should
> always use
>
> raise SomeException("some message")
>
> --
> nosy: +georg.brandl
> resolution: -> invalid
> status: open -> closed
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1244>
> __
>
--
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1244>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8822] datetime naive and aware types should have a well-defined definition that can be cross-referenced
Alexander Belopolsky added the comment: On Mon, Sep 12, 2011 at 4:30 PM, Jakob Malm wrote: .. > I created a patch with the revised wording. Your patch seems to reflow the entire paragraph which makes it hard to review and if applied will appear as a bigger change than it is. Can you regenerate the patch so that it does not have whitespace only diffs? Thanks. -- nosy: +Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue8822> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8822] datetime naive and aware types should have a well-defined definition that can be cross-referenced
Alexander Belopolsky added the comment: On Mon, Sep 12, 2011 at 4:36 PM, anatoly techtonik wrote: .. > 5. Mention the fact: By default all objects are "naive", by definition, > because they don't have any > TZ information, and there are no classes in stdlib that provide this info > (tzclass implemetations) This is simply wrong: in py3k we have the timezone class that implements tzinfo interface. > 6. Answer the questions: How to make non-naive object? How to detect if > object of naive or aware? I would go one step further: we should review the examples in datetime module documentation and use aware datetime objects unless the point of the example is to demonstrate a naive datetime. We should also replace examples that use sample implementations of tzinfo to use the timezone class. -- ___ Python tracker <http://bugs.python.org/issue8822> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8822] datetime naive and aware types should have a well-defined definition that can be cross-referenced
Alexander Belopolsky added the comment: -There are two kinds of date and time objects: "naive" and "aware". This +Date and time objects are either "naive" or "aware". This Shouldn't we say "datetime and time" instead of "date and time"? There is no tzinfo attribute in date objects. -- ___ Python tracker <http://bugs.python.org/issue8822> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8822] datetime naive and aware types should have a well-defined definition that can be cross-referenced
Alexander Belopolsky added the comment: On Thu, Sep 15, 2011 at 4:17 PM, anatoly techtonik wrote: .. > Does that mean that if aware `datetime` is converted to `date` and > then back, the tzinfo information is lost and object implicitly > becomes naive? Yes, but one cannot convert "back" from date to datetime. To get a datetime object, one needs to combine date and time and tzinfo is attached to the time component. > In this case it should mentioned IMO. I agree. The following is not really intuitive: -> None In order to preserve tzinfo, one has to preserve it when extracting the time component: -> datetime.timezone.utc -- ___ Python tracker <http://bugs.python.org/issue8822> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13029] test_strptime fails on Windows 7 french
Alexander Belopolsky added the comment: Isn't this a duplicate of #10653? In any case, this looks like a windows only issue, so I cannot move it further. Would be interested in resolution, though. Thanks for making me nosy. -- nosy: +ocean-city ___ Python tracker <http://bugs.python.org/issue13029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10254] unicodedata.normalize('NFC', s) regression
Changes by Alexander Belopolsky : -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue10254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue12729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10254] unicodedata.normalize('NFC', s) regression
Alexander Belopolsky added the comment: This new data does not crash Python 2.7.2, so I assume the issue has been fixed. Re-closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue10254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13171] Bug in tempfile module
New submission from Alexander Steppke :
The tempfile module shows strange behavior under certain conditions. This might
lead to data leaking or other problems.
The test session looks as follows:
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tmp = tempfile.TemporaryFile()
>>> tmp.read()
''
>>> tmp.write('test')
>>> tmp.read()
'P\xf6D\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ [ommitted]'
or similar behavior in text mode:
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tmp = tempfile.TemporaryFile('w+t')
>>> tmp.read()
''
>>> tmp.write('test')
>>> tmp.read()
'\x00\xa5\x8b\x02int or long, hash(a) is used instead.\ni\x10 [ommitted]'
>>> tmp.seek(0)
>>> tmp.readline()
'test\x00\xa5\x8b\x02int or long, hash(a) is used instead.\n'
This bug seems to be triggered by calling tmp.read() before tmp.seek(). I am
running Python 2.7.2 on Windows 7 x64, other people have reproduced the problem
on Windows XP but not under Linux or Cygwin (see also
http://stackoverflow.com/questions/7757663/python-tempfile-broken-or-am-i-doing-it-wrong).
Thank you for looking into this.
Alexander
--
components: Library (Lib), Windows
messages: 145477
nosy: Alexander.Steppke
priority: normal
severity: normal
status: open
title: Bug in tempfile module
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13171] Bug in tempfile module
Alexander Steppke added the comment:
Hi David,
I followed your suggestion and tried to reproduce the problem without the
tempfile module. It turns out that is indeed an underlying issue. I am not sure
what the root cause is but now this is even a bigger problem: read() returns
information from some file/memory that it was never intended to access.
The session looks similar to the tempfile session:
>>> tmp = open('tmp', 'w+t')
>>> tmp.read()
''
>>> tmp.write('test')
>>> tmp.read()
'hp\'\x02\xe4\xb9>7\x80\x88\x81\x02\x01\x00\x00\x00\x00\x00\x00\x00\x12\x00\x00\
x00\xe86(\x02p\x11\x8d\x02\x01\x00\x00\x00@\xfd)\x02\xe7Y\x9aN\x01\x00\x00\x00\x
00\x00\x00\x00\x14\x00\x00\x00\x087(\x02\x00\x00\x00\x00\xe9Y\x0b\xa2\x00\x93+\x
02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x9b,\x02\x02\x00\x00\x00\xe06(\x02\xc0W5\
At the moment the bug could only be reproduced using CPython 2.7.1 on Windows
XP and Windows 7.
Alexander
--
___
Python tracker
<http://bugs.python.org/issue13171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13171] Bug in file.read(), can access unknown data.
Changes by Alexander Steppke : -- components: +IO title: Bug in tempfile module -> Bug in file.read(), can access unknown data. ___ Python tracker <http://bugs.python.org/issue13171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13171] Bug in file.read(), can access unknown data.
Alexander Steppke added the comment: Additionally after calling tmp.close() the file 'tmp' contains the string 'test', which is followed by about 4kB of binary data similar to the previous output of tmp.read(). -- ___ Python tracker <http://bugs.python.org/issue13171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13171] Bug in file.read(), can access unknown data.
Alexander Steppke added the comment:
Thank you for the update Victor. It seems to me that this is exactly the same
issue.
At the moment the current documentation says
(http://docs.python.org/library/stdtypes.html#bltin-file-objects):
"Note: This function is simply a wrapper for the underlying fread() C function,
and will behave the same in corner cases, such as whether the EOF value is
cached."
This is a hint to the current behavior but I would not expect from this that
file.read() can return any kind of data, if used directly after file.write().
Maybe one could include a link or a snippet of the C standard which states that
one shall not do this:
"When a file is opened with update mode ('+' as the second or third character
in the above list of mode argument values), both input and output may be
performed on the associated stream. However, output shall not be directly
followed by input without an intervening call to the fflush function or to a
file positioning function (fseek, fsetpos, or rewind), and input shall not be
directly followed by output without an
intervening call to a file positioning function, unless the input operation
encounters end-of-file."
(from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, page 272)
--
___
Python tracker
<http://bugs.python.org/issue13171>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13260] distutils and cross-compiling the extensions
New submission from Alexander Myodov : I was recently trying to cross-compile several extensions (host: Linux, target: Win32) using mingw-gcc, and noticed that there is quite a little amount of changes needed to distutils code to at least make proper win32-compabible modules. Some of them require pretty noticeable functionality changes to distutils (like, adding a new option) thus they are unlikely a target for 2.7 anymore (though with some luck, any person who wants to follow my way and do cross-compilation, may just subclass the existing code). But some others are obvious bugs, and their fixes may still be useful for users stuck at 2.7. 1. (This is dubious but still is related to the problem, and was required to build some of the modules). "--include-dirs" and "--library-dirs" options to build_ext command support multiple paths separated by os.pathsep. For some reason (which I may be unaware of) "--libraries" option doesn't. A tiny fix just adds this support. 2. (more obvious issue) get_msvcr() function in distutils/cygwincompiler.py tries to guess the C runtime library which the target extension should link to. To do that, it tests the Python where the setup.py is *running* for what library it was linked to. But when the compilation target is Win32 but the compilation host is Linux, the hosts's Python won't contain such information. In this case, this function will return None. The result then gets assigned to self.dll_libraries (in an instance of CygwinCCompiler or Mingw32CCompiler), and gets used in a context which implies it is always an iterable (libraries.extend(self.dll_libraries)). These changes, together with altering or subclassing Mingw32CCompiler to use a different compiler name (like, "i586-mingw32msvc-gcc" instead of "gcc"), make it possible to cross-compile a number of extensions which were non-compileable before. -- assignee: tarek components: Distutils files: distutils.patch keywords: patch messages: 146340 nosy: amyodov, eric.araujo, tarek priority: normal severity: normal status: open title: distutils and cross-compiling the extensions versions: Python 2.7 Added file: http://bugs.python.org/file23514/distutils.patch ___ Python tracker <http://bugs.python.org/issue13260> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13268] assert
New submission from Alexander Myodov : The extended version of assert statement has a strange violation of documented behaviour. According to the http://docs.python.org/reference/simple_stmts.html#the-assert-statement, "assert expression1, expression2" should be equivalent to "if __debug__: if not expression1: raise AssertionError(expression2)". Nevertheless, it is not so for the following scenario: class A(object): def __str__(self): return "str" def __unicode__(self): return "unicode" def __repr__(self): return "repr" expression1 = False expression2 = (A(),) That is, when expression2 is a single-item tuple, assert statement prints the str-evaluation of the item itself, rather than of the tuple. This occurs in 2.x branch only, seems fixed in 3.x, and it would be great to have it backported for consistency. -- messages: 146434 nosy: amyodov priority: normal severity: normal status: open title: assert type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue13268> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13268] assert statement violates the documentation
Changes by Alexander Myodov : -- title: assert -> assert statement violates the documentation ___ Python tracker <http://bugs.python.org/issue13268> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13305] datetime.strftime("%Y") not consistent for years < 1000
Alexander Belopolsky added the comment: I am not sure this can be fixed without distributing our own implementation of strftime. See issue 3173. -- dependencies: +external strftime for Python? ___ Python tracker <http://bugs.python.org/issue13305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13556] When tzinfo.utcoffset is out-of-bounds, the exception message is misleading
Alexander Belopolsky added the comment: Is 3.3 message better? >>> datetime.now(tz=X()) Traceback (most recent call last): File "", line 1, in ValueError: offset must be a timedelta strictly between -timedelta(hours=24) and timedelta(hours=24). In 2.7, the message is indeed misleading: >>> datetime.now(tz=X()) Traceback (most recent call last): File "", line 1, in ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439 I am not sure fixing this in 2.x is worth the trouble, but I would consider improving the message in 3.x by adding information about the actual offset. I vaguely remember that there was a reason for leaving that info out in 3.x. -- assignee: -> belopolsky stage: -> needs patch versions: +Python 3.4 ___ Python tracker <http://bugs.python.org/issue13556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
Alexander Belopolsky added the comment: I'll try to give this a more thorough review by the end of the week. For now, just a nit-pick, but _calc_julian_from_V jumped at me as a really odd name. Either "iso_to_julian" or "julian_from_iso" would be much clearer. The patch also needs tests and documentation. -- assignee: -> belopolsky stage: needs patch -> patch review ___ Python tracker <http://bugs.python.org/issue12006> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
Alexander Belopolsky added the comment:
On Wed, May 25, 2011 at 6:28 PM, Ashley Anderson wrote:
>
> .. I agree that '_calc_julian_from_V' is a bit strange. I was mimicking a
> similar helper function's
> name ('_calc_julian_from_U_or_W'), but perhaps that is no defense.
This is a perfect defense. Local consistency usually trumps global
conventions. I only looked at the patch and did not see that other
function. Please don't change the name.
--
___
Python tracker
<http://bugs.python.org/issue12006>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
Alexander Belopolsky added the comment: On Thu, May 26, 2011 at 9:44 AM, R. David Murray wrote: .. > Documentation is in the Doc subdirectory of a checkout, and is in the form of > *.rst files. Modify the appropriate .rst file, More specifically, strftime/strptime directives are listed in a table inside the the Doc/library/datetime.rst file. Note that the narrative before the table says that only C89 standard codes are listed and I don't think %V and %u are standard. Check if there is an applicable standard for them - C99 and POSIX define more codes that C89. -- ___ Python tracker <http://bugs.python.org/issue12006> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
Alexander Belopolsky added the comment: On Thu, May 26, 2011 at 12:07 PM, Ashley Anderson wrote: > I think this should be fixed by implementing the %G directive (ISO year, > which is present in strftime) as well. Correct. -- ___ Python tracker <http://bugs.python.org/issue12006> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8887] “pydoc str” works but not “pydoc str.translate”
Alexander Belopolsky added the comment: The patch looks good. A nit-pick: +if len(parts) > 0: Since *parts* is a list, the above can be replaced with simply "if parts:". Also, it seems to me that the new code may produce an AttributeError when given invalid name, but locate() function is supposed to return None instead. I wouder if it would be possible to reuse the try/except logic ing the "if module" clause and simply do something like if module: object = module else: object = builtins for part in parts[n:]: try: object = getattr(object, part) except AttributeError: return None return object -- ___ Python tracker <http://bugs.python.org/issue8887> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8887] “pydoc str” works but not “pydoc str.translate”
Alexander Belopolsky added the comment: On Fri, May 27, 2011 at 12:23 PM, Éric Araujo wrote: > .. I’ll add tests and see if I can reproduce what you’re hinting at (it would > be helpful > if you could give examples of invalid names: full dotted names, method names, > class names?). I did not try to apply your patch yet, but what I had in mind was misspelled names like "str.transkate". -- ___ Python tracker <http://bugs.python.org/issue8887> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Jun 3, 2011 at 3:57 PM, Martin v. Löwis wrote: .. > I suggest that rather than using composite time stamps, decimal.Decimal is > used to represent high-precision time in Python. I support this idea in theory, but as long as decimal is implemented in Python, os module should probably expose a low level (tuple-based?) interface and a higher level module would provide Decimal-based high-precision time. BTW, what is the status of cdecimal? -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Jun 3, 2011 at 6:13 PM, Martin v. Löwis wrote: .. >> I support this idea in theory, but as long as decimal is implemented >> in Python, os module should probably expose a low level (tuple-based?) >> interface and a higher level module would provide Decimal-based >> high-precision time. > > Can you explain why you think so? I fail to see the connection. One reason is the desire to avoid loading Python module from a C-module. I understand that this ship has already left the port with larger and larger portions of stdlib being implemented in Python, but doing that in a basic module such as os (or rather posix) is likely to cause more problems than what we have in other similar situation. For example, strptime is implemented in a Python module loaded by time and datetime implemented in C. This works, but at a cost of extreme trickery in the test suit and similar problems encountered by sophisticated applications. As far as I remember, some multi-threding issues have never been resolved. -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on Pipe()
Alexander Myodov added the comment: Sorry for being a little bit slow to respond... No I was not able to come up with a testcase that could generate this problem in a reproducible way on any Windows box I had. This problem sometimes occured on various OS versions, being probably a Windows oof configuration problem rather than the problem of the Python code itself. Nevertheless, changing it as I described above didn't cause any adverse side effects, at least for me. -- ___ Python tracker <http://bugs.python.org/issue9099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Jun 3, 2011 at 6:52 PM, Martin v. Löwis wrote: .. >> One reason is the desire to avoid loading Python module from a >> C-module. > > This desire is indeed no guidance for Python development; the opposite > is the case. Can you elaborate on this? I did notice the current trend of mixing software layers and welcoming circular dependencies in Python stdlib, but I am not sure this is a good thing. In the good old times imports inside functions where frowned upon. (And for many good reasons.) Imports from inside C functions seem to be even worse. Tricks like this greatly reduce understandability of the code. The import statements at the top of the module tell a great deal about what the module can and cannot do. When modules can be imported at will as a side-effect of innocuous looking functions (time.strptime is my personal pet peeve), analysis of the programs becomes much more difficult. > The only exception may be bootstrapping issues, which I > claim are irrelevant in this case. It is hard to tell without attempting an implementation, but my intuition is exactly the opposite. I believe parts of the import mechanism have been implemented in Python and it seems to me that os.stat() may need to be available before decimal can be imported. -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12286] float('nan') breaks sort() method on a list of floats
Alexander Belopolsky added the comment: This is actually a duplicate of issue7915. I don't think there is nothing we can do to improve the situation. In fact discussion at #11949 ends with a +0 from Mark Dickinson to issue a warning whenever nans participate in order comparison. Discussion at #11986 ends without any clear consensus. I think we should keep at least one issue on this topic open rather than close new issues as invalid by referring users to older closed issues that don't explain why silently producing nonsensical results is better than raising an error or issuing a warning. -- resolution: invalid -> duplicate ___ Python tracker <http://bugs.python.org/issue12286> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Sun, Jun 26, 2011 at 8:23 AM, Martin v. Löwis wrote: .. >> I understand that it is an issue of the datetime module. Can it be >> solved, or is there a design issue in the module? > > It's an inherent flaw of broken-down time. Don't use that > representation; Not quite. This is an inherent flaw of expressing time in time zones with DST adjustments. Yet even if there was no DST, using local time for file timestamps is inconvenient because you cannot easily compare timestamps across systems. This is similar to using locale encoding instead of Unicode. However this flaw does not affect timestamps expressed in UTC. UTC is sort of Unicode (or maybe UTF-8) of timezones. > the only true representation of point-in-time > is "seconds since the epoch, as a real number" (IMO, of course). Mathematically speaking, broken down UTC timestamp is equivalent to "seconds since the epoch, as a real number". There are relatively simple mathematical formulas (defined by POSIX) that convert from one representation to the other and back. As long as "real number" and broken down structure contain the sub-second data to the same precision, the two representations are mathematically equivalent. In practice one representation may be more convenient than the other. (This is somewhat similar to decimal vs. binary representation of real numbers.) When performance is an issue "real numbers" may be more optimal than broken down structures, but in most applications datetime/timedelta objects are easier to deal with than abstract numbers. > Broken-down time has the advantage of being more easily human-readable, > but is (often deliberately) incomplete (with the notion of partial > time stamps) and text representations are difficult to parse. > I am not sure I understand this. ISO timestamps are not more difficult to parse than decimal numbers. I don't think Python supports partial timestamps and certainly partial timestamps would not be appropriate for representing os.stat() fields. -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating extension module
Changes by Alexander Slesarev : -- nosy: +nuald ___ Python tracker <http://bugs.python.org/issue9878> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12694] crlf.py script from Tools doesn't work with Python 3.2
New submission from Alexander Belchenko : Attempt to use crlf.py script from standard windows install always fail with traceback: C:\Python32\Tools\Scripts>C:\Python32\python.exe crlf.py 2to3.py Traceback (most recent call last): File "crlf.py", line 23, in main() File "crlf.py", line 12, in main if '\0' in data: TypeError: Type str doesn't support the buffer API C:\Python32\Tools\Scripts>C:\Python32\python.exe -V Python 3.2 -- messages: 141650 nosy: bialix priority: normal severity: normal status: open title: crlf.py script from Tools doesn't work with Python 3.2 versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky added the comment: The code review links point to something weird. Victor, can you upload your patch for review? My first impression is that your patch does not accomplish much beyond replacing some literal expressions with macros. What I wanted to achieve with this issue was to enable writing code without #ifdef Py_UNICODE_WIDE branches. In your patch these branches seem to still be there and in fact it appears that new code is longer than the old one (I am not sure why, but I see more '+' than '-'s in your patch.) -- ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Alexander Belopolsky added the comment: > Return the local time as a floating point number > expressed in seconds since the epoch. No. Seconds since the epoch is neither local nor UTC. It is just an elapsed number of seconds since an agreed upon time called the "epoch". I would say: "Return the current time as a floating point number representing the number of seconds elapsed since the epoch." Suggestions for a shorter formulation that would not change the meaning are welcome. Maybe "Return the number of seconds elapsed since the epoch as a floating point number." -- ___ Python tracker <http://bugs.python.org/issue12758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime
Alexander Belopolsky added the comment: > i.e. it appears that replace() applies the TZ offset to a naive datetime > object effectively assuming it is local time rather than un-timezoned > (which is what the docs imply to me) I don't understand your issue. The replace method does not assume anything, it just replaces whatever fields you specify with new values. You can replace tzinfo just like any other field, year, month, day, etc while preserving the other fields. I think this is fairly well documented. I think what you are looking for is the astimezone() method which, however may not work well on naive datetime instances simply because a naive instance may be ambiguous in presence of DST. However, if you start with an aware UTC datetime, you should be able to use astimezone() to convert to any local TZ. -- ___ Python tracker <http://bugs.python.org/issue12750> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.strftime('%s') should respect tzinfo
Alexander Belopolsky added the comment:
> it would appear the problem lies with strftime()
Yes, strftime('%s') ignores tzinfo at the moment. This is not a bug. Support
for '%s' format code is incidental and not documented in Python.
Nevertheless I think this is a good feature request. I am changing the title
to make it more explicit.
--
components: +Extension Modules
keywords: +easy
stage: committed/rejected -> needs patch
title: datetime.datetime how to correctly attach a timezone to an existing
naive datetime -> datetime.strftime('%s') should respect tzinfo
versions: -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue12750>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12757] undefined name in doctest.py
Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue12757> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12772] fractional day attribute in datetime class
Alexander Belopolsky added the comment: You can easily get the fractional day value using existing functionality: >>> from datetime import * >>> (datetime(2011,8,15,18,30) - datetime(2011,8,13,12,0)) / timedelta(1) 2.27083335 >>> (datetime(2011,8,15,18,30) - datetime(1970,1,1)) / timedelta(1) 15201.77083334 In some sense this request is a duplicate of issue2736. -- assignee: -> belopolsky nosy: +belopolsky resolution: -> rejected stage: -> committed/rejected status: open -> pending ___ Python tracker <http://bugs.python.org/issue12772> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12831] 2to3 and integer division
New submission from Alexander Rødseth : Hi, 2to3 is a great tool, but I think I found one case it doesn't catch, which is this change: -half = self.maxstars / 2 +half = self.maxstars // 2 "/ 2" is an integer division, so it should be "// 3" in Python 3. Thanks. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 142879 nosy: alexander256 priority: normal severity: normal status: open title: 2to3 and integer division type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12831> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12831] 2to3 and integer division
Alexander Rødseth added the comment: Even though it's hard to cover every case, it should be possible in quite a few cases: self.maxstars = 4 half = self.maxstars / 2 -- ___ Python tracker <http://bugs.python.org/issue12831> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x
New submission from Alexander Dutton : If there are any broken symlinks in the same directory as a setup.py when e.g. sdist is run, findall() will fall over when attempting to os.stat() the symlink: Traceback (most recent call last): File "setup.py", line 81, in run _sdist.run(self) File "/usr/lib/python2.6/distutils/command/sdist.py", line 144, in run self.get_file_list() File "/usr/lib/python2.6/distutils/command/sdist.py", line 238, in get_file_list self.filelist.findall() File "/usr/lib/python2.6/distutils/filelist.py", line 47, in findall self.allfiles = findall(dir) File "/usr/lib/python2.6/distutils/filelist.py", line 297, in findall stat = os.stat(fullname) OSError: [Errno 2] No such file or directory: 'debian/tmp/usr/share/somepath/somesymlink' Solutions would include replacing the call to os.stat() with one to os.lstat() (probably backwards-incompatible), or trying one and then the other. This bug is present in Pythons 2.6.6 (Debian 6.0.2) and 2.7 (Fedora 14). When attempting to reproduce in Python 3.1.2 (on Fedora) no error was encountered. However, looking at distutils/filelist.py, the same unadulterated call to os.stat() is present. I'll presume that for whatever reason distutils in Py3.1.2 never has cause to stat my broken symlink. -- assignee: tarek components: Distutils messages: 143399 nosy: Alexander.Dutton, eric.araujo, tarek priority: normal severity: normal status: open title: distutils.filelist.findall() fails on broken symlink in Py2.x type: behavior versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue12885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x
Alexander Dutton added the comment: I've come across it as I'm creating a Debian package of the Python package in the same tree — I'm happy to be told this is a Bad Idea and that they should be in different places. The broken symlinks are relative and in debian/tmp, and will point to locations provided by other Debian packages once my package is installed in the right location. FWIW, I'm getting round it at the moment by walking the directory tree and removing the files is os.path.islink(filename) and not os.path.exists(os.path.join(filename, os.readlink(filename))). I'm happy to provide tests and a patch if necessary. -- ___ Python tracker <http://bugs.python.org/issue12885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 4:50 PM, Larry Hastings wrote: .. > I think a pair of integers is a poor API. It ties the value of the > fractional part to nanoseconds. What happens > when a future filesystem implements picosecond resolution? If history repeats, struct stat will grow new st_xtimesuperspec fields, st_xtimespec will become a macro expanding to st_xtimesuperspec.tv_picosec and we will get a request to support that in os.stat(). I don't see why this conflicts with stat_result.st_xtimespec returning a (sec, nsec) tuple. If we will ever have to support higher resolution, stat_result will grow another member with a (sec, picosec) or whatever will be appropriate value. > And then later goes to femtoseconds? Same thing. > Or some platform chooses another divisor (2**32)? Unlikely, but C API will dictate Python API if this happens. -- nosy: +Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 5:22 PM, Alexander Belopolsky wrote: .. > If history repeats, struct stat will grow new st_xtimesuperspec > fields, st_xtimespec will become a macro expanding to > st_xtimesuperspec.tv_picosec On the second thought, this won't work. To support higher resolution will need to supply 3 fields in st_xtimesuperspec: tv_sec and tv_nsec packed in st_xtimespec (say tv_timespec) and new tv_psec field. st_xtime will now be st_xtimesuperspec.tv_timespec.tv_sec and st_xtimespec will be a new macro expanding to st_xtimesuperspec.tv_timespec. The rest of my argument still holds. -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 5:42 PM, Larry Hastings wrote: .. > How is this superior to using either Decimal or float128? It is explicit about the units of time used. If we use named tuples and retain C API field names, stat_result.tv_atimespec.tv_sec will clearly mean number of seconds and stat_result.tv_atimespec.tv_nsec will clearly mean nanoseconds. Even if we use plain tuples, the convention will be obvious to someone familiar with C API. And familiarity with C API is expected from users of os module, IMO. Those who need higher level abstractions should use higher level modules. -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] Expose nanosecond precision from system calls
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 6:18 PM, Larry Hastings wrote: .. > I've drawn an ASCII table summarizing the proposals so far. You did not mention "closely matches C API" as an upside. -- ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue665761] reduce() masks exception
Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file18472/issue665761-py3k.diff ___ Python tracker <http://bugs.python.org/issue665761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy
Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: -Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue2443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy
Alexander Belopolsky added the comment: I updated the patch for 3.x. I agree that using va_copy where available makes sense, but let's leave this type of improvements for the future. -- Added file: http://bugs.python.org/file18477/issue2443-py3k.diff ___ Python tracker <http://bugs.python.org/issue2443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy
Alexander Belopolsky added the comment: Committed in r83949. -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue2443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9573] imporing a module that executes fork() raises RuntimeError
Alexander Belopolsky added the comment: > How can this be worked around, short of placing the fork() > in the main module? Why wouldn't you place the fork() call in a function? -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue9573> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9573] imporing a module that executes fork() raises RuntimeError
Alexander Belopolsky added the comment: On Wed, Aug 11, 2010 at 10:56 PM, Alex Roitman wrote: > > Alex Roitman added the comment: > > I can place it in a function. But if I execute that function from anything > other than main > module, the fork() will be called while import lock is held, one way or > another. It will just > happen in another module. So what? This discussion is now off-topic for the python bug tracker. Please ask questions on how to use python in an appropriate forum such as python-list. The problem you have uncovered only occurs if fork() is called *during* module import. If you place fork() in a function, it will not be called when you import the module or the function, - only when you call the function. -- ___ Python tracker <http://bugs.python.org/issue9573> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9573] importing a module that executes fork() raises RuntimeError
Changes by Alexander Belopolsky : -- nosy: -belopolsky ___ Python tracker <http://bugs.python.org/issue9573> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9573] importing a module that executes fork() raises RuntimeError
Changes by Alexander Belopolsky : -- Removed message: http://bugs.python.org/msg113654 ___ Python tracker <http://bugs.python.org/issue9573> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9574] complex does not parse strings containing decimals
Alexander Belopolsky added the comment:
Current behavior is also consistent with that of fractions:
>>> Fraction("1/2")
Fraction(1, 2)
>>> Fraction("1 / 2")
Traceback (most recent call last):
..
ValueError: Invalid literal for Fraction: '1 / 2'
I am -1 on this RFE. At most, this can be clarified in the docs.
Allowing whitespace involves too much uncertainly. Would you allow any white
space or just chr(0x20)? End-of-line or tab in complex numbers is most likely
a typo and should be flagged. What about more exotic unicode whitespace such
as chr(0x00A0) or chr(0x2009)? Allow one or any number of whitespace
characters?
Users who need a more powerful parser can use eval() or simply remove spaces
from their strings before converting them to numbers.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue9574>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9574] complex does not parse strings containing decimals
Alexander Belopolsky added the comment:
I did some experimentation and found some inconsistency between int and complex:
>>> int('\xA11')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa1 in position 0: invalid
start byte
but
>>> complex('\xA11')
Traceback (most recent call last):
File "", line 1, in
ValueError: complex() arg is a malformed string
The int behavior is probably a bug that should be reported separately.
--
___
Python tracker
<http://bugs.python.org/issue9574>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9578] int() raises UnicodeDecodeError when called on malformed string
New submission from Alexander Belopolsky :
>>> int('\xA11')
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa1 in position 0: invalid
start byte
This is inconsistent with other number types' behavior:
>>> float(b'\xA1')
Traceback (most recent call last):
File "", line 1, in
ValueError: could not convert string to float: �
--
messages: 113694
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
status: open
title: int() raises UnicodeDecodeError when called on malformed string
___
Python tracker
<http://bugs.python.org/issue9578>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2281] Enhanced cPython profiler with high-resolution timer
Alexander Belopolsky added the comment: Can someone post a diff against current py3k? I would like to take a look, but the files attached to this issue seem to be more than a year old. -- ___ Python tracker <http://bugs.python.org/issue2281> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8912] `make patchcheck` should check the whitespace of .c/.h files
Alexander Belopolsky added the comment: Note directly related to this issue, but untabify.py fails on files that contain non-ascii characters. For example: $ ./python.exe Tools/scripts/untabify.py Modules/_heapqmodule.c Traceback (most recent call last): ... (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe7 in position 173: invalid continuation byte I am not sure what relevant C standard has to say about using non-ascii characters in comments, but the checking tool should not fail with a traceback in such situation. -- ___ Python tracker <http://bugs.python.org/issue8912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
New submission from Alexander Belopolsky : For example: $ ./python.exe Tools/scripts/untabify.py Modules/_heapqmodule.c Traceback (most recent call last): ... (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe7 in position 173: invalid continuation byte I am not sure what relevant C standard has to say about using non-ascii characters in comments, but the checking tool should not fail with a traceback in such situation. -- components: Demos and Tools messages: 113849 nosy: belopolsky priority: normal severity: normal status: open title: untabify.py fails on files that contain non-ascii characters type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7962] Demo and Tools need to be tested and pruned
Changes by Alexander Belopolsky : -- dependencies: +untabify.py fails on files that contain non-ascii characters ___ Python tracker <http://bugs.python.org/issue7962> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
Changes by Alexander Belopolsky : -- nosy: +eric.araujo ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8912] `make patchcheck` should check the whitespace of .c/.h files
Alexander Belopolsky added the comment: I opened issue9598 for the untabify bug. For the purposes of source checking, I believe non-ascii characters should be disallowed in python C source code. According to my understanding of C89 standard, interpretation of characters outside of the basic character set is implementation and locale dependent. -- ___ Python tracker <http://bugs.python.org/issue8912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1982] Feature: extend strftime to accept milliseconds
Changes by Alexander Belopolsky : -- resolution: -> out of date stage: unit test needed -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue1982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue665761] reduce() masks exception
Alexander Belopolsky added the comment: Committed to py3k in r84098. Accepting this change for py3k was an easy decision to make because zip and map already behave this way in 3.x. I am inclined to reject this for 2.7, however. While I agree that this is a bug, fixing it has a potential of breaking users' code. I also note that for zip and map, 2.7 users can switch to izip and imap which don't have this problem. Arguably, switching to izip and imap in new code is a good idea regardless of this issue. While there is no similar work-around for reduce, I don't think this bug is important enough to introduce backward incompatible change in the stable series. -- status: open -> pending ___ Python tracker <http://bugs.python.org/issue665761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1581183] pickle protocol 2 failure on int subclass
Changes by Alexander Belopolsky : -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue1581183> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue998998] pickle bug - recursively memoizing class?
Changes by Alexander Belopolsky : -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue998998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8983] Docstrings should refer to help(name), not name.__doc__
Alexander Belopolsky added the comment: Committed in r84106. I left the __init__ docstring issue unresolved because it is orthogonal to the name.__doc__ vs. help(name) issue here. With redundant help(type(x)), the meaning of the docstring is not changed. I am leaving docstrings on magic methods question for a separate issue. -- resolution: -> accepted stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue8983> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets
Alexander Belopolsky added the comment: Can someone post a script demonstrating the proposed feature? Is "clones of clones" issue mentioned by OP resolved in the latest patch? Given that nobody commented on this issue for 7 years, I am skeptical about the utility of this feature. -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue734176> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1100942] Add datetime.time.strptime and datetime.date.strptime
Alexander Belopolsky added the comment: Is anyone still interested in moving this forward? -- ___ Python tracker <http://bugs.python.org/issue1100942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524938] PEP MemoryError with a lot of available memory gc not called
Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file18568/unnamed ___ Python tracker <http://bugs.python.org/issue1524938> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1545463] New-style classes fail to cleanup attributes
Alexander Belopolsky added the comment: This is superseded by issue812369, but as a stop-gap measure, I don't see any downside of applying gc-import.patch. -- assignee: -> belopolsky ___ Python tracker <http://bugs.python.org/issue1545463> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Alexander Belopolsky added the comment: > Is there any reason not to include the strftime formatting codes > in the docstrings of time.strftime and time.strptime? I believe the reason is that time.strftime behavior is platform dependent, so "man strftime" is likely to produce more relevant documentation than "pydoc time.strftime". Python manual <http://docs.python.org/library/time.html?#time.strftime> lists ANSI C codes, but warns that "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C." It is likely that there are platforms where ANSI C subset does not behave in a fully compliant manner. -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Alexander Belopolsky added the comment: > there are even two websites dedicated to these options: > http://strftime.org/ ... Note the source at one of these sites: "Source: Python’s strftime documentation." :-) -- ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
Alexander Belopolsky added the comment: > If untabify fails because a file has an incorrect encoding, is it really > a problem in untabify? This is a developer’s tool, so getting a > traceback here seems okay to me. I disagree. I think we should use this opportunity to clarify preferred encoding for C language source files in python and make untabify produce meaningful diagnostic in case of encoding errors. As a matter of policy, I see two possibilities: 1. Restrict C sources to 7-bit ASCII. (A pedantic reading of ANSI C standard would probably suggest even more restricted character set, but practically, I don't think 7-bit ASCII in C comments is likely to cause problems for any tools. 2. Require UTF-8 encoding for non-ASCII characters. Given that this is the default for python source code, it is likely that tools that are used for python development can handle UTF-8. My vote is for #1. Display of non-ascii characters is still not universally supported and they are likely to be clobbered when diffs are copied in e-mails etc. -- ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
Alexander Belopolsky added the comment: > I wouldn’t want to see names of authors/contributors mangled > in the source. This is a reason to write names in ASCII. While Latin-1 is a grey area because most of it's characters look familiar to English-speaking developers, I don't think you will easily recognize my name if I write it in Cyrillic and even if you do, chances are you would not be able to search for it. On the other hand, everyone who uses e-mail is likely to have a preferred ASCII spelling of his/her name. -- ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
Alexander Belopolsky added the comment: >From IRC: Me: UTF-8 was not strictly valid in ANSI C comments, so it is a bug in untabify to assume UTF-8 in C files. Merwok: Works for me. I am lowering the priority because it looks like untabify does not fail on the current code base. I'll follow up on python-dev to find out whether ASCII or UTF-8 should be enforced by untabify. -- assignee: -> belopolsky priority: normal -> low ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
Alexander Belopolsky added the comment: On Tue, Sep 7, 2010 at 8:08 PM, Éric Araujo wrote: .. > Why would it be the job of untabify to report invalid non-ASCII characters in > C files? > Since untabify works by loading C code as text, it has to assume some encoding. Failing with uncaught decode error (as it currently does on non UTF-8 source) is not very user friendly. For example, the diagnostic does not report the position of the offending character and does not explain how to fix the source. -- ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9598] untabify.py fails on files that contain non-ascii characters
Alexander Belopolsky added the comment: On Tue, Sep 7, 2010 at 8:31 PM, Éric Araujo wrote: .. > My real question was: Shouldn’t this be a VCS hook instead of untabify’s job? > (or in addition to untabify if you insist) > Yes, VCS hook makes sense (and may almost eliminate the need to handle invalid bytestreams in untabify). The hard question is still the same, though: are non-ascii characters allowed in python C code? My answer is "no". -- ___ Python tracker <http://bugs.python.org/issue9598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9811] strftime strips '%' from unknown format codes on OS X
Alexander Belopolsky added the comment: > I think there have been some rumblings about writing our own strftime Yes, see issue #3173. Another related issue is #9650 which discusses how to properly document strftime codes. -- ___ Python tracker <http://bugs.python.org/issue9811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1475397] time.asctime_tz, time.strftime %z %C
Alexander Belopolsky added the comment:
Would issue9527 address your request? Note that datetime.strftime already
supports %z:
>>> from datetime import *
>>> datetime.now(timezone.utc).strftime('%c %z')
'Mon Sep 13 13:43:19 2010 +'
(I assume you meant to write %c, not %C.)
--
assignee: -> belopolsky
dependencies: +Add aware local time support to datetime module
___
Python tracker
<http://bugs.python.org/issue1475397>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9323] trace.py bug with the main file being traced
Alexander Belopolsky added the comment: > The full path *could* be easily passed, but I think we should > address this problem from regrtest.py's side. I disagree. There may be other scripts that rely on __main__.__file__ being an absolute path and we cannot require everyone to change their assumptions to make their scripts traceable. It looks like absolute path assumption was added by Florent in r78723 (r78719 in trunk). Florent, I would like to hear from you before deciding how to proceed. See also issue #7712. -- nosy: +flox ___ Python tracker <http://bugs.python.org/issue9323> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky added the comment: Hmm, it looks like patches 5 and 6 lost the fix for the class name issue. I'll check if I can merge in patch 4. -- ___ Python tracker <http://bugs.python.org/issue9315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9315] The trace module lacks unit tests
Alexander Belopolsky added the comment: Committed with minor changes in r84777. Eli, please keep lines under 80 characters. Leaving the issue open pending py3k port. -- resolution: -> accepted stage: patch review -> committed/rejected ___ Python tracker <http://bugs.python.org/issue9315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
