[ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Bugs item #1520864, was opened at 2006-07-11 23:21 Message generated for change (Comment added) made by sadrejeb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) -- Comment By: Sadruddin Rejeb (sadrejeb) Date: 2006-09-04 09:08 Message: Logged In: YES user_id=26911 I have the impression that the bug has only been partially solved, i.e. in 2.5c1, singleton tuples don't get unfoled in list comprehensions. Python 2.5c1 (r25c1:51305, Sep 4 2006, 10:15:09) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [(1,), (2,)] Same example in Python 2.4.3: Python 2.4.3 (#1, Jul 25 2006, 11:53:03) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [1, 2] -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-12 05:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-12 02:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Bugs item #1520864, was opened at 2006-07-11 23:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Open >Resolution: None Priority: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-04 10:05 Message: Logged In: YES user_id=849994 You're right. Attached patch fixes this. -- Comment By: Sadruddin Rejeb (sadrejeb) Date: 2006-09-04 09:08 Message: Logged In: YES user_id=26911 I have the impression that the bug has only been partially solved, i.e. in 2.5c1, singleton tuples don't get unfoled in list comprehensions. Python 2.5c1 (r25c1:51305, Sep 4 2006, 10:15:09) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [(1,), (2,)] Same example in Python 2.4.3: Python 2.4.3 (#1, Jul 25 2006, 11:53:03) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [1, 2] -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-12 05:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-12 02:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1551669 ] Wrong link to unicode database
Bugs item #1551669, was opened at 2006-09-04 01:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yevgen Muntyan (emuntyan) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong link to unicode database Initial Comment: http://docs.python.org/lib/module-unicodedata.html has a link to unicode database (second paragraph). The link there is http://www.unicode.org/Public/UNIDATA/UnicodeData.html, it's broken. The correct one is probably http://www.unicode.org/Public/UNIDATA/UnicodeData.txt (there are lot of files in http://www.unicode.org/Public/UNIDATA/) -- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-04 14:30 Message: Logged In: YES user_id=38388 I think the documentation should link to the new standard URL: http://www.unicode.org/Public/UNIDATA/UCD.html and then point out that Python 2.4 shipped with version 3.2 and Python 2.5 will ship with 4.1. -- Comment By: George Yoshida (quiver) Date: 2006-09-04 07:14 Message: Logged In: YES user_id=671362 Given that Python 2.4 uses 3.2 database, we should link to http://www.unicode.org/Public/3.2-Update/UnicodeCharacterDatabase-3.2.0.html As for 2.5 and trunk(both using 4.1.0 database), they're linked to http://www.unicode.org/Public/4.1.0/ucd/UCD.html Any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551669&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1549574 ] Pdb parser bug
Bugs item #1549574, was opened at 2006-08-30 13:46
Message generated for change (Comment added) made by isandler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pdb parser bug
Initial Comment:
>>> import pdb
>>> pdb.set_trace()
--Return--
> (1)()->None
(Pdb) p ";;"
*** SyntaxError: SyntaxError('EOL while scanning
single-quoted string', ('', 1, 1, '"'))
*** SyntaxError: EOL while scanning single-quoted
string (, line 1)
Still present in trunk:51513M
--
Comment By: Ilya Sandler (isandler)
Date: 2006-09-04 14:42
Message:
Logged In: YES
user_id=971153
For the record, this behaviour is explicitly documented in
pdb docs.
from:
http://www.python.org/doc/current/lib/debugger-commands.html
"""Multiple commands may be entered on a single line,
separated by ";;" No intelligence is applied to
separating the commands; the input is split at the first
";;" pair, even if it is in the middle of a quoted string."""
So should this be considered a bug?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1550938 ] from . import bug
Bugs item #1550938, was opened at 2006-09-02 02:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 9 Submitted By: ganges master (gangesmaster) >Assigned to: Thomas Wouters (twouters) Summary: from . import bug Initial Comment: >>> from . import foo Traceback (most recent call last): File "", line 1, in ValueError: Relative importpath too deep it should raise ImportError, as the module does not exist. there's nothing wrong with the path being too deep. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 18:26 Message: Logged In: YES user_id=33168 Thomas, could you take a look at this patch. I'm not sure it's correct. I thought you had some reasons for these ValueErrors (unless it was diff code). -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-03 00:10 Message: Logged In: YES user_id=849994 See attached patch. I couldn't find a mention of this ValueError in the PEP or the docs, so changing it to ImportError and giving better error messages looks like the way to go. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-02 11:49 Message: Logged In: YES user_id=33168 Can you provide a patch to fix it? I'll make a decision partly based on the patch. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-02 02:21 Message: Logged In: YES user_id=849994 Agreed. Can we fix this for 2.5? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550938&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1551432 ] __unicode__ breaks for exception class objects
Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552304 ] UnixCCompiler runtime_library_dir uses -R instead of -Wl, -R
Bugs item #1552304, was opened at 2006-09-04 19:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: TFKyle (tfkyle) Assigned to: Nobody/Anonymous (nobody) Summary: UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R Initial Comment: in some cases where gcc is named oddly (i686-pc-linux-gnu-g++/i686-pc-linux-gnu-gcc in this case, gentoo names them like this) UnixCCompiler.runtime_library_dir_option will return -R instead of -Wl,-R, there seems to be a check in there already for gcc/g++ though it only checks against the first 3 characters. perhaps a better approach would be to check "gcc" in compiler or "g++" in compiler or something similar -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552304 ] UnixCCompiler runtime_library_dir uses -R instead of -Wl, -R
Bugs item #1552304, was opened at 2006-09-04 19:47 Message generated for change (Comment added) made by tfkyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: TFKyle (tfkyle) Assigned to: Nobody/Anonymous (nobody) Summary: UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R Initial Comment: in some cases where gcc is named oddly (i686-pc-linux-gnu-g++/i686-pc-linux-gnu-gcc in this case, gentoo names them like this) UnixCCompiler.runtime_library_dir_option will return -R instead of -Wl,-R, there seems to be a check in there already for gcc/g++ though it only checks against the first 3 characters. perhaps a better approach would be to check "gcc" in compiler or "g++" in compiler or something similar -- >Comment By: TFKyle (tfkyle) Date: 2006-09-04 20:26 Message: Logged In: YES user_id=1065959 dup of http://sourceforge.net/tracker/index.php?func=detail&aid=1254718&group_id=5470&atid=305470 , sorry I should've looked harder before submitting -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552304&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1550714 ] itertools.tee raises SystemError
Bugs item #1550714, was opened at 2006-09-01 12:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Neal Norwitz (nnorwitz) Summary: itertools.tee raises SystemError Initial Comment: >>> from itertools import tee >>> tee([],-1) Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:32: bad argument to internal function This should be a ValueError instead. (Still present in trunk:51513M) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:31 Message: Logged In: YES user_id=33168 Committed revision 51722. for 2.5 This also affects 2.4 if anyone wants to backport. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:58 Message: Logged In: YES user_id=33168 Thanks for the report! Committed revision 51684. 2.6 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-01 19:26 Message: Logged In: YES user_id=33168 this needs a check. i've got a patch that i'll check in in a bit. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1551432 ] __unicode__ breaks for exception class objects
Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) Assigned to: Nobody/Anonymous (nobody) Summary: __unicode__ breaks for exception class objects Initial Comment: PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5. >>> unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__unicode__' of 'exceptions.BaseException' object needs an argument It should work analogously to str: >>> str(ImportError) "" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Bugs item #1520864, was opened at 2006-07-11 16:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 21:01 Message: Logged In: YES user_id=33168 Thanks for spotting this. Let us know if you find any more bugs. Well, I'm glad Georg and I came up with the same basic patch (thanks Georg!). I had worked it up prior to seeing his version here. It's also the same fix for the for loops. Committed revision 51729. (2.6) Committed revision 51730. (2.5) -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-04 03:05 Message: Logged In: YES user_id=849994 You're right. Attached patch fixes this. -- Comment By: Sadruddin Rejeb (sadrejeb) Date: 2006-09-04 02:08 Message: Logged In: YES user_id=26911 I have the impression that the bug has only been partially solved, i.e. in 2.5c1, singleton tuples don't get unfoled in list comprehensions. Python 2.5c1 (r25c1:51305, Sep 4 2006, 10:15:09) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [(1,), (2,)] Same example in Python 2.4.3: Python 2.4.3 (#1, Jul 25 2006, 11:53:03) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> l = [(1,), (2,)] >>> print [x for x, in l] [1, 2] -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 22:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-11 19:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows
Bugs item #1545668, was opened at 2006-08-23 20:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jack Howarth (jwhowarth) >Assigned to: Tim Peters (tim_one) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: //* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 21:04 Message: Logged In: YES user_id=33168 Tim checked in fixes for 2.6 (r51716), 2.5 (r51711), and 2.4. -- Comment By: David Hopwood (dhopwood) Date: 2006-08-26 16:24 Message: Logged In: YES user_id=634468 The correct patch is the one that uses if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x) The one that uses (unsigned int)x will break some 64-bit platforms where int != long. -- Comment By: Tim Peters (tim_one) Date: 2006-08-26 13:33 Message: Logged In: YES user_id=31435 Boosted priority to 8 since it was brought up on python-dev as a suggested 2.5 release-blocker. The patch in the first comment looks fine, if a release manager wants to apply it. Python 2.4 surely has the same "issue". -- Comment By: Tim Peters (tim_one) Date: 2006-08-26 13:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). -- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 08:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 08:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can fin
[ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python
Bugs item #1541697, was opened at 2006-08-16 18:51
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recently introduced sgmllib regexp bug hangs Python
Initial Comment:
Looks like revision 47154 introduced a regexp that
hangs Python (Ctrl-C won't kill the process, CPU usage
sits near 100%) under some circumstances. A test case
is attached (sgmllib.html and hang_sgmllib.py).
The problem isn't seen if you read the whole file (or
nearly the whole file) at once. But that doesn't make
it a non-bug, AFAICS.
I'm not sure what the problem is, but presumably the
relevant part of the patch is this:
+starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*('
+r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
+
r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)[EMAIL PROTECTED]'
+
r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?'
+r')*\s*/?\s*(?=[<>])')
The patch attached to bug 1515142 (also from Sam Ruby
-- claims to fix a regression introduced by his recent
sgmllib patches, and has not yet been applied) does NOT
fix the problem.
--
Comment By: George Yoshida (quiver)
Date: 2006-08-17 21:55
Message:
Logged In: YES
user_id=671362
Slimmed down test case is attached.(The regex pattern in
question is used)
FYI, r47154 is backported to 2.4 branch(r47155).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Bugs item #1521947, was opened at 2006-07-13 10:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 22:12 Message: Logged In: YES user_id=33168 Tim, how do you feel about backporting now? (Not sure if your opinion changed based on the other bug.) That and I'm cleaning out my mailbox, so I don't have to look at this any more. :-) -- Comment By: Tim Peters (tim_one) Date: 2006-07-27 14:00 Message: Logged In: YES user_id=31435 Neal, as I said in the checkin comment, I expect it's no less likely that we'll get screwed by goofy platform values for LONG_MIN and LONG_MAX than that we /got/ screwed by an "over ambitious" compiler optimizing away "result == -result", so I'm not sure backporting is a good idea. I stuck in an assert that might fail if a platform is insane; if there are no reports of that assert triggering, then I'd feel better about backporting the change. -- Comment By: Matt Fleming (splitscreen) Date: 2006-07-27 03:49 Message: Logged In: YES user_id=1126061 Fixed for me on NetBSD -current AMD64, gcc 4.1.2 -- Comment By: Nick Maclaren (nmm) Date: 2006-07-27 01:31 Message: Logged In: YES user_id=42444 Fixed for me, too, and the code looks solid. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 21:48 Message: Logged In: YES user_id=33168 I reopened this bug as it still affects 2.4. Tim's fix should be backported. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 21:35 Message: Logged In: YES user_id=33168 Tim's fix corrected the problem on amd64 gentoo linux with gcc 4.1.1. -- Comment By: Tim Peters (tim_one) Date: 2006-07-26 18:16 Message: Logged In: YES user_id=31435 Made a non-heroic effort to repair this in rev 50855, but have no platform on which it could make any difference (and apparently no Python buildbot test platform cares either) . Would be nice if someone who has such a platform could check against current Python trunk. -- Comment By: Nick Maclaren (nmm) Date: 2006-07-17 02:20 Message: Logged In: YES user_id=42444 Yes, this is a duplicate of 1521726. The compiler people's answer is correct, and mystrtoul.c is incorrect. LONG_MIN has been in C since C90, so should be safe, but its value may not always be what you expect. However, the code breakage is worse that just that test, and there are the following 3 cases of undefined behaviour: 1) Casting and unsigned long to long above LONG_MAX. 2) That test. 3) result = -result. The fix should be to make result unsigned long, and check the range BEFORE any conversion. Nothing else is safe. It is a matter of taste whether to include a fiddle for the number that can be held only when negated - I wouldn't, and would let that
[ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self)
Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: �iga Seilnacht (zseil) >Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Bugs item #1521947, was opened at 2006-07-13 13:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) -- >Comment By: Tim Peters (tim_one) Date: 2006-09-05 01:21 Message: Logged In: YES user_id=31435 Well, I deliberately avoided using LONG_MIN in the patches for the other bug, so that should answer your question ;-) If someone wants to take the small risk of backporting it, fine by me -- it's not going to break on Windows, and if it doesn't break on your box either ... -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 01:12 Message: Logged In: YES user_id=33168 Tim, how do you feel about backporting now? (Not sure if your opinion changed based on the other bug.) That and I'm cleaning out my mailbox, so I don't have to look at this any more. :-) -- Comment By: Tim Peters (tim_one) Date: 2006-07-27 17:00 Message: Logged In: YES user_id=31435 Neal, as I said in the checkin comment, I expect it's no less likely that we'll get screwed by goofy platform values for LONG_MIN and LONG_MAX than that we /got/ screwed by an "over ambitious" compiler optimizing away "result == -result", so I'm not sure backporting is a good idea. I stuck in an assert that might fail if a platform is insane; if there are no reports of that assert triggering, then I'd feel better about backporting the change. -- Comment By: Matt Fleming (splitscreen) Date: 2006-07-27 06:49 Message: Logged In: YES user_id=1126061 Fixed for me on NetBSD -current AMD64, gcc 4.1.2 -- Comment By: Nick Maclaren (nmm) Date: 2006-07-27 04:31 Message: Logged In: YES user_id=42444 Fixed for me, too, and the code looks solid. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 00:48 Message: Logged In: YES user_id=33168 I reopened this bug as it still affects 2.4. Tim's fix should be backported. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 00:35 Message: Logged In: YES user_id=33168 Tim's fix corrected the problem on amd64 gentoo linux with gcc 4.1.1. -- Comment By: Tim Peters (tim_one) Date: 2006-07-26 21:16 Message: Logged In: YES user_id=31435 Made a non-heroic effort to repair this in rev 50855, but have no platform on which it could make any difference (and apparently no Python buildbot test platform cares either) . Would be nice if someone who has such a platform could check against current Python trunk. -- Comment By: Nick Maclaren (nmm) Date: 2006-07-17 05:20 Message: Logged In: YES user_id=42444 Yes, this is a duplicate of 1521726. The compiler people's answer is correct, and mystrtoul.c is incorrect. LONG_MIN has been in C since C90, so should be safe, but its value may not always be what you expect. However, the code breakag
[ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self)
Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: �iga Seilnacht (zseil) Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 05:22 Message: Logged In: YES user_id=849994 Attaching my patch here. Neal: PyObject_GC_TRACK is called in PyType_GenericAlloc, which is used for exceptions since the tp_alloc slot is 0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self)
Bugs item #1542051, was opened at 2006-08-17 08:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: �iga Seilnacht (zseil) Assigned to: Neal Norwitz (nnorwitz) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 23:09 Message: Logged In: YES user_id=33168 Yeah, this makes sense. Georg, can you come up with a test for this? (It's ok if it's only triggered with -R flag.) This also needs a NEWS entry. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-04 22:22 Message: Logged In: YES user_id=849994 Attaching my patch here. Neal: PyObject_GC_TRACK is called in PyType_GenericAlloc, which is used for exceptions since the tp_alloc slot is 0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
