[ python-Bugs-1502728 ] HP-UX shared library does not reference librt
Bugs item #1502728, was opened at 2006-06-08 10:03 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=1502728&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX shared library does not reference librt Initial Comment: When using the Python engine shared library on HP-UX, I get error messages like these: /usr/lib/dld.sl: Unresolved symbol: sem_init (code) from /usr/local/lib/libpython2.4.sl Looking a bit closer, I realize that the shared Python library does not point to the librt library where these functions are defined. And this is specific for HP-UX. The rule in Makefile.pre.in to make libpython*.so does refer to $(SHLIB). But the HP-UX specific rule to make libpython*.sl does not. I suggest $(SHLIB) is added to the command to link libpython*.sl. Or alternatively, that these two rules are merged into one, parameterized by a variable holding the .so/.sl suffix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 10:42 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=1502750&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: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Neal Norwitz (nnorwitz) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502805 ] 'with' sometimes eats exceptions
Bugs item #1502805, was opened at 2006-06-08 10:53
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=1502805&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: 6
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'with' sometimes eats exceptions
Initial Comment:
The 'with' statement eats some execeptions,
in a pattern that I haven't been able to
understand quite precisely:
>>> with os.popen('ls', 'r') as f:
... print 'hi'
... print 1/0
...
hi
ls: broken pipe
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502805&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1350060 ] built-in method .__cmp__
Bugs item #1350060, was opened at 2005-11-07 08:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: built-in method .__cmp__ Initial Comment: Bound methods of built-in objects have a strange __cmp__/__hash__ combination: they compare equal only if their __self__ are identical, but they hash based on the hash of __self__ instead of its _Py_HashPointer(). Built-in methods should consistently be based on the identity *or* the equality of __self__. For reference, regular instance methods are based on the equality. So I propose to fix built-in method objects in the same way. -- >Comment By: Armin Rigo (arigo) Date: 2006-06-08 10:57 Message: Logged In: YES user_id=4771 Checked in as r46739. -- Comment By: Armin Rigo (arigo) Date: 2006-04-21 16:41 Message: Logged In: YES user_id=4771 I've just been bitten by this problem. It's an arguably reasonable use case about why instance methods should work like immutable containers (they are immutable, after all) in the sense that equality should be structural. If nobody object I will check in a fix that makes instance methods and built-in instance methods compare their 'self' recursively. -- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:40 Message: Logged In: YES user_id=4771 Sorry, my mistake: regular instance methods behave like built-in methods. They are both based on the identity of their 'self' but use its hash to compute their own hash. This bug report is thus only about why should the hash of methods and built-in methods depend on the hash of their 'self'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 08:42 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 12:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502728 ] HP-UX shared library does not reference librt
Bugs item #1502728, was opened at 2006-06-08 08:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502728&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: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Göran Uddeborg (goeran) >Assigned to: Georg Brandl (gbrandl) Summary: HP-UX shared library does not reference librt Initial Comment: When using the Python engine shared library on HP-UX, I get error messages like these: /usr/lib/dld.sl: Unresolved symbol: sem_init (code) from /usr/local/lib/libpython2.4.sl Looking a bit closer, I realize that the shared Python library does not point to the librt library where these functions are defined. And this is specific for HP-UX. The rule in Makefile.pre.in to make libpython*.so does refer to $(SHLIB). But the HP-UX specific rule to make libpython*.sl does not. I suggest $(SHLIB) is added to the command to link libpython*.sl. Or alternatively, that these two rules are merged into one, parameterized by a variable holding the .so/.sl suffix. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 12:54 Message: Logged In: YES user_id=849994 Added $(SHLIBS) to build rule for .sl in rev 46743, 46744 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502805 ] 'with' sometimes eats exceptions
Bugs item #1502805, was opened at 2006-06-08 12:53
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502805&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: 6
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'with' sometimes eats exceptions
Initial Comment:
The 'with' statement eats some execeptions,
in a pattern that I haven't been able to
understand quite precisely:
>>> with os.popen('ls', 'r') as f:
... print 'hi'
... print 1/0
...
hi
ls: broken pipe
>>>
--
Comment By: iga Seilnacht (zseil)
Date: 2006-06-08 15:32
Message:
Logged In: YES
user_id=1326842
The bug is in the file.__exit__ method. This method is
just an alias for file.close(), with METH_VARARGS instead
of METH_NOARGS as flags. It should be instead a method
that requires three parameters, closes the file and
returns a false value if those parameters were not None
or if something went wrong while closing the file.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502805&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 08:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: Invalid Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 13:32 Message: Logged In: YES user_id=849994 The bug isn't in getargs. Format code "i" wants a C integer. Question is whether sys.setcheckinterval and perhaps dozens of other functions should be changed to accept "l". Changing to Invalid. Reverted checkin. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 12:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 10:42 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 15:39 Message: Logged In: YES user_id=38388 Reopened: the bug is still there. Note that a C integer does have 64-bits on a 64-bit Linux system :-) (unlike on a Win64 system). -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 15:32 Message: Logged In: YES user_id=849994 The bug isn't in getargs. Format code "i" wants a C integer. Question is whether sys.setcheckinterval and perhaps dozens of other functions should be changed to accept "l". Changing to Invalid. Reverted checkin. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 14:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 10:42 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 15:45 Message: Logged In: YES user_id=38388 Strike that last comment about ints haveing 64-bit. I got carried away by Python using C longs for ints. -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 15:39 Message: Logged In: YES user_id=38388 Reopened: the bug is still there. Note that a C integer does have 64-bits on a 64-bit Linux system :-) (unlike on a Win64 system). -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 15:32 Message: Logged In: YES user_id=849994 The bug isn't in getargs. Format code "i" wants a C integer. Question is whether sys.setcheckinterval and perhaps dozens of other functions should be changed to accept "l". Changing to Invalid. Reverted checkin. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 14:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 08:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 13:52 Message: Logged In: YES user_id=849994 To be sure: ints are 32-bit and longs 64-bit? -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 13:45 Message: Logged In: YES user_id=38388 Strike that last comment about ints haveing 64-bit. I got carried away by Python using C longs for ints. -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 13:39 Message: Logged In: YES user_id=38388 Reopened: the bug is still there. Note that a C integer does have 64-bits on a 64-bit Linux system :-) (unlike on a Win64 system). -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 13:32 Message: Logged In: YES user_id=849994 The bug isn't in getargs. Format code "i" wants a C integer. Question is whether sys.setcheckinterval and perhaps dozens of other functions should be changed to accept "l". Changing to Invalid. Reverted checkin. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 12:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 10:42 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 16:00 Message: Logged In: YES user_id=38388 Yes. Sorry for the confusion. ints are 32 bit and longs 64 bit on 64bit Linux (and other 64bit Unix systems). Since Python uses C longs for storing integers, sys.maxint correctly gives LONG_MAX. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 15:52 Message: Logged In: YES user_id=849994 To be sure: ints are 32-bit and longs 64-bit? -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 15:45 Message: Logged In: YES user_id=38388 Strike that last comment about ints haveing 64-bit. I got carried away by Python using C longs for ints. -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 15:39 Message: Logged In: YES user_id=38388 Reopened: the bug is still there. Note that a C integer does have 64-bits on a 64-bit Linux system :-) (unlike on a Win64 system). -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 15:32 Message: Logged In: YES user_id=849994 The bug isn't in getargs. Format code "i" wants a C integer. Question is whether sys.setcheckinterval and perhaps dozens of other functions should be changed to accept "l". Changing to Invalid. Reverted checkin. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 14:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint
Bugs item #1502750, was opened at 2006-06-08 08:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&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: Invalid Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: PyArg_ParseTuple(args, "i") and sys.maxint Initial Comment: The argument parser seems to have trouble with sys.maxint on 64-bit platforms: >>> import sys >>> sys.maxint 9223372036854775807 >>> sys.setcheckinterval(sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> sys.setcheckinterval(2**31-1) >>> sys.setcheckinterval(2**31) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum Looks like INT_MAX isn't the right value to test against. This is on AMD64, Linux2.6, gcc 3.3. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 14:11 Message: Logged In: YES user_id=849994 Okay, closing. -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 14:00 Message: Logged In: YES user_id=38388 Yes. Sorry for the confusion. ints are 32 bit and longs 64 bit on 64bit Linux (and other 64bit Unix systems). Since Python uses C longs for storing integers, sys.maxint correctly gives LONG_MAX. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 13:52 Message: Logged In: YES user_id=849994 To be sure: ints are 32-bit and longs 64-bit? -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 13:45 Message: Logged In: YES user_id=38388 Strike that last comment about ints haveing 64-bit. I got carried away by Python using C longs for ints. -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-08 13:39 Message: Logged In: YES user_id=38388 Reopened: the bug is still there. Note that a C integer does have 64-bits on a 64-bit Linux system :-) (unlike on a Win64 system). -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 13:32 Message: Logged In: YES user_id=849994 The bug isn't in getargs. Format code "i" wants a C integer. Question is whether sys.setcheckinterval and perhaps dozens of other functions should be changed to accept "l". Changing to Invalid. Reverted checkin. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 12:47 Message: Logged In: YES user_id=849994 No, INT_MAX is definitely not the right value. Changed to LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502750&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1502805 ] 'with' sometimes eats exceptions
Bugs item #1502805, was opened at 2006-06-08 10:53
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502805&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: 6
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'with' sometimes eats exceptions
Initial Comment:
The 'with' statement eats some execeptions,
in a pattern that I haven't been able to
understand quite precisely:
>>> with os.popen('ls', 'r') as f:
... print 'hi'
... print 1/0
...
hi
ls: broken pipe
>>>
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-08 14:50
Message:
Logged In: YES
user_id=849994
Good spotting! Fixed in rev. 46751.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-06-08 13:32
Message:
Logged In: YES
user_id=1326842
The bug is in the file.__exit__ method. This method is
just an alias for file.close(), with METH_VARARGS instead
of METH_NOARGS as flags. It should be instead a method
that requires three parameters, closes the file and
returns a false value if those parameters were not None
or if something went wrong while closing the file.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502805&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1495033 ] int/long assume that the buffer ends in \0 => CRASH
Bugs item #1495033, was opened at 2006-05-25 08:51
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495033&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: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: James Y Knight (foom)
Assigned to: Brett Cannon (bcannon)
Summary: int/long assume that the buffer ends in \0 => CRASH
Initial Comment:
But it doesn't, always.
>>> int(buffer('123a', 0, 3))
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for int(): 123a
Hmm...well if that works, how about this one:
>>> import array; int(buffer(array.array('c', [])))
***SEGFAULT***
Ah, there we go, a nice crasher.
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-08 10:02
Message:
Logged In: YES
user_id=357491
Rev. 46757 has the fix for 2.5 . Not backporting since it
is a big semantic change and the bug doesn't really cause
issues usually.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-26 00:02
Message:
Logged In: YES
user_id=33168
Brett, here's an easy one for ya to get started. :-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495033&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii
Bugs item #1501291, was opened at 2006-06-06 00:34
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: UnixOps (unixops1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: python/ncurses bug in 2.4.3 with extended ascii
Initial Comment:
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:
$ cat test.py
import curses
screen = curses.initscr()
screen.addstr("\x80")
screen.getch()
curses.endwin()
$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR
This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier.
To ensure that ncurses was able to display the
character, I wrote this test C program:
$ cat test.c
#include
int main()
{
initscr();
int rtn = addstr("\x80");
getch();
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}
$ gcc test.c -o test -lncurses
$ ./test
This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.
I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.
Can this be fixed in _cursesmodule.c?
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-08 19:58
Message:
Logged In: YES
user_id=21627
I doubt it can be fixed in _cursesmodule. Notice that Python
links with ncursesw now, not with ncurses anymore. There is
a bug in 2.4.3 which links, apparently incorrectly, with
panel instead of panelw. Try changing that and see whether
it helps.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii
Bugs item #1501291, was opened at 2006-06-05 16:34
Message generated for change (Comment added) made by unixops1234
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: UnixOps (unixops1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: python/ncurses bug in 2.4.3 with extended ascii
Initial Comment:
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:
$ cat test.py
import curses
screen = curses.initscr()
screen.addstr("\x80")
screen.getch()
curses.endwin()
$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR
This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier.
To ensure that ncurses was able to display the
character, I wrote this test C program:
$ cat test.c
#include
int main()
{
initscr();
int rtn = addstr("\x80");
getch();
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}
$ gcc test.c -o test -lncurses
$ ./test
This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.
I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.
Can this be fixed in _cursesmodule.c?
--
>Comment By: UnixOps (unixops1234)
Date: 2006-06-08 14:02
Message:
Logged In: YES
user_id=1534776
I tried recompiling Python with the patch from bug #1464056
that fixes the panelw linking in _curses_panel.so. It now
properly links with libpanelw instead of libpanel, but the
original problem persists. I still get "_curses.error:
addstr() returned ERR" when running the test code.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-08 11:58
Message:
Logged In: YES
user_id=21627
I doubt it can be fixed in _cursesmodule. Notice that Python
links with ncursesw now, not with ncurses anymore. There is
a bug in 2.4.3 which links, apparently incorrectly, with
panel instead of panelw. Try changing that and see whether
it helps.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503157 ] "/".join() throws OverflowError
Bugs item #1503157, was opened at 2006-06-08 22:58 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=1503157&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: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: "/".join() throws OverflowError Initial Comment: I noticed a regression in string.join() behaviour: Running under Python 2.4 works: $ python2.4 Python 2.4.4c0 (#2, Apr 22 2006, 22:39:06) [GCC 4.0.3 (Debian 4.0.3-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) u'/2' >>> Running under Python 2.5 SVN build fails: $ python2.5 Python 2.5a2 (trunk:46757, Jun 8 2006, 22:20:31) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) Traceback (most recent call last): File "", line 1, in OverflowError: join() is too long for a Python string >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503157 ] "/".join() throws OverflowError
Bugs item #1503157, was opened at 2006-06-09 05:58 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&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: 5 Submitted By: Wummel (calvin) >Assigned to: Tim Peters (tim_one) Summary: "/".join() throws OverflowError Initial Comment: I noticed a regression in string.join() behaviour: Running under Python 2.4 works: $ python2.4 Python 2.4.4c0 (#2, Apr 22 2006, 22:39:06) [GCC 4.0.3 (Debian 4.0.3-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) u'/2' >>> Running under Python 2.5 SVN build fails: $ python2.5 Python 2.5a2 (trunk:46757, Jun 8 2006, 22:20:31) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) Traceback (most recent call last): File "", line 1, in OverflowError: join() is too long for a Python string >>> -- >Comment By: Hye-Shik Chang (perky) Date: 2006-06-09 07:40 Message: Logged In: YES user_id=55188 That occurrs when join sequence includes a zero-length unicode object after Tim's r46084. I attached a patch but can't sure that it's correct fix yet. :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503157 ] "/".join() throws OverflowError
Bugs item #1503157, was opened at 2006-06-08 16:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&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: 5 Submitted By: Wummel (calvin) Assigned to: Tim Peters (tim_one) Summary: "/".join() throws OverflowError Initial Comment: I noticed a regression in string.join() behaviour: Running under Python 2.4 works: $ python2.4 Python 2.4.4c0 (#2, Apr 22 2006, 22:39:06) [GCC 4.0.3 (Debian 4.0.3-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) u'/2' >>> Running under Python 2.5 SVN build fails: $ python2.5 Python 2.5a2 (trunk:46757, Jun 8 2006, 22:20:31) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) Traceback (most recent call last): File "", line 1, in OverflowError: join() is too long for a Python string >>> -- >Comment By: Tim Peters (tim_one) Date: 2006-06-08 20:34 Message: Logged In: YES user_id=31435 Fudge -- sorry about that! Your fix is fine. Adding two non-negative signed integers of the same width indeed overflows if and only if the computed result is negative. I was hallucinating when I imagined that a 0 result also indicated overflow (something related to that is a correct fast test when dealing with unsigned integers, but we're not here). -- Comment By: Hye-Shik Chang (perky) Date: 2006-06-08 18:40 Message: Logged In: YES user_id=55188 That occurrs when join sequence includes a zero-length unicode object after Tim's r46084. I attached a patch but can't sure that it's correct fix yet. :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] 'make install' fails on OS X 10.4 when running compileall
Bugs item #1503294, was opened at 2006-06-08 20:20 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=1503294&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: 'make install' fails on OS X 10.4 when running compileall Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
