[issue10042] total_ordering stack overflow
New submission from Francesco Ricciardi : Tested with version 3.2a2. Not tested on version 2.7. The current implementation of functools.total_ordering generates a stack overflow because it implements the new comparison functions with inline operator, which the Python interpreter might reverse if "other" does not implement them. Reversing the comparison makes the interpreter call again the lambda function for comparison generating a stack overflow. Run the attached test file for an example of this behavior. -- components: Library (Lib) files: test_total_ordering.py messages: 118096 nosy: francescor priority: normal severity: normal status: open title: total_ordering stack overflow type: crash versions: Python 3.2 Added file: http://bugs.python.org/file19144/test_total_ordering.py ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering stack overflow
Francesco Ricciardi added the comment: Attached there is a solution of the problem, by implementing each comparison only with the class __xx__ and __eq__ operators. Also in the file there is a complete test suite for it. -- Added file: http://bugs.python.org/file19145/new_total_ordering.py ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Francesco Ricciardi added the comment: I think the whole issue is indeed how NotImplemented is treated. To me saying that 'not NotImplemented' is True is wrong. About the stack overflow I found there are various possible fixes, however none will nice. By definition, NotImplemented is the way that a method or operation have to signal to the interpreter that it doesn't know how to handle given operand types. IMHO, it shouldn't be possible to receive NotImplemented as operand value, and it shouldn't have a boolean value. Indeed, t should be handled as a special case by the interpreter. To go further, I am not really sure that NotImplemented should be a return value. Probably, an exception that is trapped by the interpreter when evaluating an expression would be easier to define and handle. Of course, such a change should be deeply grokked before being put in place, also because of the high impact on code that already relies on NotImplemented having a value. -- ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Francesco Ricciardi added the comment: On the one hand, it's not just a matter of total_ordering and rich comparison operators, because all user defined operators may return NotImplemented when they get types that they don't know how to handle. On the other hand, if such a decision is taken, a long path should be planned to move handling of unknown types from one way to the other. -- ___ Python tracker <http://bugs.python.org/issue10042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4621] zipfile returns string but expects binary
New submission from Francesco Ricciardi <[EMAIL PROTECTED]>:
Each entry of a zip file, as read by the zipfile module, can be accessed
via a ZipInfo object. The filename attribute of ZipInfo is a string.
However, the read method of a ZipFile object expects a binary as
argument, or at least this is what I can deduct from the following behavior:
>>> import zipfile
>>> testzip = zipfile.ZipFile('test.zip')
>>> t1 = testzip.infolist()[0]
>>> t1.filename
'tést.xml'
>>> data = testzip.read(testzip.infolist()[0])
Traceback (most recent call last):
File "", line 1, in
File "C:\Python30\lib\zipfile.py", line 843, in read
return self.open(name, "r", pwd).read()
File "C:\Python30\lib\zipfile.py", line 883, in open
% (zinfo.orig_filename, fname))
zipfile.BadZipfile: File name in directory 'tést.xml' and header
b't\x82st.xml' differ.
The test.zip file is attached as help in reproducing this error.
--
components: Library (Lib)
files: test.zip
messages: 77555
nosy: francescor
severity: normal
status: open
title: zipfile returns string but expects binary
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12319/test.zip
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4621>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4621] zipfile returns string but expects binary
Francesco Ricciardi added the comment:
If that is what is requested, then the manual entry for ZipFile.read
must be corrected, because it states:
"ZipFile.read(name[, pwd]) name is the name of the file in the
archive, or a ZipInfo object."
However, Eddie, you haven't tried what you suggested, because this is
what you would get:
>>> import zipfile
>>> testzip = zipfile.ZipFile('test.zip')
>>> t1 = testzip.infolist()[0]
>>> t1.filename
'tést.xml'
>>> data = testzip.read(t1.filename)
Traceback (most recent call last):
File "", line 1, in
File "C:\Python30\lib\zipfile.py", line 843, in read
return self.open(name, "r", pwd).read()
File "C:\Python30\lib\zipfile.py", line 883, in open
% (zinfo.orig_filename, fname))
zipfile.BadZipfile: File name in directory 'tést.xml' and header
b't\x82st.xml' differ.
___
Python tracker
<http://bugs.python.org/issue4621>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38198] Attributes of pathlib classes are not indexed in Windows help file
New submission from Francesco Ricciardi : Attributes of pathlib classes (e.g. 'stem' or 'root') cannot be searched for in Python Windows help file index. -- assignee: docs@python components: Documentation messages: 352630 nosy: docs@python, francescor priority: normal severity: normal status: open title: Attributes of pathlib classes are not indexed in Windows help file type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7683] Wrong link in HTML documentation
New submission from Francesco Ricciardi : The first page of the Python Tutorial in version 3.1 (http://docs.python.org/3.1/tutorial/index.html) has the "previous topic" link pointing to "What’s New in Python 2.0" instead of "What’s New in Python 3.1". -- assignee: georg.brandl components: Documentation messages: 97635 nosy: francescor, georg.brandl severity: normal status: open title: Wrong link in HTML documentation versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7683> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7683] Wrong link in HTML documentation
Francesco Ricciardi added the comment: As written in the description, it should point to the "What's New in Python 3.1" page, shouldn't it? -- ___ Python tracker <http://bugs.python.org/issue7683> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7690] Wrong PEP number in importlib module manual page
New submission from Francesco Ricciardi :
At the end of section 2.9.1 of the Library Reference, i.e. the introduction to
the importlib module manual page, there is the See Also box that often we can
find in the manual pages. The last PEP of the box has the title ("Using UTF-8
as the Default Source Encoding") and number 3128. Number and title collide.
I believe the title is correct, i.e. the numbe should be changed to 3120, and
the link correspondingly.
--
assignee: georg.brandl
components: Documentation
messages: 97707
nosy: francescor, georg.brandl
severity: normal
status: open
title: Wrong PEP number in importlib module manual page
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue7690>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
