From noreply at sourceforge.net Thu Jun 1 00:27:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 15:27:35 -0700 Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3 Message-ID: Bugs item #1494314, was opened at 2006-05-24 09:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-05-31 18:27 Message: Logged In: YES user_id=31435 akuchling: No, poll() is not part of the Windows socket API. ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 17:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 14:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 10:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 10:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 10:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 09:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your current limit. Ulimits are enforced by the Linux kernel and can likely be configured system-wide in /etc/sysctl.cfg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 From noreply at sourceforge.net Thu Jun 1 06:24:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 21:24:13 -0700 Subject: [ python-Bugs-1498638 ] tp_alloc for subtypes of PyComplex_Type is not called Message-ID: Bugs item #1498638, was opened at 2006-05-31 22:24 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=1498638&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: Travis Oliphant (teoliphant) Assigned to: Nobody/Anonymous (nobody) Summary: tp_alloc for subtypes of PyComplex_Type is not called Initial Comment: In the function complex_subtype_from_c_complex in the file complexobject.c, the allocation routine for the subtype is not called. This causes memory management problems if the sub-type does not use the Python memory manager. The fix is to make the following change: { PyObject *op; - op = PyType_GenericAlloc(type, 0); + op = type->tp_alloc(type, 0); if (op != NULL) ((PyComplexObject *)op)->cval = cval; return op; Attched is an example module and script illustrating what can go wrong along with a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498638&group_id=5470 From noreply at sourceforge.net Thu Jun 1 08:02:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 23:02:38 -0700 Subject: [ python-Bugs-1496032 ] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha Message-ID: Bugs item #1496032, was opened at 2006-05-27 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=1496032&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: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha Initial Comment: Program received signal SIGFPE, Arithmetic exception. 0x0000000160418568 in bu_double (p=0x12049d29c "", f=0x0) at / house/etrepum/src/python-46462/Modules/_struct.c:219 (this is actually due to _PyFloat_Unpack8) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-31 23:02 Message: Logged In: YES user_id=33168 Try adding the -mieee flag when compiling. That should fix the problem. It looks like we only set this for OSF platforms. It should probably be set for all Alpha platforms. See: http://mail.python.org/pipermail/python-dev/2006-March/063219.html ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-27 09:12 Message: Logged In: YES user_id=139309 More fun in test_long Program received signal SIGFPE, Arithmetic exception. 0x000000012003972c in float_richcompare (v=0x120397080, w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387 387 else if (!Py_IS_FINITE(i)) { ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-27 09:12 Message: Logged In: YES user_id=139309 More fun in test_long Program received signal SIGFPE, Arithmetic exception. 0x000000012003972c in float_richcompare (v=0x120397080, w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387 387 else if (!Py_IS_FINITE(i)) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&group_id=5470 From noreply at sourceforge.net Thu Jun 1 10:27:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 01:27:51 -0700 Subject: [ python-Bugs-1498638 ] tp_alloc for subtypes of PyComplex_Type is not called Message-ID: Bugs item #1498638, was opened at 2006-06-01 04:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498638&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: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Nobody/Anonymous (nobody) Summary: tp_alloc for subtypes of PyComplex_Type is not called Initial Comment: In the function complex_subtype_from_c_complex in the file complexobject.c, the allocation routine for the subtype is not called. This causes memory management problems if the sub-type does not use the Python memory manager. The fix is to make the following change: { PyObject *op; - op = PyType_GenericAlloc(type, 0); + op = type->tp_alloc(type, 0); if (op != NULL) ((PyComplexObject *)op)->cval = cval; return op; Attched is an example module and script illustrating what can go wrong along with a patch. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 08:27 Message: Logged In: YES user_id=849994 Fixed in rev. 46586. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498638&group_id=5470 From noreply at sourceforge.net Thu Jun 1 15:20:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:20:36 -0700 Subject: [ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability Message-ID: Bugs item #1456209, was opened at 2006-03-22 15:47 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&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: Nobody/Anonymous (nobody) Summary: dictobject.c:dictresize() vulnerability Initial Comment: We thought we squashed the last of the modify-the-dict-from-a-custom-eq kind of bugs long ago. Too bad. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-01 13:20 Message: Logged In: YES user_id=4771 Fixed by patch #1497053. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-03-22 16:32 Message: Logged In: YES user_id=4771 The cause of the bug is that if oldtable == mp->ma_smalltable then pure Python code can mangle with mp->ma_smalltable while it is being walked on. A simple fix would be to always make a copy of the oldtable if it is mp->ma_smalltable (not only if oldtable == newtable). Attached a more efficient fix, which should also make dict resizing somehow faster. It requires yet another version of the lookup algorithm, though. It's a very simple version that assumes that all items are different and the dict contains no dummy entries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 From noreply at sourceforge.net Thu Jun 1 15:22:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:22:11 -0700 Subject: [ python-Bugs-1275608 ] dict key comparison swallows exceptions Message-ID: Bugs item #1275608, was opened at 2005-08-29 10:30 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&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: Michael Hudson (mwh) Summary: dict key comparison swallows exceptions Initial Comment: This is an old one that has just biten again and cost a lot of debugging time again: the dict lookup function swallows all errors during key comparison. This is bad in itself, but if the current stack depth is just wrong then *any* comparison will raise a RuntimeError and lookup will pretend that the dictionary is essentially empty. The attached sample program shows this and crashes with a KeyError instead of a RuntimeError. While at the C level there is a basic compatibility problem involved (PyDict_GetItem() not allowed to raise any exception -- see http://thread.gmane.org/gmane.comp.python.devel/62427), I think it should be possible to improve the situation on the Python interface. Unless someone points me to something I missed, I plan to come up with a patch that changes the internal dict functions (including lookdict()) to let exceptions pass through, and have the exceptions swallowed only by the PyDict_*() API functions that require it. The possible (remote) incompatibility here is existing code relying on the exceptions being swallowed -- either Python code, or C code using PyObject_GetItem() or PyMapping_GetItemString(). Such code deserves to be shot down in my opinion. Assigned to mwh for his feedback (not because I want him to write the patch!). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-05-29 16:55 Message: Logged In: YES user_id=4771 Proposed patch #1497053. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&group_id=5470 From noreply at sourceforge.net Thu Jun 1 15:45:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:45:59 -0700 Subject: [ python-Bugs-214033 ] re incompatibility in sre Message-ID: Bugs item #214033, was opened at 2000-09-11 08:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&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: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. L??wis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 13:45 Message: Logged In: YES user_id=849994 #1456280 is a duplicate of this. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-04-10 23:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2000-10-01 18:13 Message: Yes, it is still broken in 2.0b2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 04:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 From noreply at sourceforge.net Thu Jun 1 15:46:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:46:22 -0700 Subject: [ python-Bugs-1456280 ] Traceback error when compiling Regex Message-ID: Bugs item #1456280, was opened at 2006-03-22 17:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&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: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Wolfgang Grafen (grafen) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Traceback error when compiling Regex Initial Comment: Traceback error when compiling the following regular expression. Error discovered with Python 2.4.2. Used pre from python2.3 to check the validity of re_fmt. With pre it works fine. Question: I submitted a sre error report before and I warned to take off pre from the library. It is of advantage to be able to check a failing re with pre. Personally I feel sre has still too many bugs to completely substitute pre. Regards Wolfgang Grafen ====================================================== chios scalar 582 % ./fmtscalar.py Traceback (most recent call last): File "./fmtscalar.py", line 21, in ? re_fmt = re.compile( File "/user/freepool/local/lib/python2.3/sre.py", line 179, in compile return _compile(pattern, flags) File "/user/freepool/local/lib/python2.3/sre.py", line 230, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat ---- cut here ---- #!/usr/bin/env python2.3 # -*- coding: Latin-1 -*- import sre as re re_fmt = re.compile( "(" "%" "(?P" "\d+" "(?:" "[.]" "\d+" ")" ")?" "(?:" "[(]" "(?P" "[^)]*" ")?" "[)]" ")?" "(?P[a-z])" ")" ) a="%s" b="aber%sxyz" c="aber%3.1i" c="aber%(quengel)s" for i in a,b,c: m = re_fmt.findall(i) print i,m ---- cut here --- ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 13:46 Message: Logged In: YES user_id=849994 Duplicate of #214033. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&group_id=5470 From noreply at sourceforge.net Thu Jun 1 17:54:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 08:54:47 -0700 Subject: [ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability Message-ID: Bugs item #1456209, was opened at 2006-03-22 10:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&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: Nobody/Anonymous (nobody) Summary: dictobject.c:dictresize() vulnerability Initial Comment: We thought we squashed the last of the modify-the-dict-from-a-custom-eq kind of bugs long ago. Too bad. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-01 11:54 Message: Logged In: YES user_id=31435 Patch 1497053 was checked in as revision 46589 of the trunk for Python 2.5, so closing this. I doubt it's worth the effort to backport to 2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-01 09:20 Message: Logged In: YES user_id=4771 Fixed by patch #1497053. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-03-22 11:32 Message: Logged In: YES user_id=4771 The cause of the bug is that if oldtable == mp->ma_smalltable then pure Python code can mangle with mp->ma_smalltable while it is being walked on. A simple fix would be to always make a copy of the oldtable if it is mp->ma_smalltable (not only if oldtable == newtable). Attached a more efficient fix, which should also make dict resizing somehow faster. It requires yet another version of the lookup algorithm, though. It's a very simple version that assumes that all items are different and the dict contains no dummy entries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 From noreply at sourceforge.net Thu Jun 1 17:56:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 08:56:12 -0700 Subject: [ python-Bugs-1275608 ] dict key comparison swallows exceptions Message-ID: Bugs item #1275608, was opened at 2005-08-29 06:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&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: Nobody/Anonymous (nobody) Summary: dict key comparison swallows exceptions Initial Comment: This is an old one that has just biten again and cost a lot of debugging time again: the dict lookup function swallows all errors during key comparison. This is bad in itself, but if the current stack depth is just wrong then *any* comparison will raise a RuntimeError and lookup will pretend that the dictionary is essentially empty. The attached sample program shows this and crashes with a KeyError instead of a RuntimeError. While at the C level there is a basic compatibility problem involved (PyDict_GetItem() not allowed to raise any exception -- see http://thread.gmane.org/gmane.comp.python.devel/62427), I think it should be possible to improve the situation on the Python interface. Unless someone points me to something I missed, I plan to come up with a patch that changes the internal dict functions (including lookdict()) to let exceptions pass through, and have the exceptions swallowed only by the PyDict_*() API functions that require it. The possible (remote) incompatibility here is existing code relying on the exceptions being swallowed -- either Python code, or C code using PyObject_GetItem() or PyMapping_GetItemString(). Such code deserves to be shot down in my opinion. Assigned to mwh for his feedback (not because I want him to write the patch!). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-01 11:56 Message: Logged In: YES user_id=31435 Patch 1497053 was checked in as revision 46589 of the trunk for Python 2.5, so closing this. Because it changes semantics, it should not be backported to 2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-05-29 12:55 Message: Logged In: YES user_id=4771 Proposed patch #1497053. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&group_id=5470 From noreply at sourceforge.net Thu Jun 1 20:57:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 11:57:31 -0700 Subject: [ python-Bugs-1499049 ] lstrip does not work properly Message-ID: Bugs item #1499049, was opened at 2006-06-01 18:57 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=1499049&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: rpache (rpache) Assigned to: Nobody/Anonymous (nobody) Summary: lstrip does not work properly Initial Comment: #!/usr/bin/python line1='DOMAIN=Alpha' line2='DOMAIN=Beta' error=line1.lstrip('DOMAIN=') ok=line2.lstrip('DOMAIN=') print error print ok The code above prints only "lpha" instead of "Alpha" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499049&group_id=5470 From noreply at sourceforge.net Thu Jun 1 22:08:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 13:08:03 -0700 Subject: [ python-Bugs-1497962 ] Leak in tarfile.py Message-ID: Bugs item #1497962, was opened at 2006-05-31 08:42 Message generated for change (Comment added) made by jensj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&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: 5 Submitted By: Jens J?rgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in tarfile.py Initial Comment: There is a leak when using the tarfile module and the extractfile method. Here is a simple example: $ echo "grrr" > x.txt $ tar cf x.tar x.txt $ python Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> import tarfile >>> tar = tarfile.open('x.tar', 'r') >>> f = tar.extractfile('x.txt') >>> f.read() 'grrr\n' >>> del f >>> gc.set_debug(gc.DEBUG_LEAK) >>> print gc.collect() gc: collectable gc: collectable gc: collectable 3 >>> print gc.garbage [, {'name': 'x.txt', 'read': >, 'pos': 0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset': 512L, 'linebuffer': '', 'size': 5L}, >] >>> ---------------------------------------------------------------------- >Comment By: Jens J?rgen Mortensen (jensj) Date: 2006-06-01 22:08 Message: Logged In: YES user_id=716463 Problem is that the ExfileObject hat an attribute (self.read) that is a method bound to itself (self._readsparse or self._readnormal). One solution is to add "del self.read" to the close method, but someone might forget to close the object and still get the leak. Another solution is to change the end of __init__ to: if tarinfo.issparse(): self.sparse = tarinfo.sparse else: self.sparse = None and add a read method: def read(self, size=None): if self.sparse is None: return self._readnormal(size) else: return self._readsparse(size) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470 From noreply at sourceforge.net Thu Jun 1 22:28:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 13:28:26 -0700 Subject: [ python-Bugs-1499049 ] lstrip does not work properly Message-ID: Bugs item #1499049, was opened at 2006-06-01 18:57 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499049&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: Closed >Resolution: Invalid Priority: 5 Submitted By: rpache (rpache) Assigned to: Nobody/Anonymous (nobody) Summary: lstrip does not work properly Initial Comment: #!/usr/bin/python line1='DOMAIN=Alpha' line2='DOMAIN=Beta' error=line1.lstrip('DOMAIN=') ok=line2.lstrip('DOMAIN=') print error print ok The code above prints only "lpha" instead of "Alpha" ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 20:28 Message: Logged In: YES user_id=849994 Please read the docs to (l|r|)strip -- then you'll see that this is not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499049&group_id=5470 From noreply at sourceforge.net Fri Jun 2 01:09:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 16:09:29 -0700 Subject: [ python-Bugs-1497962 ] Leak in tarfile.py Message-ID: Bugs item #1497962, was opened at 2006-05-31 02:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&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: 5 Submitted By: Jens J?rgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in tarfile.py Initial Comment: There is a leak when using the tarfile module and the extractfile method. Here is a simple example: $ echo "grrr" > x.txt $ tar cf x.tar x.txt $ python Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> import tarfile >>> tar = tarfile.open('x.tar', 'r') >>> f = tar.extractfile('x.txt') >>> f.read() 'grrr\n' >>> del f >>> gc.set_debug(gc.DEBUG_LEAK) >>> print gc.collect() gc: collectable gc: collectable gc: collectable 3 >>> print gc.garbage [, {'name': 'x.txt', 'read': >, 'pos': 0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset': 512L, 'linebuffer': '', 'size': 5L}, >] >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-01 19:09 Message: Logged In: YES user_id=31435 There's no evidence of a leak here -- quite the contrary. As the docs say, DEBUG_LEAK implies DEBUG_SAVEALL, and DEBUG_SAVEALL results in _all_ cyclic trash getting appended to gc.garbage. If you don't mess with gc.set_debug(), you'll discover that gc.garbage is empty at the end. In addition, note that the DEBUG_LEAK output plainly says: gc: collectable ... That's also telling you that it found collectable cyclic trash (which it would have reclaimed had you not forced it to get appended to gc.garbage instead). If gc had found uncollectable cycles, these msgs would have started with gc: uncollectable ... instead. Most directly, if I run your tarfile open() and file extraction in an infinite loop (without messing with gc.set_debug()), the process memory use does not grow over time. Unless you have other evidence of an actual leak, this report should be closed without action. Yes, there are reference cycles here, but they're of kinds cyclic gc reclaims. ---------------------------------------------------------------------- Comment By: Jens J?rgen Mortensen (jensj) Date: 2006-06-01 16:08 Message: Logged In: YES user_id=716463 Problem is that the ExfileObject hat an attribute (self.read) that is a method bound to itself (self._readsparse or self._readnormal). One solution is to add "del self.read" to the close method, but someone might forget to close the object and still get the leak. Another solution is to change the end of __init__ to: if tarinfo.issparse(): self.sparse = tarinfo.sparse else: self.sparse = None and add a read method: def read(self, size=None): if self.sparse is None: return self._readnormal(size) else: return self._readsparse(size) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470 From noreply at sourceforge.net Fri Jun 2 04:03:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 19:03:00 -0700 Subject: [ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)): Message-ID: Bugs item #1459159, was opened at 2006-03-27 11:05 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() is wrong for def foo((x)): Initial Comment: See my recent checkin on HEAD for fixing def foo((x)): in the AST compiler. I had to modify test_inspect because the above signature should not do tuple unpacking. inspect thinkgs it does though. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-02 04:02 Message: Logged In: YES user_id=1326842 Can this bug be closed? It seems that the only problem was test_inspect relying on the old behavior. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 13:39 Message: Logged In: YES user_id=849994 This at least explains why test_inspect didn't fail for 2.5 after you had fixed the bug and modified the test. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 13:38 Message: Logged In: YES user_id=849994 That's a bit odd. Following defs: def bar((x)): pass def foo(x): pass In 2.4: >>> dis.dis(bar) 1 0 LOAD_FAST 0 (.0) 3 STORE_FAST 1 (x) 6 LOAD_CONST 0 (None) 9 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE In 2.5: >>> dis.dis(bar) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 From noreply at sourceforge.net Fri Jun 2 08:51:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 23:51:58 -0700 Subject: [ python-Bugs-1499316 ] lstrip does not work properly Message-ID: Bugs item #1499316, was opened at 2006-06-02 06:51 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=1499316&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: rpache (rpache) Assigned to: Nobody/Anonymous (nobody) Summary: lstrip does not work properly Initial Comment: #!/usr/bin/python line1='DOMAIN=Alpha' line2='DOMAIN=Beta' error=line1.lstrip('DOMAIN=') ok=line2.lstrip('DOMAIN=') print error print ok The code above prints only "lpha" instead of "Alpha" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499316&group_id=5470 From noreply at sourceforge.net Fri Jun 2 09:56:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 00:56:52 -0700 Subject: [ python-Bugs-1499316 ] lstrip does not work properly Message-ID: Bugs item #1499316, was opened at 2006-06-02 06:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499316&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: Closed >Resolution: Invalid Priority: 5 Submitted By: rpache (rpache) Assigned to: Nobody/Anonymous (nobody) Summary: lstrip does not work properly Initial Comment: #!/usr/bin/python line1='DOMAIN=Alpha' line2='DOMAIN=Beta' error=line1.lstrip('DOMAIN=') ok=line2.lstrip('DOMAIN=') print error print ok The code above prints only "lpha" instead of "Alpha" ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-02 07:56 Message: Logged In: YES user_id=849994 Please read the docs to (l|r|)strip -- then you'll see that this is not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1499316&group_id=5470 From noreply at sourceforge.net Fri Jun 2 12:40:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 03:40:13 -0700 Subject: [ python-Bugs-1432343 ] Description of file-object read() method is wrong. Message-ID: Bugs item #1432343, was opened at 2006-02-15 17:49 Message generated for change (Comment added) made by clintonroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&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: Grant Edwards (grante) Assigned to: Nobody/Anonymous (nobody) Summary: Description of file-object read() method is wrong. Initial Comment: There are two errors in the documentation of the file object's read() method found at http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242 Suggested changes (unindented) are shown below interspersed with the current text with insertions noted by a '+' in the first column: Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. + Under some circumstances (e.g. system call aborted by + a signal) read() called with a negative or absent size + argument may return data before EOF is reached (even in + blocking mode). The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) The last sentence above (the parenthetical one) is false for Linux/Unix. Once you hit EOF on a tty, it will return EOF forever until it's closed and re-opened. If the above sentence is true for other OSes, I suggest it be so qualified -- otherwise it should just be deleted. Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible. Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-06-02 10:40 Message: Logged In: YES user_id=31446 ''' Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given.''' This sentence doesn't make much sense to me, if you haven't given a size parameter, you haven't requested any size.. ---------------------------------------------------------------------- Comment By: Grant Edwards (grante) Date: 2006-02-16 13:08 Message: Logged In: YES user_id=61937 My bad. You're right about the Ctrl-D case. The code I was looking that caused a permanent EOF was when the master end of a pty was closed. I think. Anyway, Ctrl-D doesn't cause a permanent EOF condition and you can read more data afterwards. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2006-02-16 11:17 Message: Logged In: YES user_id=1008220 Well spoken! However I'm not sure I quite follow you here: > The last sentence above (the parenthetical one) is false > for Linux/Unix. Once you hit EOF on a tty, it will return > EOF forever until it's closed and re-opened. A quote from Donn Cave in a discussion on comp.lang.python: """ They were probably thinking of the way the UNIX tty driver delivers an EOF on D, after which of course you can continue to read data from the same tty. """ This is also true for the Linux tty (afaik), so under those circumstances it may really make sense to continue reading past EOF. example: ------------------------------------------------- #!/usr/bin/python import sys while True: s = sys.stdin.read() print s ------------------------------------------------- Pressing Ctrl-D while providing input to sys.stdin via the keyboard will cause sys.stdin.read() to return, and you will still be able to keep reading from sys.stdin without closing and reopening it explicitly. But then again I might have missed something. /Joel Hedlund ---------------------------------------------------------------------- Comment By: Grant Edwards (grante) Date: 2006-02-15 17:51 Message: Logged In: YES user_id=61937 Well, that didn't work very well. I really hate these web interfaces. I've attached the suggested changes as a text file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470 From noreply at sourceforge.net Fri Jun 2 12:52:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 03:52:10 -0700 Subject: [ python-Bugs-1432343 ] Description of file-object read() method is wrong. Message-ID: Bugs item #1432343, was opened at 2006-02-15 17:49 Message generated for change (Comment added) made by clintonroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&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: Grant Edwards (grante) Assigned to: Nobody/Anonymous (nobody) Summary: Description of file-object read() method is wrong. Initial Comment: There are two errors in the documentation of the file object's read() method found at http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242 Suggested changes (unindented) are shown below interspersed with the current text with insertions noted by a '+' in the first column: Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. + Under some circumstances (e.g. system call aborted by + a signal) read() called with a negative or absent size + argument may return data before EOF is reached (even in + blocking mode). The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) The last sentence above (the parenthetical one) is false for Linux/Unix. Once you hit EOF on a tty, it will return EOF forever until it's closed and re-opened. If the above sentence is true for other OSes, I suggest it be so qualified -- otherwise it should just be deleted. Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible. Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-06-02 10:52 Message: Logged In: YES user_id=31446 ''' Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given.''' This sentence doesn't make much sense to me, if you haven't given a size parameter, you haven't requested any size.. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-06-02 10:40 Message: Logged In: YES user_id=31446 ''' Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given.''' This sentence doesn't make much sense to me, if you haven't given a size parameter, you haven't requested any size.. ---------------------------------------------------------------------- Comment By: Grant Edwards (grante) Date: 2006-02-16 13:08 Message: Logged In: YES user_id=61937 My bad. You're right about the Ctrl-D case. The code I was looking that caused a permanent EOF was when the master end of a pty was closed. I think. Anyway, Ctrl-D doesn't cause a permanent EOF condition and you can read more data afterwards. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2006-02-16 11:17 Message: Logged In: YES user_id=1008220 Well spoken! However I'm not sure I quite follow you here: > The last sentence above (the parenthetical one) is false > for Linux/Unix. Once you hit EOF on a tty, it will return > EOF forever until it's closed and re-opened. A quote from Donn Cave in a discussion on comp.lang.python: """ They were probably thinking of the way the UNIX tty driver delivers an EOF on D, after which of course you can continue to read data from the same tty. """ This is also true for the Linux tty (afaik), so under those circumstances it may really make sense to continue reading past EOF. example: ------------------------------------------------- #!/usr/bin/python import sys while True: s = sys.stdin.read() print s ------------------------------------------------- Pressing Ctrl-D while providing input to sys.stdin via the keyboard will cause sys.stdin.read() to return, and you will still be able to keep reading from sys.stdin without closing and reopening it explicitly. But then again I might have missed something. /Joel Hedlund ---------------------------------------------------------------------- Comment By: Grant Edwards (grante) Date: 2006-02-15 17:51 Message: Logged In: YES user_id=61937 Well, that didn't work very well. I really hate these web interfaces. I've attached the suggested changes as a text file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470 From noreply at sourceforge.net Sat Jun 3 07:03:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 22:03:34 -0700 Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25 Message-ID: Bugs item #1295179, was opened at 2005-09-19 17:28 Message generated for change (Comment added) made by kbob_ru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. ---------------------------------------------------------------------- >Comment By: kbob_ru (kbob_ru) Date: 2006-06-03 13:03 Message: Logged In: YES user_id=1347065 I used next patch for Python versions 2.3.5 and 2.4.3. It helps work properly termios module in QNX4.25 and termios test pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 From noreply at sourceforge.net Sat Jun 3 20:10:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 11:10:33 -0700 Subject: [ python-Bugs-1472084 ] sgmllib do_tag description error Message-ID: Bugs item #1472084, was opened at 2006-04-17 23:52 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472084&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: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James G. sack (jim) (jgsack) >Assigned to: A.M. Kuchling (akuchling) Summary: sgmllib do_tag description error Initial Comment: section 13.2 sgmllib -- Simple SGML parser do_tag(attributes) This method is called to process an opening tag that does not come with a matching closing tag... (that's incorrect) It should say something like This method is called to process an opening tag (only) if there is no corresponding start_tag function defined. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:10 Message: Logged In: YES user_id=11375 Fixed on both the 2.4-maint branch and the trunk; thanks for the correction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472084&group_id=5470 From noreply at sourceforge.net Sat Jun 3 20:24:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 11:24:11 -0700 Subject: [ python-Bugs-1489648 ] time module missing from global mod index Message-ID: Bugs item #1489648, was opened at 2006-05-16 11:49 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&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: Closed Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time module missing from global mod index Initial Comment: The time module is not listed in the latest dev global module index: http://docs.python.org/dev/modindex.html Skip ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:24 Message: Logged In: YES user_id=11375 Closing this bug, then; it's a website issue, not a Python one. I've informed Neal Norwitz, who seems to be responsible for the dev. docs. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-05-24 23:10 Message: Logged In: YES user_id=44345 Okay, I'll open a ticket for the website and refer to this ticket. Skip ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-05-24 22:57 Message: Logged In: YES user_id=3066 Skip, I don't know how to make the update. When I build the docs on my machine, the "time" module link is included in the global module index. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-05-24 22:34 Message: Logged In: YES user_id=44345 I'm not sure what's to reproduce. I just observed that the dev version of the module index is missing the time module, at least when viewed from my Mac using Safari or Firefox. Does updating the dev docs restore it? Skip ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-05-24 21:51 Message: Logged In: YES user_id=3066 I can't reproduce this, even after doing a "make clobber" in the Doc/ directory. Was there anything weird about the environment? Windows/Cygwin? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-05-16 14:44 Message: Logged In: YES user_id=671362 Same as bug #1109523 I can't reproduce this in my local environment but Fred should know the reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470 From noreply at sourceforge.net Sat Jun 3 20:34:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 11:34:39 -0700 Subject: [ python-Bugs-1475554 ] Poorly worded description for socket.makefile() Message-ID: Bugs item #1475554, was opened at 2006-04-24 10:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Roy Smith (roysmith) >Assigned to: A.M. Kuchling (akuchling) Summary: Poorly worded description for socket.makefile() Initial Comment: On the "7.2.1 Socket Objects" page, under makefile(), it says "The socket should be in blocking mode". If I understand it correctly, it MUST be in blocking mode. "Must" implies a mandatory requirement, "should" implies a suggestion of the best way to do something. This comment applies to many places in the Python docs. There should be a comprehensive review of all the docs to clarify "should" vs. "must" usage. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:34 Message: Logged In: YES user_id=11375 I've corrected the text for makefile() on the 2.4-maint and trunk branches. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 From noreply at sourceforge.net Sat Jun 3 20:47:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 11:47:42 -0700 Subject: [ python-Bugs-1441864 ] Omission in docs for urllib2.urlopen() Message-ID: Bugs item #1441864, was opened at 2006-03-02 11:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441864&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: A.M. Kuchling (akuchling) Summary: Omission in docs for urllib2.urlopen() Initial Comment: The docs for urllib2.urlopen() don't explicitly say that if the data parameter is provided then it will do a POST. I suggest replacing the second paragraph (beginning with "data should be a string") with this text: In HTTP requests, the optional data argument may be given to specify a POST request (normally the request type is GET). The data argument must be in standard application/x-www-form-urlencoded format, for example one returned from urllib.urlencode(). Kent ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:47 Message: Logged In: YES user_id=11375 I've used a modified version of your clarification. Thanks for the suggestion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441864&group_id=5470 From noreply at sourceforge.net Sat Jun 3 20:52:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 11:52:13 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&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: nomind (vnainar) >Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 18:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 17:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 16:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 09:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 06:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 06:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 01:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-04 18:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sat Jun 3 20:55:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 11:55:31 -0700 Subject: [ python-Bugs-1500167 ] interpret termination, object deleting Message-ID: Bugs item #1500167, was opened at 2006-06-03 20:55 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=1500167&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: 5 Submitted By: Jan Martinek (johnymart) Assigned to: Nobody/Anonymous (nobody) Summary: interpret termination, object deleting Initial Comment: Hello, I found out a strange behavior. This code #!/usr/bin/python class M: b = 0 def __del__(self): M.b = 0 a1 = M() results in exception when the program terminates. Exception exceptions.AttributeError: "'NoneType' object has no attribute 'b'" in > ignored Note that the code must be run from an executable file -not from the python interpretter. Otherwise the exception is not thrown. An interesting thing is that changing the last line to a = M() also prevents python from throwing the exception. Why does it depend on variable's name? bye Jan Martinek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500167&group_id=5470 From noreply at sourceforge.net Sat Jun 3 21:03:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 12:03:23 -0700 Subject: [ python-Bugs-1497414 ] __self reserved WATCOM 10.6 word Message-ID: Bugs item #1497414, was opened at 2006-05-30 05:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&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: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: __self reserved WATCOM 10.6 word Initial Comment: same as bug 1412837, but for Modules/_tkinter.c ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 15:03 Message: Logged In: YES user_id=11375 Fix committed to the trunk in rev. 46619. I'll wait for the buildbots to complete before applying to 2.4-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&group_id=5470 From noreply at sourceforge.net Sat Jun 3 21:32:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 12:32:56 -0700 Subject: [ python-Bugs-1500179 ] re.escape incorrectly escape literal. Message-ID: Bugs item #1500179, was opened at 2006-06-03 21:32 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=1500179&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: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Baptiste Lepilleur (blep) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.escape incorrectly escape literal. Initial Comment: Using Python 2.4.2. Here is a small programm excerpt that reproduce the issue (attached): --- import re literal = r'E:\prg\vc' print 'Expected:', literal print 'Actual:', re.sub('a', re.escape(literal), 'a' ) assert re.sub('a', re.escape(literal), 'a' ) == literal --- And the output of the sample: --- Expected: E:\prg\vc Actual : E\:\prg\vc Traceback (most recent call last): File "re_escape_bug.py", line 5, in ? assert re.sub('a', re.escape(literal), 'a' ) == literal AssertionError --- Looking at regular expression syntax of python documentation I don't see why ':' is escaped as '\:'. Baptiste. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470 From noreply at sourceforge.net Sat Jun 3 22:16:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 13:16:51 -0700 Subject: [ python-Bugs-1488934 ] file.write + closed pipe = no error Message-ID: Bugs item #1488934, was opened at 2006-05-15 12:10 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&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: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: file.write + closed pipe = no error Initial Comment: I am writing a Python script on Linux that gets called via ssh (ssh hostname script.py) and I would like it to know when its stdout gets closed because the ssh connection gets killed. I assumed that it would suffice to write to stdout, and that I would get an error if stdout was no longer connected to anything. This is not the case, however. I believe it is because of incorrect error checking in Objects/fileobject.c's file_write. Consider this example: while True: __print 'Hello' __time.sleep (1) If this program is run via ssh and then the ssh connection dies, the program continues running forever (or at least, over 10 hours). No exceptions are thrown. In contrast, this example does die as soon as the ssh connection dies (within one second): while True: __os.write (1, 'Hello') __time.sleep (1) I claim that this is because os.write does proper error checking, but file.write seems not to. I was surprised to find this intricacy in fwrite(). Consider the attached C program, test.c. (Warning: If you run it, it will create a file /tmp/hello, and it will keep running until you kill it.) While the ssh connection remains open, fwrite() reports a length of 6 bytes written, ferror() reports no error, and errno remains 0. Once the ssh connection dies, fwrite() still reports a length of 6 bytes written (surprise!), but ferror(stdout) reports an error, and errno changes to 5 (EIO). So apparently one cannot tell from the return value of fwrite() alone whether the write actually succeeded; it seems necessary to call ferror() to determine whether the write caused an error. I think the only change necessary is on line 2443 of file_write() in Objects/fileobject.c (in svn version 46003): 2441 n2 = fwrite(s, 1, n, f->f_fp); 2442 Py_END_ALLOW_THREADS 2443 if (n2 != n) { 2444 PyErr_SetFromErrno(PyExc_IOError); 2445 clearerr(f->f_fp); I am not totally sure whether the "n2 != n" condition should be changed to "n2 != n || ferror (f->f_fp)" or simply "ferror (f->f_fp)", but I believe that the condition should be changed to one of these possibilities. The current behavior is wrong. Incidentally, you'll notice that the C code has to turn off signal SIGPIPE (like Python does) in order to not die right away. However, I could not get Python to die by re-enabling SIGPIPE. I tried "signal.signal (signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal (signal.SIGPIPE, lambda x, y: sys.exit ())" and neither one caused death of the script when the ssh connection died. Perhaps I'm not using the signal module correctly? I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and I am running the latest Subversion version of Python, but my guess is that this error transcends most if not all versions of Python. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:16 Message: Logged In: YES user_id=11375 I agree with your analysis, and think your suggested fixes are correct. However, I'm unable to construct a small test case that exercises this bug. I can't even replicate the problem with SSH; when I run a remote script with SSH and then kill SSH with Ctrl-C, the write() gets a -1. Are you terminating SSH in some other way? (I'd really like to have a test case for this problem before committing the fix.) ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2006-05-15 12:26 Message: Logged In: YES user_id=265183 One more thing: fwrite() is used in a couple of other places, and I think the same comment applies to them. They are: - file_writelines() in Objects/fileobject.c - w_string() in Python/marshal.c doesn't seem to have any error checking? (At least no ferror() call in marhsal.c...) - string_print() in Objects/stringobject.c doesn't seem to have any error checking (but I'm not quite sure what this means in Python land). - flush_data() in Modules/_hotshot.c - array_tofile() in Modules/arraymodule.c - write_file() in Modules/cPickle.c - putshort(), putlong(), writeheader(), writetab() [and the functions that call them] in Modules/rgbimgmodule.c - svc_writefile() in Modules/svmodule.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470 From noreply at sourceforge.net Sat Jun 3 22:27:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 13:27:08 -0700 Subject: [ python-Bugs-1500179 ] re.escape incorrectly escape literal. Message-ID: Bugs item #1500179, was opened at 2006-06-03 15:32 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&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: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Baptiste Lepilleur (blep) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.escape incorrectly escape literal. Initial Comment: Using Python 2.4.2. Here is a small programm excerpt that reproduce the issue (attached): --- import re literal = r'E:\prg\vc' print 'Expected:', literal print 'Actual:', re.sub('a', re.escape(literal), 'a' ) assert re.sub('a', re.escape(literal), 'a' ) == literal --- And the output of the sample: --- Expected: E:\prg\vc Actual : E\:\prg\vc Traceback (most recent call last): File "re_escape_bug.py", line 5, in ? assert re.sub('a', re.escape(literal), 'a' ) == literal AssertionError --- Looking at regular expression syntax of python documentation I don't see why ':' is escaped as '\:'. Baptiste. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:27 Message: Logged In: YES user_id=11375 The assertion is wrong, I think. The signature is re.sub(pattern, replacement, string), so the assertion is replacing 'a' with re.escape(literal), which is obviously not going to equal literal. re.escape() puts a backslash in front of all non-alphanumeric characters; ':' is non-alphanumeric, so it will be escaped. The regex parser will ignore unknown escapes, so \: is the same as : -- the redundant escaping is harmless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470 From noreply at sourceforge.net Sat Jun 3 22:28:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 13:28:12 -0700 Subject: [ python-Bugs-1498146 ] optparse does not hande unicode help strings Message-ID: Bugs item #1498146, was opened at 2006-05-31 07:52 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Cato Amundsen (tomcato) >Assigned to: Greg Ward (gward) Summary: optparse does not hande unicode help strings Initial Comment: Unicode strings with non-ascii chars in generate a UnicodeEncodeError File "/usr/lib/python2.3/optparse.py", line 1370, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: +ordinal not in range(128) I'm subclassing OptionParser and adds the following method to get it to work. Should something like this be done for python 2.5? def print_help(self, file=None): if file is None: file = sys.stdout file.write(self.format_help().encode(file.encoding, 'replace')) Tom Cato ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 From noreply at sourceforge.net Sat Jun 3 22:35:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 13:35:31 -0700 Subject: [ python-Bugs-1497414 ] __self reserved WATCOM 10.6 word Message-ID: Bugs item #1497414, was opened at 2006-05-30 05:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&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: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: A.M. Kuchling (akuchling) Summary: __self reserved WATCOM 10.6 word Initial Comment: same as bug 1412837, but for Modules/_tkinter.c ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:35 Message: Logged In: YES user_id=11375 The buildbots seemed to still compile _tkinter.c, so I've applied the change to the release24-maint branch in rev. 46620 and will now close this bug. Thanks for reporting this problem! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 15:03 Message: Logged In: YES user_id=11375 Fix committed to the trunk in rev. 46619. I'll wait for the buildbots to complete before applying to 2.4-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&group_id=5470 From noreply at sourceforge.net Sat Jun 3 22:42:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 13:42:47 -0700 Subject: [ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need updating Message-ID: Bugs item #1495229, was opened at 2006-05-25 19:33 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Martin v. L??wis (loewis) Summary: W3C <-> Python DOM type mapping docs need updating Initial Comment: I believe the information at http://docs.python.org/lib/dom-type-mapping.html is outdated; most if not all boolean return values, at least in minidom, are handled as BooleanType, not IntegerType. This should be standard. Sorry, I don't have a patch to submit for this. Should be an easy fix though. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:42 Message: Logged In: YES user_id=11375 Martin, you probably need to make a pronouncement on this. The DOM mapping is supposed to be derived from the IDL mapping for Python, which predates Booleans, but methods such as hasChildNodes() return True/False. I can see at least three answers: 1) Booleans are subtypes of integers, so the docs are not wrong. 2) The docs are wrong and should say Boolean. 3) The methods should be returning regular 0 and 1, not True and False, and should be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470 From noreply at sourceforge.net Sat Jun 3 23:01:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 14:01:36 -0700 Subject: [ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need updating Message-ID: Bugs item #1495229, was opened at 2006-05-25 16:33 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Martin v. L??wis (loewis) Summary: W3C <-> Python DOM type mapping docs need updating Initial Comment: I believe the information at http://docs.python.org/lib/dom-type-mapping.html is outdated; most if not all boolean return values, at least in minidom, are handled as BooleanType, not IntegerType. This should be standard. Sorry, I don't have a patch to submit for this. Should be an easy fix though. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2006-06-03 14:01 Message: Logged In: YES user_id=371366 If answer #1 is chosen and the others rejected, then the docs remain misleading, since the average reader just wants to know what types to expect from an implementation (or should code into their implementation), and shouldn't be expected to know the relationship between Booleans and integers. Is it even reasonable to expect that this relationship will always be true? In any case, I'd rather see it made explicit as to why minidom doesn't seem, at first, to respect the type mapping, at least in current implementations. It could be as simple as adding Andrew's comment, phrased as "This DOM mapping is derived from the IDL mapping for Python, which predates the introduction of BooleanType, which is currently a subtype of IntegerType. Implementations may use either type." or some such. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 13:42 Message: Logged In: YES user_id=11375 Martin, you probably need to make a pronouncement on this. The DOM mapping is supposed to be derived from the IDL mapping for Python, which predates Booleans, but methods such as hasChildNodes() return True/False. I can see at least three answers: 1) Booleans are subtypes of integers, so the docs are not wrong. 2) The docs are wrong and should say Boolean. 3) The methods should be returning regular 0 and 1, not True and False, and should be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470 From noreply at sourceforge.net Sat Jun 3 23:45:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 14:45:46 -0700 Subject: [ python-Bugs-1500179 ] re.escape incorrectly escape literal. Message-ID: Bugs item #1500179, was opened at 2006-06-03 21:32 Message generated for change (Settings changed) made by blep You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&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: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Baptiste Lepilleur (blep) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.escape incorrectly escape literal. Initial Comment: Using Python 2.4.2. Here is a small programm excerpt that reproduce the issue (attached): --- import re literal = r'E:\prg\vc' print 'Expected:', literal print 'Actual:', re.sub('a', re.escape(literal), 'a' ) assert re.sub('a', re.escape(literal), 'a' ) == literal --- And the output of the sample: --- Expected: E:\prg\vc Actual : E\:\prg\vc Traceback (most recent call last): File "re_escape_bug.py", line 5, in ? assert re.sub('a', re.escape(literal), 'a' ) == literal AssertionError --- Looking at regular expression syntax of python documentation I don't see why ':' is escaped as '\:'. Baptiste. ---------------------------------------------------------------------- >Comment By: Baptiste Lepilleur (blep) Date: 2006-06-03 23:45 Message: Logged In: YES user_id=196852 You are correct. Though, the 'repl' string parameter is not a literal string and is interpreted. The correct escape function to preserve the literal is literal.replace('\\','\\\\') not re.escape(). It would preserve any interpretation of the repl pattern. I believe this fact should be clearly stated in the documentation as it is not that obvious. The following assertion pass: --- import re literal = r'e:\prg\vc\1' assert re.sub( '(a+)', literal.replace('\\','\\\\'), 'aabac' ) == (literal+'b'+literal+'c') --- In the above example neither \v nor \1 are interpreted. Regards, Baptiste. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 22:27 Message: Logged In: YES user_id=11375 The assertion is wrong, I think. The signature is re.sub(pattern, replacement, string), so the assertion is replacing 'a' with re.escape(literal), which is obviously not going to equal literal. re.escape() puts a backslash in front of all non-alphanumeric characters; ':' is non-alphanumeric, so it will be escaped. The regex parser will ignore unknown escapes, so \: is the same as : -- the redundant escaping is harmless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470 From noreply at sourceforge.net Sun Jun 4 05:30:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 20:30:34 -0700 Subject: [ python-Bugs-1500293 ] Memory leak in subprocess module Message-ID: Bugs item #1500293, was opened at 2006-06-04 05:30 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=1500293&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: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in subprocess module Initial Comment: The memory leak is in _subprocess module in functions getint and gethandle. They forget to decref the objects returned by PyObject_GetAttrString(). The bug is present in version 2.4 as well as in the trunk. Few more bugs in the subprocess module that I found while looking for the leak: - class STARTUPINFO is missing a wShowWindow attribute (this is hidden because _subprocess.CreateProcess() ignores most of the exceptions) - _execute_child() had a nonsensical test (if not None in tuple_of_posible_file_handles) - _execute_child() is assigning attributes to a default_startupinfo, which isn't used if user supplies another one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 From noreply at sourceforge.net Sun Jun 4 06:28:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 21:28:11 -0700 Subject: [ python-Bugs-1500293 ] Memory leak in subprocess module Message-ID: Bugs item #1500293, was opened at 2006-06-04 12:30 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&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: ?iga Seilnacht (zseil) >Assigned to: Peter ? strand (astrand) Summary: Memory leak in subprocess module Initial Comment: The memory leak is in _subprocess module in functions getint and gethandle. They forget to decref the objects returned by PyObject_GetAttrString(). The bug is present in version 2.4 as well as in the trunk. Few more bugs in the subprocess module that I found while looking for the leak: - class STARTUPINFO is missing a wShowWindow attribute (this is hidden because _subprocess.CreateProcess() ignores most of the exceptions) - _execute_child() had a nonsensical test (if not None in tuple_of_posible_file_handles) - _execute_child() is assigning attributes to a default_startupinfo, which isn't used if user supplies another one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 From noreply at sourceforge.net Sun Jun 4 11:53:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 02:53:07 -0700 Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources Message-ID: Bugs item #1484556, was opened at 2006-05-09 13:14 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Output of KlocWork on Python2.4.3 sources Initial Comment: We're evaluating KlocWork (http://www.klocwork.com), I've ran it on the source of Python 2.4.3 and the output is attached (1562 warnings). ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2006-06-04 12:53 Message: Logged In: YES user_id=358087 I'll try to see if I can sneak it in, can't promise anything though ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 17:26 Message: Logged In: YES user_id=11375 The Coverity scans also probably report some of the same bugs, so many of these problems may be fixed in the 2.5 trunk. If you're still evaluating, you could try running the tool on the 2.5 trunk (snapshot available from http://svn.python.org/snapshots/) and see if the results are shorter. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-10 07:45 Message: Logged In: YES user_id=21627 Thanks for these results. Unfortunately, they seem to contain many false positives, so it is unclear how one should proceed with them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 From noreply at sourceforge.net Sun Jun 4 18:57:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 09:57:11 -0700 Subject: [ python-Bugs-1496315 ] strptime: wrong default values used to fill in missing data Message-ID: Bugs item #1496315, was opened at 2006-05-28 11:26 Message generated for change (Comment added) made by markus_gritsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&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: Closed Resolution: Fixed Priority: 5 Submitted By: Markus Gritsch (markus_gritsch) Assigned to: Brett Cannon (bcannon) Summary: strptime: wrong default values used to fill in missing data Initial Comment: The documentation of strptime() says: """The default values used to fill in any missing data are (1900, 1, 1, 0, 0, 0, 0, 1, -1)""". As the example below shows, this is not the case. Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.strptime('', '') (1900, 1, 1, 0, 0, 0, 0, 1, -1) >>> time.strptime('2006', '%Y') (2006, 1, 1, 0, 0, 0, 6, 1, -1) >>> time.strptime('2006-05', '%Y-%m') (2006, 5, 1, 0, 0, 0, 0, 121, -1) >>> time.strptime('2006-05-26', '%Y-%m-%d') (2006, 5, 26, 0, 0, 0, 4, 146, -1) >>> time.strptime('2006-05-26 21', '%Y-%m-%d %H') (2006, 5, 26, 21, 0, 0, 4, 146, -1) >>> time.strptime('2006-05-26 21:06', '%Y-%m-%d %H:%M') (2006, 5, 26, 21, 6, 0, 4, 146, -1) >>> time.strptime('2006-05-26 21:06:11', '%Y-%m-%d %H:%M:%S') (2006, 5, 26, 21, 6, 11, 4, 146, -1) ---------------------------------------------------------------------- >Comment By: Markus Gritsch (markus_gritsch) Date: 2006-06-04 18:57 Message: Logged In: YES user_id=553904 Thank you ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-05-31 04:22 Message: Logged In: YES user_id=357491 Rev. 46569 has more clear wording for HEAD and rev. 46570 has it for 2.4 . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-05-28 20:29 Message: Logged In: YES user_id=357491 The docs need to be fixed to say those are the default values except when strptime() can infer better ones. There is a lot of smarts in the algorithm that do calculations to fill in missing data as best as possible, and that is what is happening here. Thanks for the bug report. I will try to fix this some time this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&group_id=5470 From noreply at sourceforge.net Sun Jun 4 21:56:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 12:56:48 -0700 Subject: [ python-Bugs-1500167 ] interpret termination, object deleting Message-ID: Bugs item #1500167, was opened at 2006-06-03 20:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500167&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jan Martinek (johnymart) Assigned to: Nobody/Anonymous (nobody) Summary: interpret termination, object deleting Initial Comment: Hello, I found out a strange behavior. This code #!/usr/bin/python class M: b = 0 def __del__(self): M.b = 0 a1 = M() results in exception when the program terminates. Exception exceptions.AttributeError: "'NoneType' object has no attribute 'b'" in > ignored Note that the code must be run from an executable file -not from the python interpretter. Otherwise the exception is not thrown. An interesting thing is that changing the last line to a = M() also prevents python from throwing the exception. Why does it depend on variable's name? bye Jan Martinek ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 21:56 Message: Logged In: YES user_id=21627 On shutdown time, Python clears each module by replacing all module entries with None. So at some point, it does a1 = None # or a1 = None and at some other point, it does M = None Depending on the order in which these happen, M might be None (i.e. might not be class M anymore) when __del__ runs. The order in which these happen depends on the order which the names have in the module's dict. This, in turn, depends on the hash values of the strings, modulo the size of the dictionary. Apparently, "a1" gets hashed after "M", but "a" gets hashed before "M". This isn't really a bug, atleast not one that we plan to fix. The order in which modules get emptied is unspecified, and it can easily happen that things are gone when some destructor runs. Classes should be written to be resistent against this behaviour, e.g. by writing def __del__(self): self.__class__.b = 0 # name "M" might be gone already Closing this as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500167&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:02:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:02:51 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 14:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 22:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:05:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:05:46 -0700 Subject: [ python-Bugs-1498051 ] MSVC compiler problems with .NET v2.0 Message-ID: Bugs item #1498051, was opened at 2006-05-31 11:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498051&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: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Retief Gerber (hrgerber) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC compiler problems with .NET v2.0 Initial Comment: There is a problem with msvccompiler.py that does not allow it to work with MS Visual Studio 2005 and .NET v2.0 msvccompiler.py __revision__ = "$Id: msvccompiler.py,v 1.64.2.4 2005/08/07 20:50:37 loewis Exp $" from line 128 if version > 7.0: self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1") else: self.set_macro("FrameworkSDKDir", net, "sdkinstallroot") should be replaced with if version == 7.1: self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv2.0") elif version > 7.0: self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1") else: self.set_macro("FrameworkSDKDir", net, "sdkinstallroot") I dont have must dev experience on distutils, so this might not be the best solution ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 22:05 Message: Logged In: YES user_id=21627 This is not a bug. You shouldn't use Visual Studio 2005 to build extensions for Python. Python extensions should be built with the same version of the Microsoft compiler that was used to build Python itself. For Python 2.4 and 2.5, that's Visual Studio 2003. Closing as "not-a-bug". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498051&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:14:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:14:57 -0700 Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3 Message-ID: Bugs item #1494314, was opened at 2006-05-24 15:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 22:14 Message: Logged In: YES user_id=21627 A patch to replace internal_select with poll(2) where available is acceptable. The current version should be conditionally kept. That Windows doesn't have poll(2) is no problem: its select implementation supports arbitrarily large FDs (just like poll). Relaxing the IS_SELECTABLE usage to cases where select is actually going to be called is optional: there shouldn't be too many systems left without select where people still want to open many file descriptors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-01 00:27 Message: Logged In: YES user_id=31435 akuchling: No, poll() is not part of the Windows socket API. ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 23:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 20:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 16:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 16:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 16:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 15:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your current limit. Ulimits are enforced by the Linux kernel and can likely be configured system-wide in /etc/sysctl.cfg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:20:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:20:46 -0700 Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE Message-ID: Bugs item #1489051, was opened at 2006-05-15 20:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Windows Group: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: BartlebyScrivener (bscrivener) Assigned to: Martin v. L??wis (loewis) Summary: keyword and topic help broken in Pythonwin IDE Initial Comment: Using ActivePython 2.4.3 on Windows XP While in the Pythonwin IDE, if I seek keyword help by issuing the following command: >>>help ('while') I get: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. My PYTHONDOCS variable is set to: c:\python24\Doc\Python-Docs-2.4.2\ref which appears to be correct (ie the help html files are installed there). Searching this group, I found someone else complaining about the same behavior with no clear resolution. http://tinyurl.com/pblev See also http://tinyurl.com/mbokp ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 22:20 Message: Logged In: YES user_id=21627 bscrivener, please run hh -decompile c:\python24\doc\html c:\python24\Doc\python24.chm and report whether that fixes the problem. ---------------------------------------------------------------------- Comment By: BartlebyScrivener (bscrivener) Date: 2006-05-30 02:45 Message: Logged In: YES user_id=1523094 >> From what I understand, HTML help hasn't shipped with >> Python on Windows for a few releases (likely around the >> time that .chm help files started shipping). The two tiny urls, esp. the second one illuminate just where the bug is in Pydoc, but the fix recommended by the poster doesn't work. The problem happens even after downloading html help and pointing pydoc to it in the Pythondocs environment variable. I don't know enough to explore further, which is why I need a nice working help function :) I would think this would be an urgent fix for Python evangelism. rd ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-30 02:42 Message: Logged In: YES user_id=1326842 The problem is on your side. You should set the PYTHONDOCS environment variable to the root directory of the html documentation, eg.: PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2 and not: PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2\ref ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-05-30 00:30 Message: Logged In: YES user_id=341410 >From what I understand, HTML help hasn't shipped with Python on Windows for a few releases (likely around the time that .chm help files started shipping). If you've got html help files installed, and it's still not picking them up, could you dig deeper into why this is the case. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-30 00:24 Message: Logged In: YES user_id=849994 Okay, reopening. ---------------------------------------------------------------------- Comment By: BartlebyScrivener (bscrivener) Date: 2006-05-30 00:19 Message: Logged In: YES user_id=1523094 Sorry, if I was unclear. IDLE is not third party, is it? So I'm saying that on Windows XP, using the install from Python.org help() is BROKEN. Search in the Python Google group and you'll find many other references to same. Pydoc no longer provides help on topic or keywords. It will do modules. In short it's PYDOC that is broken, not Pythonwin IDE. Thanks, rick ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-29 23:00 Message: Logged In: YES user_id=849994 Closing as 3rd party. ---------------------------------------------------------------------- Comment By: BartlebyScrivener (bscrivener) Date: 2006-05-21 02:51 Message: Logged In: YES user_id=1523094 help('topic') or help('keyword') doesn't work in IDLE or Pythonwin IDE ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-05-20 09:00 Message: Logged In: YES user_id=341410 Since you are using the Pythonwin IDE, which was written and is supported by Mark Hammond via the pywin32 project, perhaps you should be visiting his project page instead: http://sf.net/projects/pywin32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:39:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:39:49 -0700 Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE Message-ID: Bugs item #1489051, was opened at 2006-05-15 18:46 Message generated for change (Comment added) made by bscrivener You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Windows Group: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: BartlebyScrivener (bscrivener) Assigned to: Martin v. L??wis (loewis) Summary: keyword and topic help broken in Pythonwin IDE Initial Comment: Using ActivePython 2.4.3 on Windows XP While in the Pythonwin IDE, if I seek keyword help by issuing the following command: >>>help ('while') I get: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. My PYTHONDOCS variable is set to: c:\python24\Doc\Python-Docs-2.4.2\ref which appears to be correct (ie the help html files are installed there). Searching this group, I found someone else complaining about the same behavior with no clear resolution. http://tinyurl.com/pblev See also http://tinyurl.com/mbokp ---------------------------------------------------------------------- >Comment By: BartlebyScrivener (bscrivener) Date: 2006-06-04 20:39 Message: Logged In: YES user_id=1523094 >> bscrivener, please run >> hh -decompile c:\python24\doc\html c:\python24\Doc\python24.chm >> and report whether that fixes the problem. Fixed! Thank you. I'll share with comp.lang.python next time somebody else has the same problem. Thank you, loewis! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 20:20 Message: Logged In: YES user_id=21627 bscrivener, please run hh -decompile c:\python24\doc\html c:\python24\Doc\python24.chm and report whether that fixes the problem. ---------------------------------------------------------------------- Comment By: BartlebyScrivener (bscrivener) Date: 2006-05-30 00:45 Message: Logged In: YES user_id=1523094 >> From what I understand, HTML help hasn't shipped with >> Python on Windows for a few releases (likely around the >> time that .chm help files started shipping). The two tiny urls, esp. the second one illuminate just where the bug is in Pydoc, but the fix recommended by the poster doesn't work. The problem happens even after downloading html help and pointing pydoc to it in the Pythondocs environment variable. I don't know enough to explore further, which is why I need a nice working help function :) I would think this would be an urgent fix for Python evangelism. rd ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-30 00:42 Message: Logged In: YES user_id=1326842 The problem is on your side. You should set the PYTHONDOCS environment variable to the root directory of the html documentation, eg.: PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2 and not: PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2\ref ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-05-29 22:30 Message: Logged In: YES user_id=341410 >From what I understand, HTML help hasn't shipped with Python on Windows for a few releases (likely around the time that .chm help files started shipping). If you've got html help files installed, and it's still not picking them up, could you dig deeper into why this is the case. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-29 22:24 Message: Logged In: YES user_id=849994 Okay, reopening. ---------------------------------------------------------------------- Comment By: BartlebyScrivener (bscrivener) Date: 2006-05-29 22:19 Message: Logged In: YES user_id=1523094 Sorry, if I was unclear. IDLE is not third party, is it? So I'm saying that on Windows XP, using the install from Python.org help() is BROKEN. Search in the Python Google group and you'll find many other references to same. Pydoc no longer provides help on topic or keywords. It will do modules. In short it's PYDOC that is broken, not Pythonwin IDE. Thanks, rick ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-29 21:00 Message: Logged In: YES user_id=849994 Closing as 3rd party. ---------------------------------------------------------------------- Comment By: BartlebyScrivener (bscrivener) Date: 2006-05-21 00:51 Message: Logged In: YES user_id=1523094 help('topic') or help('keyword') doesn't work in IDLE or Pythonwin IDE ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-05-20 07:00 Message: Logged In: YES user_id=341410 Since you are using the Pythonwin IDE, which was written and is supported by Mark Hammond via the pywin32 project, perhaps you should be visiting his project page instead: http://sf.net/projects/pywin32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470 From noreply at sourceforge.net Mon Jun 5 00:16:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 15:16:06 -0700 Subject: [ python-Bugs-1500293 ] Memory leak in subprocess module Message-ID: Bugs item #1500293, was opened at 2006-06-04 03:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&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: Closed >Resolution: Fixed Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Peter ? strand (astrand) Summary: Memory leak in subprocess module Initial Comment: The memory leak is in _subprocess module in functions getint and gethandle. They forget to decref the objects returned by PyObject_GetAttrString(). The bug is present in version 2.4 as well as in the trunk. Few more bugs in the subprocess module that I found while looking for the leak: - class STARTUPINFO is missing a wShowWindow attribute (this is hidden because _subprocess.CreateProcess() ignores most of the exceptions) - _execute_child() had a nonsensical test (if not None in tuple_of_posible_file_handles) - _execute_child() is assigning attributes to a default_startupinfo, which isn't used if user supplies another one. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-04 22:16 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 46651, 46652. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 From noreply at sourceforge.net Mon Jun 5 00:16:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 15:16:29 -0700 Subject: [ python-Bugs-1497962 ] Leak in tarfile.py Message-ID: Bugs item #1497962, was opened at 2006-05-31 06:42 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&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: Pending Resolution: None Priority: 5 Submitted By: Jens J?rgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in tarfile.py Initial Comment: There is a leak when using the tarfile module and the extractfile method. Here is a simple example: $ echo "grrr" > x.txt $ tar cf x.tar x.txt $ python Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> import tarfile >>> tar = tarfile.open('x.tar', 'r') >>> f = tar.extractfile('x.txt') >>> f.read() 'grrr\n' >>> del f >>> gc.set_debug(gc.DEBUG_LEAK) >>> print gc.collect() gc: collectable gc: collectable gc: collectable 3 >>> print gc.garbage [, {'name': 'x.txt', 'read': >, 'pos': 0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset': 512L, 'linebuffer': '', 'size': 5L}, >] >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-01 23:09 Message: Logged In: YES user_id=31435 There's no evidence of a leak here -- quite the contrary. As the docs say, DEBUG_LEAK implies DEBUG_SAVEALL, and DEBUG_SAVEALL results in _all_ cyclic trash getting appended to gc.garbage. If you don't mess with gc.set_debug(), you'll discover that gc.garbage is empty at the end. In addition, note that the DEBUG_LEAK output plainly says: gc: collectable ... That's also telling you that it found collectable cyclic trash (which it would have reclaimed had you not forced it to get appended to gc.garbage instead). If gc had found uncollectable cycles, these msgs would have started with gc: uncollectable ... instead. Most directly, if I run your tarfile open() and file extraction in an infinite loop (without messing with gc.set_debug()), the process memory use does not grow over time. Unless you have other evidence of an actual leak, this report should be closed without action. Yes, there are reference cycles here, but they're of kinds cyclic gc reclaims. ---------------------------------------------------------------------- Comment By: Jens J?rgen Mortensen (jensj) Date: 2006-06-01 20:08 Message: Logged In: YES user_id=716463 Problem is that the ExfileObject hat an attribute (self.read) that is a method bound to itself (self._readsparse or self._readnormal). One solution is to add "del self.read" to the close method, but someone might forget to close the object and still get the leak. Another solution is to change the end of __init__ to: if tarinfo.issparse(): self.sparse = tarinfo.sparse else: self.sparse = None and add a read method: def read(self, size=None): if self.sparse is None: return self._readnormal(size) else: return self._readsparse(size) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470 From noreply at sourceforge.net Mon Jun 5 00:17:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 15:17:30 -0700 Subject: [ python-Bugs-1500179 ] re.escape incorrectly escape literal. Message-ID: Bugs item #1500179, was opened at 2006-06-03 19:32 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&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: Regular Expressions Group: Python 2.4 Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Baptiste Lepilleur (blep) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.escape incorrectly escape literal. Initial Comment: Using Python 2.4.2. Here is a small programm excerpt that reproduce the issue (attached): --- import re literal = r'E:\prg\vc' print 'Expected:', literal print 'Actual:', re.sub('a', re.escape(literal), 'a' ) assert re.sub('a', re.escape(literal), 'a' ) == literal --- And the output of the sample: --- Expected: E:\prg\vc Actual : E\:\prg\vc Traceback (most recent call last): File "re_escape_bug.py", line 5, in ? assert re.sub('a', re.escape(literal), 'a' ) == literal AssertionError --- Looking at regular expression syntax of python documentation I don't see why ':' is escaped as '\:'. Baptiste. ---------------------------------------------------------------------- Comment By: Baptiste Lepilleur (blep) Date: 2006-06-03 21:45 Message: Logged In: YES user_id=196852 You are correct. Though, the 'repl' string parameter is not a literal string and is interpreted. The correct escape function to preserve the literal is literal.replace('\\','\\\\') not re.escape(). It would preserve any interpretation of the repl pattern. I believe this fact should be clearly stated in the documentation as it is not that obvious. The following assertion pass: --- import re literal = r'e:\prg\vc\1' assert re.sub( '(a+)', literal.replace('\\','\\\\'), 'aabac' ) == (literal+'b'+literal+'c') --- In the above example neither \v nor \1 are interpreted. Regards, Baptiste. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 20:27 Message: Logged In: YES user_id=11375 The assertion is wrong, I think. The signature is re.sub(pattern, replacement, string), so the assertion is replacing 'a' with re.escape(literal), which is obviously not going to equal literal. re.escape() puts a backslash in front of all non-alphanumeric characters; ':' is non-alphanumeric, so it will be escaped. The regex parser will ignore unknown escapes, so \: is the same as : -- the redundant escaping is harmless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470 From noreply at sourceforge.net Mon Jun 5 03:19:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 18:19:59 -0700 Subject: [ python-Bugs-912845 ] urllib2 checks for http return code 200 only. Message-ID: Bugs item #912845, was opened at 2004-03-09 11:32 Message generated for change (Comment added) made by heresiarch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912845&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ahmed F. (oneofone) Assigned to: A.M. Kuchling (akuchling) Summary: urllib2 checks for http return code 200 only. Initial Comment: from urllib2 import * req = Request("http://someurl/page.html", headers={'range: bytes=%s':'20-40'}) result = urlopen(req) will die with something like : File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib/python2.3/urllib2.py", line 412, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 206: Partial Content line 892 in {PATH}/urllib2.py should be changed from : if code == 200: to if code in [200, 206]: peace ---------------------------------------------------------------------- Comment By: Drew (heresiarch) Date: 2006-06-04 20:19 Message: Logged In: YES user_id=1534250 While it's good that 200 and 206 are not considered errors, what about 201-205? Per the HTTP RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2) all 2xx codes should be considered successful responses and probably shouldn't trigger errors. Thanks! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 08:19 Message: Logged In: YES user_id=11375 Applied to CVS; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912845&group_id=5470 From noreply at sourceforge.net Mon Jun 5 18:33:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 09:33:29 -0700 Subject: [ python-Feature Requests-1491485 ] str.startswith/endswith could take a tuple? Message-ID: Feature Requests item #1491485, was opened at 2006-05-19 05:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: str.startswith/endswith could take a tuple? Initial Comment: In the same way that exceptions can have a tuple of types specified and isinstance can take a tuple of types, str.startswith and endswith could take a tuple of possible prefixes/suffixes. One use-case:: if filename.endswith(('jpg', 'gif', 'png')): # ... vs: if (filename.endswith('jpg') or filename.endswith ('gif') or filename.endswith('png')): #... Obviously it's not a huge improvement in clarity, but it does seem to be an improvement to me. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-05 11:33 Message: Logged In: YES user_id=80475 The previous comment was just information. I am +1 on the proposal because the use case is so common and the proposed form is concise, clear, and natural. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-05-19 15:58 Message: Logged In: YES user_id=80475 FWIW, in Py2.5, this would be written: if any(filename.startswith(s) for s in suffixes): . . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470 From noreply at sourceforge.net Mon Jun 5 18:40:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 09:40:29 -0700 Subject: [ python-Feature Requests-1501108 ] Add write buffering to gzip Message-ID: Feature Requests item #1501108, was opened at 2006-06-05 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1501108&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: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add write buffering to gzip Initial Comment: A series of write() calls is dog slow compared to building-up a pool of data and then writing it in larger batches. The attached script demonstrates the speed-up potential. It compares a series of GzipFile.write() calls to an alternate approach using cStringIO.write() calls followed by a GzipFile.write(sio.getvalue()). On my box, there is a three-fold speed-up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1501108&group_id=5470 From noreply at sourceforge.net Mon Jun 5 19:10:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 10:10:03 -0700 Subject: [ python-Bugs-1501122 ] Lang ref '<' description in 5.9 not consistent with __lt__ Message-ID: Bugs item #1501122, was opened at 2006-06-05 12:10 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=1501122&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: Lang ref '<' description in 5.9 not consistent with __lt__ Initial Comment: >From the reference manual section 5.9: "The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily." The last sentence may apply to built-in types, but '<' may be evaluated via __lt__ for user defined types, and there are no such restrictions as I read the documentation. If this section is only referring to built-in types it shuld be clearly stated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501122&group_id=5470 From noreply at sourceforge.net Mon Jun 5 21:10:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 12:10:10 -0700 Subject: [ python-Bugs-1470026 ] distutils.core: link to list of Trove classifiers Message-ID: Bugs item #1470026, was opened at 2006-04-13 15:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470026&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Ansel Halliburton (anseljh) >Assigned to: A.M. Kuchling (akuchling) Summary: distutils.core: link to list of Trove classifiers Initial Comment: In 10.1 (distutils.core), it would be nice to have a link to the full list of Trove classifiers. There is already a place for such a link in the table for the setup() method; search for "XXX link to better definition". Here is the link to add: http://www.python.org/pypi?:action=list_classifiers I would say "a list of strings; see http://www.python.org/pypi?:action=list_classifiers for a list of all possible values" ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-05 15:10 Message: Logged In: YES user_id=11375 Thanks for pointing this out. I've added a link to the classifier list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470026&group_id=5470 From noreply at sourceforge.net Mon Jun 5 22:45:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 13:45:51 -0700 Subject: [ python-Bugs-1501223 ] Possible buffer overflow in Python/sysmodule.c Message-ID: Bugs item #1501223, was opened at 2006-06-05 13:45 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=1501223&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible buffer overflow in Python/sysmodule.c Initial Comment: Line 1070 (along with lines 1075 and 1080) have sprintf() calls that store "cp%d" into a buffer that is 10 characters long. But an unsigned int could be 32 bits, which means 10 digits on its own. Add in the need for a null byte and the "cp" part and it would seem the buffer is 3 characters short. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 From noreply at sourceforge.net Mon Jun 5 23:02:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 14:02:41 -0700 Subject: [ python-Bugs-1501223 ] Possible buffer overflow in Python/sysmodule.c Message-ID: Bugs item #1501223, was opened at 2006-06-05 16:45 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible buffer overflow in Python/sysmodule.c Initial Comment: Line 1070 (along with lines 1075 and 1080) have sprintf() calls that store "cp%d" into a buffer that is 10 characters long. But an unsigned int could be 32 bits, which means 10 digits on its own. Add in the need for a null byte and the "cp" part and it would seem the buffer is 3 characters short. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-05 17:02 Message: Logged In: YES user_id=31435 So make it bigger ;-) In reality, I don't believe any Windows "code page" needs more than 5 digits, so there are actually a couple bytes to spare, but boosting the buffer size wouldn't hurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 From noreply at sourceforge.net Mon Jun 5 23:49:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 14:49:27 -0700 Subject: [ python-Bugs-1493322 ] bsddb: db never opened for writing forgets its size Message-ID: Bugs item #1493322, was opened at 2006-05-22 19:30 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&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: Steven Taschuk (staschuk) Assigned to: Gregory P. Smith (greg) Summary: bsddb: db never opened for writing forgets its size Initial Comment: See the attached program; on my machine, its output is as described therein. That is: if a bsddb hash database is opened read-only, and has never been opened for writing (except when first created), then calling len() on the database object returns the correct value the first time, but zero on the second and later calls. Opening the database for writing once seems to eliminate the problem; even when it is opened read-only later, len() behaves as expected. My machine runs Linux 2.6.16, glibc 2.3.4, Python 2.4.3, and Berkeley DB 4.3.28. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-05 14:49 Message: Logged In: YES user_id=413 this sounds the same as pybsddb bug 1184012. i'm looking into it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-22 22:47 Message: Logged In: YES user_id=33168 Greg, is this a known issue? Any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&group_id=5470 From noreply at sourceforge.net Tue Jun 6 00:34:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 15:34:09 -0700 Subject: [ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii Message-ID: Bugs item #1501291, was opened at 2006-06-05 16:34 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=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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470 From noreply at sourceforge.net Tue Jun 6 01:58:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 16:58:55 -0700 Subject: [ python-Bugs-1501223 ] Possible buffer overflow in Python/sysmodule.c Message-ID: Bugs item #1501223, was opened at 2006-06-05 13:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&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: Windows Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible buffer overflow in Python/sysmodule.c Initial Comment: Line 1070 (along with lines 1075 and 1080) have sprintf() calls that store "cp%d" into a buffer that is 10 characters long. But an unsigned int could be 32 bits, which means 10 digits on its own. Add in the need for a null byte and the "cp" part and it would seem the buffer is 3 characters short. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-05 16:58 Message: Logged In: YES user_id=357491 OK, I will! =) Just had to wait until I had time at work to do it. HEAD for rev. 46682 and for 2.4 there is rev. 46683 has the buffer increase. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-05 14:02 Message: Logged In: YES user_id=31435 So make it bigger ;-) In reality, I don't believe any Windows "code page" needs more than 5 digits, so there are actually a couple bytes to spare, but boosting the buffer size wouldn't hurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501223&group_id=5470 From noreply at sourceforge.net Tue Jun 6 02:00:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 17:00:55 -0700 Subject: [ python-Bugs-1493322 ] bsddb: db never opened for writing forgets its size Message-ID: Bugs item #1493322, was opened at 2006-05-22 19:30 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Gregory P. Smith (greg) Summary: bsddb: db never opened for writing forgets its size Initial Comment: See the attached program; on my machine, its output is as described therein. That is: if a bsddb hash database is opened read-only, and has never been opened for writing (except when first created), then calling len() on the database object returns the correct value the first time, but zero on the second and later calls. Opening the database for writing once seems to eliminate the problem; even when it is opened read-only later, len() behaves as expected. My machine runs Linux 2.6.16, glibc 2.3.4, Python 2.4.3, and Berkeley DB 4.3.28. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-05 17:00 Message: Logged In: YES user_id=413 fixed in python svn rev 46684. i'll backport this one to python 2.4 as well. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-06-05 14:49 Message: Logged In: YES user_id=413 this sounds the same as pybsddb bug 1184012. i'm looking into it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-22 22:47 Message: Logged In: YES user_id=33168 Greg, is this a known issue? Any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&group_id=5470 From noreply at sourceforge.net Tue Jun 6 02:06:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 17:06:46 -0700 Subject: [ python-Bugs-1477450 ] test_bsddb skipped -- Failed to load on HP-UX 11.2i Message-ID: Bugs item #1477450, was opened at 2006-04-27 00:07 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&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: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) >Summary: test_bsddb skipped -- Failed to load on HP-UX 11.2i Initial Comment: Hi , Iam building Python-2.4.3 on HP-UX 11.2i , while testing its npt able import the _bsddb.sl module and hence that is skipped . In previous versions the test is passing. what can be done to pass the test?. Thanks, shashi ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 21:45 Message: Logged In: YES user_id=33168 Support for db-4.4 was added late. I believe the only thing you need to do to enable it is modify setup.py, line 496 (proabably that line) should be: max_db_ver = (4, 4) >From what I've seen, you are much better off with newer versions of bdb. As for the seg faults, I wonder if your ulimits are too low. What is the output of: ulimit -a Also, can you attach the output of ./python Lib/test/regrtest.py -v -u bsddb test_subprocess and do the same for test_bsddb3 (or test_bsddb whichever is crashing). ---------------------------------------------------------------------- Comment By: shashi (shashikala) Date: 2006-04-27 21:35 Message: Logged In: YES user_id=1506183 Hi, I am having db-4.4.20 installed, It looks like Python doesn't support 4.4.20 version , hence i built 4.2.52 , now I am getting segmentation fault (memory fault) and its dumping core . I want to know the versions of the dependent libraries Python-2.4.3 supports and also while testing the Python test_subprocess.py is also dumping core. I am sending out the outputs of test_bsddb and test_subprocess. Thanks, shashi ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 20:11 Message: Logged In: YES user_id=33168 The test can't pass without being able to import _bsddb.sl. Why can't this file be imported? When you build python it should print out what version of bsddb is found. It will look something like this: running build running build_ext db.h: found (4, 1) in /usr/include db lib: using (4, 1) db-4.1 What version of bsddb was found on your box? Are there compile errors when building bsddb? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 From noreply at sourceforge.net Mon Jun 5 12:52:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 03:52:38 -0700 Subject: [ python-Feature Requests-1497532 ] C API to retain GIL during Python Callback Message-ID: Feature Requests item #1497532, was opened at 2006-05-30 14:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: C API to retain GIL during Python Callback Initial Comment: [Split off from closed 1453341, which desired a Python- level API. This request is for a C API, to be used in C extensions that call back into Python.] I think it would be very useful to have an API that would tell Python not to release the GIL during call backs to Python code, until it is told again (back in C code) that it is ok to do so. I'd like to quote Tim Peters, who explains it better than me (private conversation, June 2005): ---------- It would be more feasible to patch Python, introducing a way to tell the interpreter not to allow other _Python_ threads to run. It has such a mechanism already (the GIL -- the global interpreter lock), but as soon as C code calls back into Python, the interpreter may release the GIL and give ownership of it to a different thread. I think it would be pretty easy to introduce a Python C API to say "don't allow other Python threads to run until I tell you otherwise". ---------- The Use Case arose with a multi-threading problem in ZODB's Connection, where the C code must ensure that no other thread runs Python code accessing an object BUT the own thread needs to call back into Python. Any other mechanism that came to my mind would either require to halt *all* others threads, or run into race conditions. Best regards, Martin Gfeller ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-05 12:52 Message: Logged In: YES user_id=21627 Would you like to work on a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&group_id=5470 From noreply at sourceforge.net Tue Jun 6 02:23:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 17:23:41 -0700 Subject: [ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster Message-ID: Bugs item #1501330, was opened at 2006-06-05 17:23 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=1501330&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: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: failure of test_ossaudiodev; elapsed time .1 sec faster Initial Comment: I am getting a consistent failure of test_ossaudiodev on Ubuntu Hoary on an HP xw4300 Workstation. The failure is that the test is printing out "elapsed time: 3.0 sec" while the test expects 3.1 sec. I don't know anything about sound recordings so I don't know if there is any way to calculate the expected length of the test sound file and thus know that this is a true error or the test is just working faster than normally expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470 From noreply at sourceforge.net Tue Jun 6 02:30:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 17:30:16 -0700 Subject: [ python-Feature Requests-1491485 ] str.startswith/endswith could take a tuple? Message-ID: Feature Requests item #1491485, was opened at 2006-05-19 05:24 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Lynn (tlynn) >Assigned to: Georg Brandl (gbrandl) Summary: str.startswith/endswith could take a tuple? Initial Comment: In the same way that exceptions can have a tuple of types specified and isinstance can take a tuple of types, str.startswith and endswith could take a tuple of possible prefixes/suffixes. One use-case:: if filename.endswith(('jpg', 'gif', 'png')): # ... vs: if (filename.endswith('jpg') or filename.endswith ('gif') or filename.endswith('png')): #... Obviously it's not a huge improvement in clarity, but it does seem to be an improvement to me. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-05 19:30 Message: Logged In: YES user_id=80475 Georg, would you like to implement this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-05 11:33 Message: Logged In: YES user_id=80475 The previous comment was just information. I am +1 on the proposal because the use case is so common and the proposed form is concise, clear, and natural. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-05-19 15:58 Message: Logged In: YES user_id=80475 FWIW, in Py2.5, this would be written: if any(filename.startswith(s) for s in suffixes): . . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470 From noreply at sourceforge.net Tue Jun 6 11:48:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 02:48:19 -0700 Subject: [ python-Feature Requests-1497532 ] C API to retain GIL during Python Callback Message-ID: Feature Requests item #1497532, was opened at 2006-05-30 14:58 Message generated for change (Comment added) made by gfe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: C API to retain GIL during Python Callback Initial Comment: [Split off from closed 1453341, which desired a Python- level API. This request is for a C API, to be used in C extensions that call back into Python.] I think it would be very useful to have an API that would tell Python not to release the GIL during call backs to Python code, until it is told again (back in C code) that it is ok to do so. I'd like to quote Tim Peters, who explains it better than me (private conversation, June 2005): ---------- It would be more feasible to patch Python, introducing a way to tell the interpreter not to allow other _Python_ threads to run. It has such a mechanism already (the GIL -- the global interpreter lock), but as soon as C code calls back into Python, the interpreter may release the GIL and give ownership of it to a different thread. I think it would be pretty easy to introduce a Python C API to say "don't allow other Python threads to run until I tell you otherwise". ---------- The Use Case arose with a multi-threading problem in ZODB's Connection, where the C code must ensure that no other thread runs Python code accessing an object BUT the own thread needs to call back into Python. Any other mechanism that came to my mind would either require to halt *all* others threads, or run into race conditions. Best regards, Martin Gfeller ---------------------------------------------------------------------- >Comment By: Martin Gfeller (gfe) Date: 2006-06-06 11:48 Message: Logged In: YES user_id=884167 This would unfortunately be way beyond my competence in C programming. I would only be able to change the existing code to use the API, if it were available. Sorry! Martin ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-05 12:52 Message: Logged In: YES user_id=21627 Would you like to work on a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&group_id=5470 From noreply at sourceforge.net Tue Jun 6 13:19:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 04:19:14 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 12:19 Message generated for change (Comment added) made by theaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- >Comment By: Tim Heaney (theaney) Date: 2006-06-06 11:19 Message: Logged In: YES user_id=827666 I'm not sure I know how. It looks like the downloaded files have the following shebang lines Tools/scripts/pydoc => #!/usr/bin/env python Tools/scripts/idle => #! /usr/bin/env python Lib/smtpd.py => #! /usr/bin/env python Misc/python-config.in => #!@BINDIR@/python whereas the installed files have /usr/local/bin/pydoc => #!/usr/local/bin/python /usr/local/bin/idle => #!/usr/local/bin/python /usr/local/bin/smtpd.py => #!/usr/local/bin/python /usr/local/bin/python-config => #!/usr/local/bin/python so they're already getting rewritten somewhere. We want both their names and their shebang lines to have the version /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5 It seems that python-config appears in the Makefile, so adding something like sed -e "s, at BINDIR@,$(BINDIR)," < $(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE) $(INSTALL_SCRIPT) python-config $(BINDIR)/python-config$(VERSION)$(EXE) rm python-config to Makefile.pre.in in an altlibainstall section or something might be all we need for that. The others are named in setup.py # Scripts to install scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] but I haven't worked out where they get rewritten or installed yet. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 20:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Tue Jun 6 17:14:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 08:14:28 -0700 Subject: [ python-Bugs-1501699 ] method format of logging.Formatter caches incorrectly Message-ID: Bugs item #1501699, was opened at 2006-06-06 17:14 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=1501699&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: None Status: Open Resolution: None Priority: 5 Submitted By: Boris Lorbeer (blorbeer) Assigned to: Nobody/Anonymous (nobody) Summary: method format of logging.Formatter caches incorrectly Initial Comment: The format method of logging.Formatter is buggy in that it doesn't call the method formatException if the cache record.exc_text is set. If you have two Formatters that should format the same log record differently (i.e. each has its own overriding formatException method), the formatException method of the second formatter will never be called because the cache has been set by the first formatter. The proper way of using the cache is IMHO to check the cache only in the method formatException of logging.Formatter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 From noreply at sourceforge.net Tue Jun 6 21:17:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 12:17:21 -0700 Subject: [ python-Bugs-791410 ] Make logging consistent in the standard library Message-ID: Bugs item #791410, was opened at 2003-08-19 18:32 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791410&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: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthew Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: Make logging consistent in the standard library Initial Comment: Logging should be consistent in the standard library. Standard library modules that currently define their own logging functions should be updated to use the standard 'logging' module instead. Such modules include (not necessarily a complete list): asyncore.py BaseHTTPServer.py cgi.py doctest.py imaplib.py unittest.py distutils package ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-06 19:17 Message: Logged In: YES user_id=849994 Now that this is a Summer of Code project, I guess this issue can be closed. ---------------------------------------------------------------------- Comment By: Matthew Barnes (mfbarnes) Date: 2003-09-29 06:25 Message: Logged In: YES user_id=843448 Remove doctest.py and unittest.py from this list. Steve Purcell and Tim Peters have indicated that logging is not applicable to those modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791410&group_id=5470 From noreply at sourceforge.net Tue Jun 6 21:20:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 12:20:55 -0700 Subject: [ python-Bugs-1241006 ] Distutils does not use logging Message-ID: Bugs item #1241006, was opened at 2005-07-19 17:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&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: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils does not use logging Initial Comment: distutils.log creates its own PEP 282-like logger class, which is fine from the distutils point of view, but not exactly brilliant if you want to intercept the calls using the logging facilities that have been in python since 2.3. Recommended fix: If, in fact, distutils.log has to be kept compatible with 2.1 as is claimed in the source file then something along the lines of: try: import logging _global_log = logging.getLogger('distutils') except ImportError: #insert current Log class definition here _global_log = Log() Also, changing the values for DEBUG, INFO, WARN, ERROR and FATAL to be the same as the ones in logging.py is probably a good idea. The distutils logger should have its own formatter that prints out lines as the thing currently does, but this formatter should be set within the code for setup() rather than in the log module. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-06 19:20 Message: Logged In: YES user_id=849994 This should be resolved as part of the Summer of Code project this year. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-06 18:00 Message: Logged In: YES user_id=21627 It needs to stay backwards-compatible with 2.1, so you need to fallback if logging is not available. No need to hurry, though. ---------------------------------------------------------------------- Comment By: Giles Antonio Radford (mewf) Date: 2005-08-06 16:46 Message: Logged In: YES user_id=859703 Yes, though I'm offline for most of this week, I'll try and give it a go for next weekend. Does it need to be kept compatible with python 2.1? Or is 2.3 and above OK? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-06 12:45 Message: Logged In: YES user_id=21627 Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241006&group_id=5470 From noreply at sourceforge.net Wed Jun 7 01:57:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 16:57:54 -0700 Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation Message-ID: Bugs item #1501934, was opened at 2006-06-07 01:57 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=1501934&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Wouters (twouters) Assigned to: Neal Norwitz (nnorwitz) Summary: incorrect LOAD/STORE_GLOBAL generation Initial Comment: Python 2.5 compiles the following piece of code differently than Python 2.4: g = 1 def f(): g += 1 In Python 2.4, this raises an UnboundLocalError. In current svn trunk, it will increment the global g by 1. (dis.dis shows that it actually compiles into LOAD/STORE_GLOBAL opcodes.) It seems the compiler doesn't treat augmented assignment as assignment for the purpose of determining locals, as this still fails correctly: g = 1 def f(): g += 1 g = 5 I can't find where this optimization happens nowadays, but it feels like a short fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470 From noreply at sourceforge.net Wed Jun 7 05:42:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 20:42:07 -0700 Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation Message-ID: Bugs item #1501934, was opened at 2006-06-06 23:57 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: Thomas Wouters (twouters) >Assigned to: Jeremy Hylton (jhylton) Summary: incorrect LOAD/STORE_GLOBAL generation Initial Comment: Python 2.5 compiles the following piece of code differently than Python 2.4: g = 1 def f(): g += 1 In Python 2.4, this raises an UnboundLocalError. In current svn trunk, it will increment the global g by 1. (dis.dis shows that it actually compiles into LOAD/STORE_GLOBAL opcodes.) It seems the compiler doesn't treat augmented assignment as assignment for the purpose of determining locals, as this still fails correctly: g = 1 def f(): g += 1 g = 5 I can't find where this optimization happens nowadays, but it feels like a short fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470 From noreply at sourceforge.net Wed Jun 7 14:49:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 05:49:23 -0700 Subject: [ python-Bugs-1501699 ] method format of logging.Formatter caches incorrectly Message-ID: Bugs item #1501699, was opened at 2006-06-06 11:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&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: None Status: Open Resolution: None Priority: 5 Submitted By: Boris Lorbeer (blorbeer) >Assigned to: Vinay Sajip (vsajip) Summary: method format of logging.Formatter caches incorrectly Initial Comment: The format method of logging.Formatter is buggy in that it doesn't call the method formatException if the cache record.exc_text is set. If you have two Formatters that should format the same log record differently (i.e. each has its own overriding formatException method), the formatException method of the second formatter will never be called because the cache has been set by the first formatter. The proper way of using the cache is IMHO to check the cache only in the method formatException of logging.Formatter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 From noreply at sourceforge.net Wed Jun 7 15:07:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 06:07:39 -0700 Subject: [ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster Message-ID: Bugs item #1501330, was opened at 2006-06-05 20:23 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&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: Brett Cannon (bcannon) >Assigned to: Greg Ward (gward) Summary: failure of test_ossaudiodev; elapsed time .1 sec faster Initial Comment: I am getting a consistent failure of test_ossaudiodev on Ubuntu Hoary on an HP xw4300 Workstation. The failure is that the test is printing out "elapsed time: 3.0 sec" while the test expects 3.1 sec. I don't know anything about sound recordings so I don't know if there is any way to calculate the expected length of the test sound file and thus know that this is a true error or the test is just working faster than normally expected. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-07 09:04 Message: Logged In: YES user_id=11375 Yes, the length is calculable -- you have N bytes in the file, with so many bits per sample and so many samples per second. Perhaps the driver now buffers more and the write() returns earlier? Or you could try printing the exact duration without rounding; maybe it's 3.0999999 or something and the print is just truncating. Assigning to Greg Ward, in case he gets around to looking at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470 From noreply at sourceforge.net Wed Jun 7 22:19:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 13:19:48 -0700 Subject: [ python-Bugs-1491468 ] argvemulator doesn't work on intel mac Message-ID: Bugs item #1491468, was opened at 2006-05-19 11:49 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491468&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: Macintosh Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: argvemulator doesn't work on intel mac Initial Comment: According to a report on macpython-sig the argvemulator module doesn't work on intel macs due to endianness issues. This seems to be a problem in aepack/aetypes. The attached version of argvemulator should fix the problem by not using aepack and friends and was written by has. I know to little of AppleEvents and the aepack module to actually fix this at this point in time. I propose to replace argvemulator by the attached version. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-07 22:19 Message: Logged In: YES user_id=580910 Fixed in revision 46727. I've merged the basic AE-handling of the attached patch with the original eventloop code. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-19 20:32 Message: Logged In: YES user_id=580910 The new version seems to be not entirely equivalent to the current version, I was using argvemulator in the .app wrapper for IDLE and that now behaves differently: before it opened quite slowly (maybe just due to my machine), now it doesn't make progress until the first time you quit IDLE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491468&group_id=5470 From noreply at sourceforge.net Wed Jun 7 22:58:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 13:58:36 -0700 Subject: [ python-Bugs-1502517 ] crash in expat when compiling with --enable-profiling Message-ID: Bugs item #1502517, was opened at 2006-06-07 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=1502517&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: crash in expat when compiling with --enable-profiling Initial Comment: On MacOSX 10.4.6, Xcode 2.3 (but appearently also on earlier versions of Xcode) the script below causes a segmentation fault in expat when python is compiled with --enable-profiling. The script (to be run from the root of the python source tree) import plistlib p = plistlib.PlistParser() print p.parse(open('Mac/scripts/BuildApplet.plist')) The gdb session: $ gdb ./python.exe GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:01:44 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done (gdb) r t.py Starting program: /Users/ronald/Python/python-trunk/build/ python.exe t.py Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 0x01320285 in poolGrow (pool=0x600270) at /Users/ronald/Python/ python-trunk/Modules/expat/xmlparse.c:6018 6018 pool->blocks = (BLOCK *) (gdb) and backtrace: (gdb) where #0 0x01320285 in poolGrow (pool=0x600270) at /Users/ronald/ Python/python-trunk/Modules/expat/xmlparse.c:6018 #1 0x0132772f in doProlog (parser=0x620640, enc=0x1345760, s=0x185503e "\"-//Apple Computer//DTD PLIST 1.0//EN\" \"http:// www.apple.com/DTDs/PropertyList-1.0.dtd\">\n\n\n\tCFBundleDevelopmentRegion\n \tEnglish\n\tCFBundleDocu"..., end=0x1855652 "", tok=12, next=0x1855064 " \"http:// www.apple.com/DTDs/PropertyList-1.0.dtd\">\n\n\n\tCFBundleDevelopmentRegion\n \tEnglish\n\tCFBundleDocumentTypes\n\t\n\t\t\n\t\t\t<"..., nextPtr=0x620658, haveMore=1 '\001') at /Users/ronald/Python/python-trunk/Modules/ expat/xmlparse.c:5935 #2 0x0132d5a5 in prologInitProcessor (parser=0x620640, s=0x1855000 "\n\n\n\n\tCFBundleDevelo"..., end=0x1855652 "", nextPtr=0x620658) at /Users/ronald/Python/ python-trunk/Modules/expat/xmlparse.c:3551 #3 0x0131f7c4 in XML_ParseBuffer (parser=0x620640, len=1618, isFinal=0) at /Users/ronald/Python/python-trunk/Modules/expat/ xmlparse.c:1562 #4 0x01319bb2 in xmlparse_ParseFile (self=0x129efa8, f=0x12991d0) at /Users/ronald/Python/python-trunk/Modules/ pyexpat.c:1025 #5 0x0006de12 in PyEval_EvalFrameEx (f=0x6219c0, throwflag=0) at ../Python/ceval.c:3553 #6 0x0006df07 in PyEval_EvalFrameEx (f=0x61a860, throwflag=0) at ../Python/ceval.c:3650 #7 0x0006e71a in PyEval_EvalCodeEx (co=0x1298380, globals=0x1241ae0, locals=0x1241ae0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../ Python/ceval.c:2832 #8 0x0006e8d9 in PyEval_EvalCode (co=0x1298380, globals=0x1241ae0, locals=0x1241ae0) at ../Python/ceval.c:494 #9 0x00091f2f in PyRun_FileExFlags (fp=0xa000bd00, filename=0xbffffbb7 "t.py", start=257, globals=0x1241ae0, locals=0x1241ae0, closeit=1, flags=0xbffffa7c) at ../Python/ pythonrun.c:1230 #10 0x00092300 in PyRun_SimpleFileExFlags (fp=0xa000bd00, filename=0xbffffbb7 "t.py", closeit=1, flags=0xbffffa7c) at ../Python/ pythonrun.c:854 #11 0x00005b6f in Py_Main (argc=1, argv=0xbffffb00) at ../Modules/ main.c:494 #12 0x000023c5 in _start (argc=2, argv=0xbffffb00, envp=0xbffffb0c) at /SourceCache/Csu/Csu-58.1.1/crt.c:272 #13 0x000022cd in start () ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1502517&group_id=5470 From noreply at sourceforge.net Wed Jun 7 23:01:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 14:01:17 -0700 Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails, configure is odd Message-ID: Bugs item #1486897, was opened at 2006-05-11 23:44 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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.5 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Christopher Knox (vizowl) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: OS X framework build for python 2.5 fails, configure is odd Initial Comment: The OS X framework build for python 2.5 does not install a dynamic library at /Library/Frameworks/Python.framework/Versions/2.5/Python where it should. The python2.5 executible does not run because it is trying to load this dynamic library. This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2. Also all of the extra modules (_CG extension, IDLE extra) fail to link because their link command is -lpython2.5 which is not what it should be for a framework build and even if it was correct for linking agianst a framework it would fil because the framework doesn't have its library anyway. Finally, the configure script behaves oddly in that it works fine, but if you change the parameters and rerun it it will fail unless you run 'make distclean' This is where it fails. checking whether mmap with MAP_ANON(YMOUS) works... yes configure: error: "libffi has not been ported to i686-apple-darwin8.6.1." Failed to configure _ctypes module ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-07 23:01 Message: Logged In: YES user_id=580910 I'm closing this bug and have opened a new one for the profiling issue, it seems to have nothing to do with frameworks. I'm also getting a crash with a plain unix build if I use the right libraries. See bug #1502517 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 15:20 Message: Logged In: YES user_id=580910 I've checked in a patch that makes it possible to use 'make install' to install a framework. --enable-profiling still doesn't work and I won't look into this anytime soon ;-( ---------------------------------------------------------------------- Comment By: Christopher Knox (vizowl) Date: 2006-05-23 20:11 Message: Logged In: YES user_id=1346203 Yeah - it works fine without --enable-profiling - I forgot that you said not to use it. I fear I am being less than helpful today. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 19:44 Message: Logged In: YES user_id=580910 Why do you try to use --enable-profiling with a framework install? Whenever I need such a special build I generally install a normal unix build in a temporary location. I know --enable-framework doesn't clean up after itself. It does work correctly in a seperate build directory though, that way you can just dump the build directory to clean up. BTW. Integrating 'make frameworkinstall' into 'make install' seems to be pretty easy, I might check in a patch later this week. --enable-profiling crashes for me too, I don't have time to look into this at the moment. ---------------------------------------------------------------------- Comment By: Christopher Knox (vizowl) Date: 2006-05-23 18:54 Message: Logged In: YES user_id=1346203 Sorry - it was too early in the morning here and I forgot about the frameworkinstall.... The frameworkinstall does not quite work. It looks like it installs everything critical and then fails on the MacPython stuff. Specifically, it fails here: /usr/bin/install -c -s ../../python.exe "/Library/Frameworks/ Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/ Python" ../../python.exe ./../scripts/BuildApplet.py \ --destroot "" \ --python /Library/Frameworks/Python.framework/Versions/2.5/ Resources/Python.app/Contents/MacOS/Python \ --output "/Applications/MacPython 2.5/Build Applet.app" \ ./../scripts/BuildApplet.py make[1]: *** [install_BuildApplet] Bus error make: *** [frameworkinstallapps] Error 2 However, I can still run the python interpeter - although when I exit the interpretor it says "mcount: gmon.out: Permission denied" frameworkinstall does overwrite the Current symlink - but I just fixed it manually. Also I noticed that make clean does not remove the actual dynamic library called 'Python' from the Python.framework directory in the build directory ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 18:26 Message: Logged In: YES user_id=580910 You shouldn't use make install, but make frameworkinstall. This is documented in Mac/OSX/README. I wouldn't mind seeing a patch that makes it possible to install a framework using 'make install', but that's very low on my todo-list. ---------------------------------------------------------------------- Comment By: Christopher Knox (vizowl) Date: 2006-05-23 17:41 Message: Logged In: YES user_id=1346203 I checked out rev 46110 and it is almost fixed. It builds correctly now - however the make install (or altinstall) does not copy the dynamic library into the framework. It is built into BUILD_ROOT/ Python.Framework/Versions/2.5/Python and after installation it should land up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but nothing is there. If I copy it over manually then the python2.5 interpeter will run. The 2.4 framework has a symlink from /Library/Frameworks/ Python.framework/Python to /Library/Frameworks/Python.framework/ Versions/2.4/Python The rest of my comment is more of an aside than a bug... The equivalent symlink exists in the built version of the 2.5 framework and it chould not (and does not currently) get transferred into /Library/ Frameworks/Python.framework. However, if someone wanted to upgrade from python2.4 to 2.5 then the symlink should also be updated - otherwise when people add the linker flag -framework Python to their builds it will keep linking against the 2.4 dynamic lib. Also I am not sure what happened with the build log - it is fine when I download it - but it doesn't matter now ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 14:13 Message: Logged In: YES user_id=580910 I've checked in a fix in revision 46103. Could you please test if this solves the problems for you? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 13:27 Message: Logged In: YES user_id=580910 I'm currently building the trunk and I'm seeing the same issue as you. The problem is caused by the checkin at revision 45232 by Martin van Loewis. This forces '-lpython2.5' onto the commandline for the linker when building extensions. I'm working on a patch that disables this feature for framework builds. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 13:07 Message: Logged In: YES user_id=580910 The configure failure in the orginal message is not a problem, that's libffi failing. Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I know of another one, but neither have been merged into the copy that's used by ctypes. The only effect of this is that you won't get ctypes. Could you test again without --enable-profiling? That's one flag I've never used and didn't test yet. BTW. the attached build log contains lots of NUL bytes, should it or has it been corrupted along the way? ---------------------------------------------------------------------- Comment By: Christopher Knox (vizowl) Date: 2006-05-15 19:13 Message: Logged In: YES user_id=1346203 Hi Neal, I checked out rev 46003 (the HEAD at the time) in a clean directory and used: ./configure --enable-profiling --enable-shared --enable-framework -- enable-universalsdk Unfortunately it failed in the same way it has the same problems in that it is linking with the flag -lpython2.5 when it should be a framework linking. I have attached the build log from after having built it once so you only see the linking. However, it does appear that the issue raised in bug # 1487105 is solved. It compiled fine on an intel mac it just has linking problems. Also I get exactly the same problem on a G5 Chris ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-15 08:25 Message: Logged In: YES user_id=33168 Christopher can you try with a current checkout? Ronald checked in lots of changes which I think include x86 support at svn rev 45997. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470 From noreply at sourceforge.net Wed Jun 7 23:11:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 14:11:39 -0700 Subject: [ python-Feature Requests-1491485 ] str.startswith/endswith could take a tuple? Message-ID: Feature Requests item #1491485, was opened at 2006-05-19 10:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Lynn (tlynn) Assigned to: Georg Brandl (gbrandl) Summary: str.startswith/endswith could take a tuple? Initial Comment: In the same way that exceptions can have a tuple of types specified and isinstance can take a tuple of types, str.startswith and endswith could take a tuple of possible prefixes/suffixes. One use-case:: if filename.endswith(('jpg', 'gif', 'png')): # ... vs: if (filename.endswith('jpg') or filename.endswith ('gif') or filename.endswith('png')): #... Obviously it's not a huge improvement in clarity, but it does seem to be an improvement to me. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-07 21:11 Message: Logged In: YES user_id=849994 I will, tomorrow. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-06 00:30 Message: Logged In: YES user_id=80475 Georg, would you like to implement this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-05 16:33 Message: Logged In: YES user_id=80475 The previous comment was just information. I am +1 on the proposal because the use case is so common and the proposed form is concise, clear, and natural. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-05-19 20:58 Message: Logged In: YES user_id=80475 FWIW, in Py2.5, this would be written: if any(filename.startswith(s) for s in suffixes): . . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470 From noreply at sourceforge.net Thu Jun 8 07:45:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 22:45:47 -0700 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 19:29 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&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.5 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-07 22:45 Message: Logged In: YES user_id=413 I've added the e.set_lk_detect(db.DB_LOCK_DEFAULT) To the _openDBEnv function so that at the very least the bad threaded behaviour is upgraded from a deadlock to an exception. I'm trying to decide if doing all the DeadlockWrap wrapping is worth it (and if theres an automatic python classish way to do it rather than manually identifying and wrapping all db calls) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:54 Message: Logged In: YES user_id=413 modifying bsddb/__init__.py to wrap all calls with DeadlockWrap will be a bit of a pita (but would be doable). I've attached an example wrapped_hammer.py that demonstrates the _openDBEnv change as well as DeadlockWrap wrapping to work properly. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:31 Message: Logged In: YES user_id=413 oh good i see you already suggested the simple thread calling lock_detect that I was about to suggest. :) regardless a thread isn't needed. see dbenv.set_lk_detect which tells BerkeleyDB to run deadlock detection automatically anytime a lock conflict occurs. http://www.sleepycat.com/docs/api_c/env_set_lk_detect.html Just add e.set_lk_detect(db.DB_LOCK_DEFAULT) to bsddb/__init__.py's _openDBEnv() function. That causes hammer.py to get DBLockDeadlockError exceptions as expected (dying if the main thread gets one). No lock_detect thread needed. The bsddb legacy interface in __init__.py could have all of its database accesses wrapped in the bsddb.dbutils.DeadlockWrap function. to prevent this. (testing now) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 20:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 18:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-05 18:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 12:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 10:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 09:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 07:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 00:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 00:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 23:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-27 22:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 16:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 11:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 15:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 12:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 12:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 12:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 11:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 10:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 09:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 09:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 16:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 01:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Thu Jun 8 07:51:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 22:51:09 -0700 Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3 Message-ID: Bugs item #1494314, was opened at 2006-05-24 06:51 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-07 22:51 Message: Logged In: YES user_id=413 eew yuck. yes use poll at the very least. we should also consider using epoll (linux) and kevent (bsd) in the future as both of those scale better than O(n) unlike select and poll. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 13:14 Message: Logged In: YES user_id=21627 A patch to replace internal_select with poll(2) where available is acceptable. The current version should be conditionally kept. That Windows doesn't have poll(2) is no problem: its select implementation supports arbitrarily large FDs (just like poll). Relaxing the IS_SELECTABLE usage to cases where select is actually going to be called is optional: there shouldn't be too many systems left without select where people still want to open many file descriptors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-05-31 15:27 Message: Logged In: YES user_id=31435 akuchling: No, poll() is not part of the Windows socket API. ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 14:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 11:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 07:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 07:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 07:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 06:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your current limit. Ulimits are enforced by the Linux kernel and can likely be configured system-wide in /etc/sysctl.cfg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 From noreply at sourceforge.net Thu Jun 8 10:03:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 01:03:29 -0700 Subject: [ python-Bugs-1502728 ] HP-UX shared library does not reference librt Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 10:42:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 01:42:09 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 12:53:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 03:53:18 -0700 Subject: [ python-Bugs-1502805 ] 'with' sometimes eats exceptions Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 12:57:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 03:57:17 -0700 Subject: [ python-Bugs-1350060 ] built-in method .__cmp__ Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 14:47:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 05:47:10 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 14:54:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 05:54:47 -0700 Subject: [ python-Bugs-1502728 ] HP-UX shared library does not reference librt Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 15:32:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 06:32:40 -0700 Subject: [ python-Bugs-1502805 ] 'with' sometimes eats exceptions Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 15:32:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 06:32:46 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 15:39:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 06:39:24 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 15:45:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 06:45:51 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 15:52:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 06:52:41 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 16:00:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 07:00:43 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 16:11:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 07:11:50 -0700 Subject: [ python-Bugs-1502750 ] PyArg_ParseTuple(args, "i") and sys.maxint Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 16:50:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 07:50:45 -0700 Subject: [ python-Bugs-1502805 ] 'with' sometimes eats exceptions Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 19:02:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 10:02:13 -0700 Subject: [ python-Bugs-1495033 ] int/long assume that the buffer ends in \0 => CRASH Message-ID: 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 Hmmmmmm...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 From noreply at sourceforge.net Thu Jun 8 19:58:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 10:58:58 -0700 Subject: [ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 22:02:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 13:02:38 -0700 Subject: [ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii Message-ID: 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 From noreply at sourceforge.net Thu Jun 8 22:58:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 13:58:35 -0700 Subject: [ python-Bugs-1503157 ] "/".join() throws OverflowError Message-ID: 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 From noreply at sourceforge.net Fri Jun 9 00:40:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 15:40:41 -0700 Subject: [ python-Bugs-1503157 ] "/".join() throws OverflowError Message-ID: 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 From noreply at sourceforge.net Fri Jun 9 02:34:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 17:34:28 -0700 Subject: [ python-Bugs-1503157 ] "/".join() throws OverflowError Message-ID: 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 From noreply at sourceforge.net Fri Jun 9 05:20:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 20:20:43 -0700 Subject: [ python-Bugs-1503294 ] 'make install' fails on OS X 10.4 when running compileall Message-ID: 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 From noreply at sourceforge.net Fri Jun 9 12:31:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 03:31:37 -0700 Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3 Message-ID: Bugs item #1494314, was opened at 2006-05-24 15:51 Message generated for change (Comment added) made by mlrsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike ---------------------------------------------------------------------- >Comment By: Michael Smith (mlrsmith) Date: 2006-06-09 12:31 Message: Logged In: YES user_id=1488997 Ok, I'll attach a patch that uses poll when available (HAVE_POLL is already being set by the configure stuff appropriately). It replaces one of the two uses of select() (specifically, the internal_select() function) in socketmodule.c. The other is win32-specific, so replacing it with poll() wouldn't make sense. greg: epoll/kevent don't make sense for replacing the use of select/poll in this particular case - socketmodule.c always selects/polls precisely one file descriptor. I've tested this locally, and it fixes the problem (linux/x86). I don't have a windows system to test it on, but it shouldn't change behaviour in any way for windows. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-06-08 07:51 Message: Logged In: YES user_id=413 eew yuck. yes use poll at the very least. we should also consider using epoll (linux) and kevent (bsd) in the future as both of those scale better than O(n) unlike select and poll. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 22:14 Message: Logged In: YES user_id=21627 A patch to replace internal_select with poll(2) where available is acceptable. The current version should be conditionally kept. That Windows doesn't have poll(2) is no problem: its select implementation supports arbitrarily large FDs (just like poll). Relaxing the IS_SELECTABLE usage to cases where select is actually going to be called is optional: there shouldn't be too many systems left without select where people still want to open many file descriptors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-01 00:27 Message: Logged In: YES user_id=31435 akuchling: No, poll() is not part of the Windows socket API. ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 23:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 20:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 16:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 16:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 16:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. ---------------------------------------------------------------------- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 15:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your current limit. Ulimits are enforced by the Linux kernel and can likely be configured system-wide in /etc/sysctl.cfg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 From noreply at sourceforge.net Fri Jun 9 14:57:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 05:57:03 -0700 Subject: [ python-Bugs-1503502 ] Pdb doesn't call flush on its stdout file descriptor Message-ID: Bugs item #1503502, was opened at 2006-06-09 12:57 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=1503502&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: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Pdb doesn't call flush on its stdout file descriptor Initial Comment: When redirecting Pdb's stdout file object, the commands that use this to write output don't call flush() on the object. This leads to problem when setting the stdout file object to a fileobject created from a socket with the makefile() method. My proposed solution to this problem is for the Pdb class to contain a method for writing to fileobjects which can be overridden by programmers if they wish to write to sockets or other streams that require flush()ing. I can work on this patch if people thinks its a good idea. Thanks, Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503502&group_id=5470 From noreply at sourceforge.net Fri Jun 9 15:16:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 06:16:17 -0700 Subject: [ python-Bugs-1472827 ] xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes Message-ID: Bugs item #1472827, was opened at 2006-04-19 04:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes Initial Comment: xml.sax.saxutils.XMLGenerator does not escape \r, \n, \t symbols when they are present in the attribute: startElement("name", {"attrib": "value\nvalue"}) will result in which will be normalized by XML parser to According to the XML specs, to preserve this symbols in the attribute values, they should be replaced with \xD; \xA; \x9; Trivial fix is to replace those characters in xml.sax.saxutils.writeattr ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-09 09:16 Message: Logged In: YES user_id=11375 Fixed in trunk in rev. 46773; thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&group_id=5470 From noreply at sourceforge.net Fri Jun 9 16:00:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 07:00:48 -0700 Subject: [ python-Bugs-1472827 ] xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes Message-ID: Bugs item #1472827, was opened at 2006-04-19 04:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&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: XML Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mikhail Gusarov (gusarov) >Assigned to: A.M. Kuchling (akuchling) Summary: xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes Initial Comment: xml.sax.saxutils.XMLGenerator does not escape \r, \n, \t symbols when they are present in the attribute: startElement("name", {"attrib": "value\nvalue"}) will result in which will be normalized by XML parser to According to the XML specs, to preserve this symbols in the attribute values, they should be replaced with \xD; \xA; \x9; Trivial fix is to replace those characters in xml.sax.saxutils.writeattr ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-09 10:00 Message: Logged In: YES user_id=11375 Fixed on release24-maint in rev. 46777. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-09 09:16 Message: Logged In: YES user_id=11375 Fixed in trunk in rev. 46773; thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&group_id=5470 From noreply at sourceforge.net Fri Jun 9 18:59:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 09:59:48 -0700 Subject: [ python-Bugs-1503294 ] 'make install' fails on OS X 10.4 when running compileall Message-ID: Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Comment added) made by bcannon 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. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 From noreply at sourceforge.net Fri Jun 9 21:56:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 12:56:24 -0700 Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency Message-ID: Bugs item #1496501, was opened at 2006-05-28 14:42 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: dict order dependency Initial Comment: When guessing the type of a file, tarfile.py tries to open it in .tar, .tar.gz and .tar.bz2 modes successfully. The problem is that in conjunction with a fileobj argument, failed attempts can advance the current position of the fileobj, and cause the following attempts to fail as well. This didn't show up so far because, by chance, the order in which the OPEN_METH dictionary is enumerated is somehow the "correct" one. The problem can be seen by changing this order and re-running test_tarfile.py; for example, reverse the order (tarfile.py line 1013): for comptype in reversed(cls.OPEN_METH): ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 15:56 Message: Logged In: YES user_id=591932 I took a look at tarfile.py and though there is this comment about OPEN_METH # This concept allows one to subclass TarFile without losing the comfort of # the super-constructor. A sub-constructor is registered and made available # by adding it to the mapping in OPEN_METH. because adding items to OPEN_METH could change the order and break the Tarfile.open() classmethod I doubt adding to OPEN_METH is done in practice. +1 for renaming OPEN_METH to _OPEN_METH and making it a list of two-tuples. +0 on changing the two tups from ('typename', 'funcname') to ('typename', function_ref) and dropping the getattr functionality. The three default openers are not listed in the public interface so if anyone is subclassing Tarfile and overriding them (doubtful) they are doing so at their own peril. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470 From noreply at sourceforge.net Fri Jun 9 22:23:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 13:23:52 -0700 Subject: [ python-Feature Requests-1491485 ] str.startswith/endswith could take a tuple? Message-ID: Feature Requests item #1491485, was opened at 2006-05-19 10:24 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tom Lynn (tlynn) Assigned to: Georg Brandl (gbrandl) Summary: str.startswith/endswith could take a tuple? Initial Comment: In the same way that exceptions can have a tuple of types specified and isinstance can take a tuple of types, str.startswith and endswith could take a tuple of possible prefixes/suffixes. One use-case:: if filename.endswith(('jpg', 'gif', 'png')): # ... vs: if (filename.endswith('jpg') or filename.endswith ('gif') or filename.endswith('png')): #... Obviously it's not a huge improvement in clarity, but it does seem to be an improvement to me. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-09 20:23 Message: Logged In: YES user_id=849994 Committed implementation in rev. 46795. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-07 21:11 Message: Logged In: YES user_id=849994 I will, tomorrow. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-06 00:30 Message: Logged In: YES user_id=80475 Georg, would you like to implement this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-05 16:33 Message: Logged In: YES user_id=80475 The previous comment was just information. I am +1 on the proposal because the use case is so common and the proposed form is concise, clear, and natural. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-05-19 20:58 Message: Logged In: YES user_id=80475 FWIW, in Py2.5, this would be written: if any(filename.startswith(s) for s in suffixes): . . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470 From noreply at sourceforge.net Sat Jun 10 00:39:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 15:39:16 -0700 Subject: [ python-Bugs-532646 ] Recursive class instance "error" Message-ID: Bugs item #532646, was opened at 2002-03-20 10:56 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregor Mirai (gregmi) Assigned to: Brett Cannon (bcannon) Summary: Recursive class instance "error" Initial Comment: If one writes the following code (tested on Python 2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 98, NT, 2000) one can easily produce several "errors". MacOS X, MacOS X Server (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name, return A() ------------------------------------------ >>> a=A() >>> a.foo Segmentation fault Win98, NT, 2000 (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name return A() ------------------------------------------ >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 15:39 Message: Logged In: YES user_id=357491 Rev. 46806 for 2.5 and rev. 46807 for 2.4 have the fix for new-style classes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-04-18 12:08 Message: Logged In: YES user_id=357491 The test is already in crashers: infinite_rec_3 . And it is the same crash as in py3k; that's how I found it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-18 01:09 Message: Logged In: YES user_id=6380 Ironically, I just found the same (?) crash in the p3yk branch, in test_class.py (which is now testing new-style classes for compatibility with the behavior of classic classes). I can't fix this myself, so assigning to Brett. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-17 21:37 Message: Logged In: YES user_id=33168 Please add a test case to Lib/test/crashers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-04-17 17:00 Message: Logged In: YES user_id=357491 This was not fixed for new-style classes and still segfaults the interpreter at least back to 2.4. Reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 14:50 Message: Logged In: YES user_id=6380 It was very specific to __call__ after all, and I found an example that didn't involve __getattr__. See the comments I checked in as part of the fix in classobject.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 13:41 Message: Logged In: YES user_id=6380 Hm. I'm tracing this in the debugger now, and it appears that the problem is when trying to *print* an A instance. The statement a.foo causes the problem simply because it returns an A instance. (Proof: "a=A().foo; print a" fails in the print.) I think that instance_call may not be the real cause of the problem... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-12 15:38 Message: Logged In: YES user_id=33168 The problem is that there is mutual recursion between instance_call() and PyObject_Call(). The recursion apparently goes through the eval_frame() loop. This patch increases the recursion depth so the mutual recursion will eventually end (otherwise, the stack grows without bounds). ISTM the first check SHOULD be reached, but it is not. I don't understand why. The recursion error must be set in eval_frame(). The first block in the patch could be just this line: ++tstate->recursion_depth; I didn't do it that way, since I didn't expect returning to eval_frame(). I'm not sure if it's guaranteed to return to eval_frame() which is why I left the first condition in with the comment. I suppose the comment should say something like: /* this condition doesn't seem to be triggered, the recursion depth limit is exceeded in eval_frame */ The test for recursion_depth is necessary to ensure that the recursion error isn't overwritten. If this check is removed, the follow exception is raised: AttributeError: A instance has no __call__ method Hopefully this makes sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 09:08 Message: Logged In: YES user_id=6380 Can you explain how the fix works? Why does the first comment say /* this shouldn't be reached, but just in case */ and why is this test necesary if (tstate->recursion_depth < Py_GetRecursionLimit()) { ??? And who *does* report the recursion error? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 15:52 Message: Logged In: YES user_id=33168 The recursion fields are shared in the new patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:35 Message: Logged In: YES user_id=33168 That sounds more reasonable. I'll take a look and see if they can be integrated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:27 Message: Logged In: YES user_id=6380 Fair enough. Ideally this should share the recursion_limit variable from ceval.c and the recursion_depth field of the stack frame. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:23 Message: Logged In: YES user_id=33168 I don't know. I tried to come up with other test cases and failed. Tried __str__ and __getitem__. Also tried new-style classes. The problem was that the code bounced back and forth between PyObject_Call() & instance_call() (mutual recursion). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:08 Message: Logged In: YES user_id=6380 Is this fix enough? Aren't there lots of other ways to generate the same error? E.g. new-style classes (where this particular example doesn't apply, but others might). Or is this specific to instance_call? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 12:21 Message: Logged In: YES user_id=33168 The attached patch stops the segfault and raises an exception: TypeError: 'A' max recursion limit (100000) exceeded I'm not sure if this is genarally applicable, or what a reasonable # is. 100,000 was a guess and should probably be made a #def w/comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-21 01:47 Message: Logged In: NO >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf This is normal behavior. The code at the top is buggy. The correct one is: class A: def __getattr__(self, name): if name == '__repr__': return self.__repr__() print name return A() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-20 14:10 Message: Logged In: YES user_id=6380 This is buggy user code. But the segfault should be fixed if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 From noreply at sourceforge.net Sat Jun 10 01:04:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 16:04:17 -0700 Subject: [ python-Bugs-1503765 ] logger.config problems with comma separated lists Message-ID: Bugs item #1503765, was opened at 2006-06-09 23:04 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=1503765&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: cuppatea (cuppatea) Assigned to: Nobody/Anonymous (nobody) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 From noreply at sourceforge.net Sat Jun 10 02:03:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 17:03:35 -0700 Subject: [ python-Bugs-1503780 ] stdin directory causes crash (SIGSEGV) Message-ID: Bugs item #1503780, was opened at 2006-06-09 17: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=1503780&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: Ben Liblit (liblit) Assigned to: Nobody/Anonymous (nobody) Summary: stdin directory causes crash (SIGSEGV) Initial Comment: If standard input is redirected from a directory instead of a regular file, Python crashes quite early during startup, before running a single line of the user's script. I admit that redirecting from a directory is a weird thing to do, but even so, Python should respond with something more useful than a segmentation fault. In my particular case, the ideal behavior would be to not complain at all unless the Python script actually attempts to read from stdin. How to reproduce the problem: % touch empty.py % python -V Python 2.4.1 % python -d -v empty.py % python -d -v empty.py Bugs item #1503780, was opened at 2006-06-09 17:03 Message generated for change (Settings changed) made by liblit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&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: Ben Liblit (liblit) Assigned to: Nobody/Anonymous (nobody) >Summary: stdin from directory causes crash (SIGSEGV) Initial Comment: If standard input is redirected from a directory instead of a regular file, Python crashes quite early during startup, before running a single line of the user's script. I admit that redirecting from a directory is a weird thing to do, but even so, Python should respond with something more useful than a segmentation fault. In my particular case, the ideal behavior would be to not complain at all unless the Python script actually attempts to read from stdin. How to reproduce the problem: % touch empty.py % python -V Python 2.4.1 % python -d -v empty.py % python -d -v empty.py Bugs item #1503789, was opened at 2006-06-09 17:38 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=1503789&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: ---------------------------------------------- # -*- coding: UTF-16LE -*- print "Hello world" ---------------------------------------------- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 From noreply at sourceforge.net Sat Jun 10 02:39:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 17:39:09 -0700 Subject: [ python-Bugs-1503789 ] Cannot write source code in UTF16 Message-ID: Bugs item #1503789, was opened at 2006-06-09 17:38 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: ---------------------------------------------- # -*- coding: UTF-16LE -*- print "Hello world" ---------------------------------------------- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. ---------------------------------------------------------------------- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-09 17:39 Message: Logged In: YES user_id=561546 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 From noreply at sourceforge.net Sat Jun 10 03:42:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 18:42:56 -0700 Subject: [ python-Bugs-1503294 ] 'make install' fails on OS X 10.4 when running compileall Message-ID: Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Comment added) made by bcannon 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: 8 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. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 18:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 From noreply at sourceforge.net Sat Jun 10 03:47:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 18:47:28 -0700 Subject: [ python-Bugs-1503294 ] -Wi causes a fatal Python error on OS X Message-ID: Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Settings changed) made by bcannon 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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: -Wi causes a fatal Python error on OS X 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. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 18:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 From noreply at sourceforge.net Sat Jun 10 04:19:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 19:19:14 -0700 Subject: [ python-Bugs-1503294 ] -Wi causes a fatal Python error Message-ID: Bugs item #1503294, was opened at 2006-06-08 23:20 Message generated for change (Comment added) made by tim_one 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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: -Wi causes a fatal Python error 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. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-09 22:19 Message: Logged In: YES user_id=31435 Removed "on OS X" from the Summary line, since this is trivial to reproduce on Windows too: $ python_d -Wi Fatal Python error: PyThreadState_Get: no current thread Note that I used a debug build there; the error doesn't occur if I use a release build instead. As a matter of fact, Armin recently added a comment to dictobject.c pointing out this very failure mode: /* We can arrive here with a NULL tstate during initialization: try running "python -Wi" for an example related to string interning. Let's just hope that no exception occurs then... */ For that matter, it could be that Armin _created_ this failure mode too ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 21:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 12:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 From noreply at sourceforge.net Sat Jun 10 04:20:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 9 Jun 2006 19:20:09 -0700 Subject: [ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell. Message-ID: <200606100220.k5A2K9tJ018927@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1495210, was opened at 05/25/06 15:39 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&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: Macintosh Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: ephantom (ephantom) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Install under osx 10.4.6 breaks shell. Initial Comment: Build.txt: # BUILD INFO # Date: Fri Apr 7 11:07:14 2006 # By: Ronald Oussoren The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge terminal's shell. We installed it on two systems running 10.4.6, both systems had a previous version of python on them (2.3.5). On one system the shell broke to where it would not run UNIX commands, even after a re-boot. Under both systems the following shell errors occurred right after install. The error appears when you first initiate the shell, or change shells. glacier-wl:~ support$ csh csh: Badly placed ()'s. sh-2.05b$ tcsh tcsh: Badly placed ()'s. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 06/09/06 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 05/26/06 04:18 Message: Logged In: YES user_id=580910 This is now fixed in the trunk, and will be fixed in the next release of the universal build as well. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 05/26/06 03:41 Message: Logged In: YES user_id=580910 Assigned to me because I'm at fault here. This seems to be a bug in one of the postinstall scripts, I'll have a look. Sorry about the inconvenience. ---------------------------------------------------------------------- Comment By: ephantom (ephantom) Date: 05/25/06 15:43 Message: Logged In: YES user_id=1528840 Addendum: Both systems where PPC G4 systems, and not Intel chipsets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470 From noreply at sourceforge.net Sat Jun 10 04:54:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 19:54:25 -0700 Subject: [ python-Bugs-1503294 ] -Wi causes a fatal Python error Message-ID: Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Comment added) made by bcannon 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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Brett Cannon (bcannon) >Assigned to: Armin Rigo (arigo) Summary: -Wi causes a fatal Python error 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. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 19:54 Message: Logged In: YES user_id=357491 Ah-ha! I checked svn blame on PyThreadState_Get() and PyThreadState_GET(), but not on PyDict_GetItem(). Assigning to Armin since he caused this ruckus. =) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-09 19:19 Message: Logged In: YES user_id=31435 Removed "on OS X" from the Summary line, since this is trivial to reproduce on Windows too: $ python_d -Wi Fatal Python error: PyThreadState_Get: no current thread Note that I used a debug build there; the error doesn't occur if I use a release build instead. As a matter of fact, Armin recently added a comment to dictobject.c pointing out this very failure mode: /* We can arrive here with a NULL tstate during initialization: try running "python -Wi" for an example related to string interning. Let's just hope that no exception occurs then... */ For that matter, it could be that Armin _created_ this failure mode too ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 18:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 From noreply at sourceforge.net Sat Jun 10 08:34:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 23:34:45 -0700 Subject: [ python-Bugs-1503780 ] stdin from directory causes crash (SIGSEGV) Message-ID: Bugs item #1503780, was opened at 2006-06-10 00:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&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: Out of Date Priority: 5 Submitted By: Ben Liblit (liblit) Assigned to: Nobody/Anonymous (nobody) Summary: stdin from directory causes crash (SIGSEGV) Initial Comment: If standard input is redirected from a directory instead of a regular file, Python crashes quite early during startup, before running a single line of the user's script. I admit that redirecting from a directory is a weird thing to do, but even so, Python should respond with something more useful than a segmentation fault. In my particular case, the ideal behavior would be to not complain at all unless the Python script actually attempts to read from stdin. How to reproduce the problem: % touch empty.py % python -V Python 2.4.1 % python -d -v empty.py % python -d -v empty.py Comment By: Georg Brandl (gbrandl) Date: 2006-06-10 06:34 Message: Logged In: YES user_id=849994 This is already fixed in svn: $ ./python < / Python error: is a directory, cannot continue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&group_id=5470 From noreply at sourceforge.net Sat Jun 10 08:45:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 23:45:20 -0700 Subject: [ python-Bugs-1503157 ] "/".join() throws OverflowError Message-ID: Bugs item #1503157, was opened at 2006-06-08 20:58 Message generated for change (Settings changed) made by gbrandl 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: Closed >Resolution: Fixed 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: Georg Brandl (gbrandl) Date: 2006-06-10 06:45 Message: Logged In: YES user_id=849994 I applied the fix in rev. 46812. I also added the new test to the 2.4 branch in rev. 46813. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-09 00: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 22: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 From noreply at sourceforge.net Sat Jun 10 09:33:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 00:33:19 -0700 Subject: [ python-Bugs-1503883 ] csv.Sniffer - says "1 method", shows 2 Message-ID: Bugs item #1503883, was opened at 2006-06-10 07:33 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=1503883&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: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.Sniffer - says "1 method", shows 2 Initial Comment: >From the csv module - ----------------- class Sniffer( ) [...] The Sniffer class provides a single method: [...] sniff( sample[,delimiters=None]) [...] has_header( sample) [...] ----------------- It says "provides a single method", and then shows two methods. One is not sure whether "has_header" is part of Sniffer or not. Frank Millman ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 From noreply at sourceforge.net Sat Jun 10 11:10:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 02:10:20 -0700 Subject: [ python-Bugs-1503883 ] csv.Sniffer - says "1 method", shows 2 Message-ID: Bugs item #1503883, was opened at 2006-06-10 07:33 Message generated for change (Comment added) made by frankmillman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&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: Closed >Resolution: Out of Date Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.Sniffer - says "1 method", shows 2 Initial Comment: >From the csv module - ----------------- class Sniffer( ) [...] The Sniffer class provides a single method: [...] sniff( sample[,delimiters=None]) [...] has_header( sample) [...] ----------------- It says "provides a single method", and then shows two methods. One is not sure whether "has_header" is part of Sniffer or not. Frank Millman ---------------------------------------------------------------------- >Comment By: Frank Millman (frankmillman) Date: 2006-06-10 09:10 Message: Logged In: YES user_id=1070042 Apologies - I see this has been fixed in 2.5 Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 From noreply at sourceforge.net Sat Jun 10 12:46:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 03:46:46 -0700 Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency Message-ID: Bugs item #1496501, was opened at 2006-05-28 18:42 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: dict order dependency Initial Comment: When guessing the type of a file, tarfile.py tries to open it in .tar, .tar.gz and .tar.bz2 modes successfully. The problem is that in conjunction with a fileobj argument, failed attempts can advance the current position of the fileobj, and cause the following attempts to fail as well. This didn't show up so far because, by chance, the order in which the OPEN_METH dictionary is enumerated is somehow the "correct" one. The problem can be seen by changing this order and re-running test_tarfile.py; for example, reverse the order (tarfile.py line 1013): for comptype in reversed(cls.OPEN_METH): ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-10 10:46 Message: Logged In: YES user_id=4771 If possible, I would prefer that the constructors were fixed to become order-independent. Not sure how easy this is, though. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 19:56 Message: Logged In: YES user_id=591932 I took a look at tarfile.py and though there is this comment about OPEN_METH # This concept allows one to subclass TarFile without losing the comfort of # the super-constructor. A sub-constructor is registered and made available # by adding it to the mapping in OPEN_METH. because adding items to OPEN_METH could change the order and break the Tarfile.open() classmethod I doubt adding to OPEN_METH is done in practice. +1 for renaming OPEN_METH to _OPEN_METH and making it a list of two-tuples. +0 on changing the two tups from ('typename', 'funcname') to ('typename', function_ref) and dropping the getattr functionality. The three default openers are not listed in the public interface so if anyone is subclassing Tarfile and overriding them (doubtful) they are doing so at their own peril. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470 From noreply at sourceforge.net Sat Jun 10 12:59:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 03:59:08 -0700 Subject: [ python-Bugs-1503294 ] -Wi causes a fatal Python error Message-ID: Bugs item #1503294, was opened at 2006-06-09 03:20 Message generated for change (Comment added) made by arigo 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: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Armin Rigo (arigo) Summary: -Wi causes a fatal Python error 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. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-10 10:59 Message: Logged In: YES user_id=4771 Ah, PyThreadState_GET() complains if tstate is NULL, but only in debug mode. My code was prepared to handle a NULL return value; I didn't expect this extra check :-) Let's read _PyThreadState_Current directly then, as I don't see another way to get at it with no check. Checked in as r46818. Command-line arguments are not too much stressed by the test suite... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-10 02:54 Message: Logged In: YES user_id=357491 Ah-ha! I checked svn blame on PyThreadState_Get() and PyThreadState_GET(), but not on PyDict_GetItem(). Assigning to Armin since he caused this ruckus. =) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-10 02:19 Message: Logged In: YES user_id=31435 Removed "on OS X" from the Summary line, since this is trivial to reproduce on Windows too: $ python_d -Wi Fatal Python error: PyThreadState_Get: no current thread Note that I used a debug build there; the error doesn't occur if I use a release build instead. As a matter of fact, Armin recently added a comment to dictobject.c pointing out this very failure mode: /* We can arrive here with a NULL tstate during initialization: try running "python -Wi" for an example related to string interning. Let's just hope that no exception occurs then... */ For that matter, it could be that Armin _created_ this failure mode too ;-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-10 01:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 16:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 From noreply at sourceforge.net Sat Jun 10 14:27:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 05:27:30 -0700 Subject: [ python-Bugs-1503789 ] Cannot write source code in UTF16 Message-ID: Bugs item #1503789, was opened at 2006-06-10 02:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: ---------------------------------------------- # -*- coding: UTF-16LE -*- print "Hello world" ---------------------------------------------- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-10 14:27 Message: Logged In: YES user_id=21627 Would you like to work on a patch? There is, of course, a fairly obvious reason that this doesn't work: nobody has put effort into making it work. Personally, I suggest that you use some other encoding for source code, e.g. UTF-8. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-10 02:39 Message: Logged In: YES user_id=561546 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 From noreply at sourceforge.net Sat Jun 10 16:03:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 07:03:43 -0700 Subject: [ python-Bugs-1503883 ] csv.Sniffer - says "1 method", shows 2 Message-ID: Bugs item #1503883, was opened at 2006-06-10 02:33 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&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: Closed Resolution: Out of Date Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: csv.Sniffer - says "1 method", shows 2 Initial Comment: >From the csv module - ----------------- class Sniffer( ) [...] The Sniffer class provides a single method: [...] sniff( sample[,delimiters=None]) [...] has_header( sample) [...] ----------------- It says "provides a single method", and then shows two methods. One is not sure whether "has_header" is part of Sniffer or not. Frank Millman ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-06-10 09:03 Message: Logged In: YES user_id=44345 Nevertheless, this change should have been backported. Thanks for the catch. I'll have the correction to the 2.4 branch checked in momentarily. Skip ---------------------------------------------------------------------- Comment By: Frank Millman (frankmillman) Date: 2006-06-10 04:10 Message: Logged In: YES user_id=1070042 Apologies - I see this has been fixed in 2.5 Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503883&group_id=5470 From noreply at sourceforge.net Sat Jun 10 17:54:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 08:54:32 -0700 Subject: [ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPED_ACTIONS Message-ID: Bugs item #1449311, was opened at 2006-03-13 21:07 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christopher (chrism1) >Assigned to: Greg Ward (gward) >Summary: optparse: extending actions missing ALWAYS_TYPED_ACTIONS Initial Comment: http://docs.python.org/lib/optparse-adding-new-actions. html This page of docs should include the ALWAYS_TYPED_ ACTIONS list from optparse.py. In the example, unless you add the following line: ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS + ("dict",) , then the "Value" variable gets no value unless you explicitly pass "type='string'" to parser.add_option(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470 From noreply at sourceforge.net Sat Jun 10 18:15:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 09:15:58 -0700 Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency Message-ID: Bugs item #1496501, was opened at 2006-05-28 14:42 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: dict order dependency Initial Comment: When guessing the type of a file, tarfile.py tries to open it in .tar, .tar.gz and .tar.bz2 modes successfully. The problem is that in conjunction with a fileobj argument, failed attempts can advance the current position of the fileobj, and cause the following attempts to fail as well. This didn't show up so far because, by chance, the order in which the OPEN_METH dictionary is enumerated is somehow the "correct" one. The problem can be seen by changing this order and re-running test_tarfile.py; for example, reverse the order (tarfile.py line 1013): for comptype in reversed(cls.OPEN_METH): ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 12:15 Message: Logged In: YES user_id=591932 The invidual openers could tell() the fileobj and revert with a seek() on failure. The module requires those methods be implemented already to work so that is safe. I'll cook up a patch. But basically open() isn't as extensible as it seems. Stream reading and writing isn't supported for injected compression types and appending only works on plain tarfiles. I'm guessing that isn't a problem in practice or someone would have mentioned it by now ;) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-10 06:46 Message: Logged In: YES user_id=4771 If possible, I would prefer that the constructors were fixed to become order-independent. Not sure how easy this is, though. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 15:56 Message: Logged In: YES user_id=591932 I took a look at tarfile.py and though there is this comment about OPEN_METH # This concept allows one to subclass TarFile without losing the comfort of # the super-constructor. A sub-constructor is registered and made available # by adding it to the mapping in OPEN_METH. because adding items to OPEN_METH could change the order and break the Tarfile.open() classmethod I doubt adding to OPEN_METH is done in practice. +1 for renaming OPEN_METH to _OPEN_METH and making it a list of two-tuples. +0 on changing the two tups from ('typename', 'funcname') to ('typename', function_ref) and dropping the getattr functionality. The three default openers are not listed in the public interface so if anyone is subclassing Tarfile and overriding them (doubtful) they are doing so at their own peril. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470 From noreply at sourceforge.net Sat Jun 10 18:40:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 09:40:39 -0700 Subject: [ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPED_ACTIONS Message-ID: Bugs item #1449311, was opened at 2006-03-13 21:07 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christopher (chrism1) Assigned to: Greg Ward (gward) Summary: optparse: extending actions missing ALWAYS_TYPED_ACTIONS Initial Comment: http://docs.python.org/lib/optparse-adding-new-actions. html This page of docs should include the ALWAYS_TYPED_ ACTIONS list from optparse.py. In the example, unless you add the following line: ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS + ("dict",) , then the "Value" variable gets no value unless you explicitly pass "type='string'" to parser.add_option(). ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2006-06-10 12:40 Message: Logged In: YES user_id=14422 Oops! Quite right. Thanks for catching this. This is actually a bug in Optik's documentation, so the real fix is there (rev 517 of Optik svn). Fixed in Python svn: rev 46821 (Doc/lib/liboptparse.tex). This is trunk (Python 2.5) only. (BTW, you forgot to mention which example had this error. Also, the new action in the example is "extend", not "dict". This would have been a bit quicker and easier to fix if those details had been there.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470 From noreply at sourceforge.net Sat Jun 10 18:40:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 09:40:53 -0700 Subject: [ python-Bugs-1449311 ] optparse: extending actions missing ALWAYS_TYPED_ACTIONS Message-ID: Bugs item #1449311, was opened at 2006-03-13 21:07 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher (chrism1) Assigned to: Greg Ward (gward) Summary: optparse: extending actions missing ALWAYS_TYPED_ACTIONS Initial Comment: http://docs.python.org/lib/optparse-adding-new-actions. html This page of docs should include the ALWAYS_TYPED_ ACTIONS list from optparse.py. In the example, unless you add the following line: ALWAYS_TYPED_ACTIONS = Option.ALWAYS_TYPED_ACTIONS + ("dict",) , then the "Value" variable gets no value unless you explicitly pass "type='string'" to parser.add_option(). ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-06-10 12:40 Message: Logged In: YES user_id=14422 Oops! Quite right. Thanks for catching this. This is actually a bug in Optik's documentation, so the real fix is there (rev 517 of Optik svn). Fixed in Python svn: rev 46821 (Doc/lib/liboptparse.tex). This is trunk (Python 2.5) only. (BTW, you forgot to mention which example had this error. Also, the new action in the example is "extend", not "dict". This would have been a bit quicker and easier to fix if those details had been there.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1449311&group_id=5470 From noreply at sourceforge.net Sat Jun 10 18:42:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 09:42:41 -0700 Subject: [ python-Bugs-1183972 ] dest parameter in optparse Message-ID: Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&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.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ahmado (ahmado) Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2006-06-10 12:42 Message: Logged In: YES user_id=14422 No response from original poster after almost a year, so I'm assuming that I did indeed fix this bug in Optik 1.5 / Python 2.4. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2005-08-09 20:57 Message: Logged In: YES user_id=14422 ahmado -- please check if this bug is still present in Python 2.4 / Optik 1.5. If you do not respond in a week or two, I will assume that the bug is fixed and close this report. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2005-07-21 22:03 Message: Logged In: YES user_id=14422 I'm pretty sure I fixed this in Optik 1.5 / Python 2.4. Can you 1) verify if the bug is still there in Python 2.4 and 2) if so, supply a small script demonstrating the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 From noreply at sourceforge.net Sat Jun 10 19:46:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 10:46:24 -0700 Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency Message-ID: Bugs item #1496501, was opened at 2006-05-28 14:42 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: dict order dependency Initial Comment: When guessing the type of a file, tarfile.py tries to open it in .tar, .tar.gz and .tar.bz2 modes successfully. The problem is that in conjunction with a fileobj argument, failed attempts can advance the current position of the fileobj, and cause the following attempts to fail as well. This didn't show up so far because, by chance, the order in which the OPEN_METH dictionary is enumerated is somehow the "correct" one. The problem can be seen by changing this order and re-running test_tarfile.py; for example, reverse the order (tarfile.py line 1013): for comptype in reversed(cls.OPEN_METH): ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 13:46 Message: Logged In: YES user_id=591932 added patch 1504073 because SF won't let just anyone attach files to bugs. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 12:15 Message: Logged In: YES user_id=591932 The invidual openers could tell() the fileobj and revert with a seek() on failure. The module requires those methods be implemented already to work so that is safe. I'll cook up a patch. But basically open() isn't as extensible as it seems. Stream reading and writing isn't supported for injected compression types and appending only works on plain tarfiles. I'm guessing that isn't a problem in practice or someone would have mentioned it by now ;) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-10 06:46 Message: Logged In: YES user_id=4771 If possible, I would prefer that the constructors were fixed to become order-independent. Not sure how easy this is, though. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 15:56 Message: Logged In: YES user_id=591932 I took a look at tarfile.py and though there is this comment about OPEN_METH # This concept allows one to subclass TarFile without losing the comfort of # the super-constructor. A sub-constructor is registered and made available # by adding it to the mapping in OPEN_METH. because adding items to OPEN_METH could change the order and break the Tarfile.open() classmethod I doubt adding to OPEN_METH is done in practice. +1 for renaming OPEN_METH to _OPEN_METH and making it a list of two-tuples. +0 on changing the two tups from ('typename', 'funcname') to ('typename', function_ref) and dropping the getattr functionality. The three default openers are not listed in the public interface so if anyone is subclassing Tarfile and overriding them (doubtful) they are doing so at their own peril. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470 From noreply at sourceforge.net Sat Jun 10 21:18:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 12:18:36 -0700 Subject: [ python-Bugs-1417699 ] float/atof have become locale aware Message-ID: Bugs item #1417699, was opened at 2006-01-29 02:04 Message generated for change (Comment added) made by bernhard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: float/atof have become locale aware Initial Comment: The builtin float and the function string.atof have become locale aware in Python 2.4: Python 2.4.2 (#1, Nov 29 2005, 16:07:55) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> import string >>> locale.setlocale(locale.LC_ALL, "de_DE") 'de_DE' >>> float("1,5") 1.5 >>> string.atof("1,5") 1.5 This doesn't match what's specified in pep 331: - float() and str() stay locale-unaware. It also doesn't match the documentation for atof: Convert a string to a floating point number. The string must have the standard syntax for a floating point literal in Python, optionally preceded by a sign ("+" or "-"). Note that this behaves identical to the built-in function float() when passed a string. The documentation for float() doesn't state which format is accepted by float(), though. The reason for this behavior is ultimately, that PyOS_ascii_strtod accepts the locale specific convention in addition to the "C"-locale/python convention, even though the comment in the code preceding its definition states: This function behaves like the standard strtod() function does in the C locale. ---------------------------------------------------------------------- >Comment By: Bernhard Herzog (bernhard) Date: 2006-06-10 21:18 Message: Logged In: YES user_id=2369 gustavo, your patch seems to work fine. However, it leads to some test failures because the testsuite already tests for the wrong behaviour. I've uploaded a version of your patch that in addtion to your changes contains modifications to the test suite so that it tests for the new behavior and also tests some more variations of floating point literals accepted by float(). It would be nice if this patch could go into 2.5 before beta1 ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-05-16 18:35 Message: Logged In: YES user_id=908 It seems I can't upload files?! I have put the patch to fix this problem, including unit test, here: http://www.gnome.org/~gjc/python-1417699.diff ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-05-13 13:59 Message: Logged In: YES user_id=908 I'm quite busy at this moment, but I'll send a patch soon, promise. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-12 16:14 Message: Logged In: YES user_id=21627 Unassigning myself - I don't plan to work on this anytime soon. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-08 20:00 Message: Logged In: YES user_id=849994 I grepped around and found PyOS_ascii_strtod in the following places: * stropmodule::atof * cPickle::load_float (the writing of locale dependent floats was fixed recently) * floatobject::PyFloat_FromString * complexobject::complex_subtype_from_string In my opinion, all these should not tolerate localized floats, so Gustavo, please ask the original author how to achieve this. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-05-04 11:47 Message: Logged In: YES user_id=908 My comment is, is "PyOS_ascii_strtod accepting both forms" something that is harmful and should be fixed? I didn't exactly write the PyOS_ascii_strtod code; I only integrated it with Python. But if we really need to fix this, I'll try to figure out how to make it not accept floating points in locale aware format; if necessary I'll ask help from the original author of the code, Alexander Larsson. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-04 06:42 Message: Logged In: YES user_id=21627 It's a bug. As bernhard says, it originates from PyOS_ascii_strtod accepting both forms, which in turn happens because it just leaves the locale-specific decimal point in the string, only replacing the . with the locale-specific point. Then, the platform's strtod will happily accept the locale-specific version. I'd like Gustavo Carneiro to comment. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 13:19 Message: Logged In: YES user_id=1188172 Martin, you checked in the patch which is mentioned in PEP 331. Is this correct behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470 From noreply at sourceforge.net Sun Jun 11 02:41:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 17:41:02 -0700 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 14:02 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&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: 6 Submitted By: Steven Bethard (bediviere) Assigned to: Greg Ward (gward) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''\ ... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2006-06-10 20:41 Message: Logged In: YES user_id=14422 I agree that the docs are (pretty) clear and the code is wrong. When determining common leading whitespace, tabs and spaces should *not* be treated as equivalent. Raymond's fix was close, but not quite there: considering only the length of leading whitespace still causes space/tab confusion. (This only became clear to me after I wrote several test cases.) My fix is based on Raymond's, i.e. it uses regexes for most of the heavy lifting rather than splitting the input string on newline and looping over the lines. The bit that's different is determining what exactly is the common leading whitespace string. Anyways, this ended up being a complete rewrite of dedent(). I also added a paragraph to the docs to clarify the distinction between tabs and spaces. Checked in under rev 46844 (trunk only). ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 03:45 Message: Logged In: YES user_id=1188172 Looks good! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-20 01:04 Message: Logged In: YES user_id=80475 Suggested code: import re as _re _emptylines_with_spaces = _re.compile('(?m)^[ \t]+$') _prefixes_on_nonempty_lines = _re.compile('(?m)(^[ \t]*)(?:[^ \t\n]+)') def dedent(text): text = _emptylines_with_spaces.sub('', text) prefixes = _prefixes_on_nonempty_lines.findall(text) margin = min(prefixes or ['']) if margin: text = _re.sub('(?m)^' + margin, '', text) return text ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 23:52 Message: Logged In: YES user_id=80475 After more thought, I think the expandtabs() is a bug since it expands content tabs as well as margin tabs: >>> textwrap.dedent('\tABC\t\tDEF') 'ABC DEF' This is especially problematic given that dedent() has to guess at the tab size. If this gets fixed, I recommend using regular expressions as a way to indentify common margin prefixes on non-empty lines. This will also mixes of spaces and tabs without altering content with embedded tabs and without making assumptions about the tab size. Also, it ought to run somewhat faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 15:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Sun Jun 11 11:16:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 02:16:34 -0700 Subject: [ python-Bugs-963494 ] packman upgrade issue Message-ID: Bugs item #963494, was opened at 2004-05-31 11:39 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&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: Macintosh Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: packman upgrade issue Initial Comment: When you upgrade a package using packman the installer doesn't remove the old version before installing the new version. The end result is that old files might interfere with the correct operation of the upgraded package. I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1. Some extension modules have moved between those two releases. When upgrading using PackMan the old extension modules still exists, and cause problems when you try to use the package. Three possible solutions: 1) Remove the existing package directory before installing the upgrade 2) Add pre/post install/upgrade scripts 3) Use a real package database ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-11 11:16 Message: Logged In: YES user_id=580910 PackMan was dropped in 2.5 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 12:51 Message: Logged In: YES user_id=580910 I propose closing this bug as WontFix, PackMan is dead in the water. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 21:48 Message: Logged In: YES user_id=45365 I don't like the extra_path idea: it's meant for something else really. I think I'll just go for it and try the uninstaller trick. Don't know whether I'll have it in place before additions build 3, though, we'll see. As to the other issue (missing dependencies and such): I want to solve that differently, eventually. Currently there's only one test (installed) per package that's supposed to be as cheap as possible. I want to have at least one more (consistency) and maybe even two (consistency and full selfcheck). But that'll have to wait. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-01-04 17:34 Message: Logged In: YES user_id=580910 That might work. It does require that packman installs dependencies before installing the package itself. Another problem is smart GUI's. One useful feature for a PackMan GUI would be a listing of missing dependencies (e.g. you've installed _tkinter and somehow didn't install AquaTk, it would be nice if PackMan said that AquaTk is missing). Such a feature would have to know about uninstall packages, otherwise it would complain that 'foo-uninstall' is missing after you've installed 'foo'. Another solution (at least for PyObjC) is making sure that every package uses the 'extra_path' feature of distutils, add that value to the packman database, and remove $extra_path before installing a package. The extra_path key in the database could be optional: only add it when the previous version must be uninstalled before installing a new version. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 17:03 Message: Logged In: YES user_id=45365 All of these are difficult. But I was just wondering whether we could implement something simple: uninstall packages. For example, a package "PyObjC-uninstall" (normallly hidden) would somehow contain enough info to eradicate any known PyObjC installation. It's "installed" status would be true if PyObjC is *not* installed, false if it is. PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and when the user installed either of these they would first "install" PyObjC- uninstall, which would erase any previous installation. An uninstall package would probably consist of a list of files and dirs that would need to be removed. The package would be flagged as "installed" if any of these exist. There's probably packages that need something more complex (like editing config files or whatever), but I think this scheme would handle most common cases. "installing" an uninstall package, possibly as a result of a dependency, should probably put up a warning dialog first. Does this sound workable? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 15:14 Message: Logged In: YES user_id=45365 I'm moving this to the feature requests category: it requires major surgery, and it could be argued that this functionality belongs more in distutils than in Package Manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 From noreply at sourceforge.net Sun Jun 11 14:58:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 05:58:36 -0700 Subject: [ python-Bugs-1504333 ] sgmlib should allow angle brackets in quoted values Message-ID: Bugs item #1504333, was opened at 2006-06-11 08: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=1504333&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: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) Summary: sgmlib should allow angle brackets in quoted values Initial Comment: Real live example (search for "other
corrections") http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html This addresses the following (included in the file): # XXX The following should skip matching quotes (' or ") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470 From noreply at sourceforge.net Sun Jun 11 16:43:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 07:43:04 -0700 Subject: [ python-Bugs-1366250 ] incorrect documentation for optparse Message-ID: Bugs item #1366250, was opened at 2005-11-25 07:22 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Dunn (popuptoaster) Assigned to: Greg Ward (gward) Summary: incorrect documentation for optparse Initial Comment: The page http://www.python.org/doc/current/lib/optparse-parsing-arguments.html in the current documentation has text with an incorrect example: """ 6.21.3.7 Parsing arguments The whole point of creating and populating an OptionParser is to call its parse_args() method: (options, args) = parser.parse_args(args=None, options=None) where the input parameters are args the list of arguments to process (sys.argv[1:] by default) options object to store option arguments in (a new instance of optparse.Values by default) """ The example should be changed to: (options, args) = parser.parse_args(args=None, values=None) ^^^^^^ And then there should be a correstponding substition below in the explanation of the keyword arguments: values ^^^^^^ object to store option arguments in (a new instance of optparse.Values by default) Cheers, Michael ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2006-06-11 10:43 Message: Logged In: YES user_id=14422 Actually, I prefer the terminology in the example code, and think that the text is wrong. So I fixed the text instead. Also made a few other small tweaks to this section. Fixed upstream in Optik svn, rev 519. Fix on Python trunk, rev 46860. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-26 11:37 Message: Logged In: YES user_id=1188172 Assigning to Greg as he maintains the upstream Optik distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 From noreply at sourceforge.net Sun Jun 11 18:25:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 09:25:51 -0700 Subject: [ python-Bugs-1498146 ] optparse does not hande unicode help strings Message-ID: Bugs item #1498146, was opened at 2006-05-31 07:52 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&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: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tom Cato Amundsen (tomcato) Assigned to: Greg Ward (gward) Summary: optparse does not hande unicode help strings Initial Comment: Unicode strings with non-ascii chars in generate a UnicodeEncodeError File "/usr/lib/python2.3/optparse.py", line 1370, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: +ordinal not in range(128) I'm subclassing OptionParser and adds the following method to get it to work. Should something like this be done for python 2.5? def print_help(self, file=None): if file is None: file = sys.stdout file.write(self.format_help().encode(file.encoding, 'replace')) Tom Cato ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2006-06-11 12:25 Message: Logged In: YES user_id=14422 Fixed pretty much as suggested in upstream Optik repository: r520. (However, I had to use getattr(file, 'encoding', sys.getdefaultencoding()) to maintain compatibility with Python 2.0 .. 2.2). No doc changes, since help generation isn't really documented all that well anywhere. ;-( Fixed on Python trunk: r46861. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 From noreply at sourceforge.net Sun Jun 11 18:54:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 09:54:43 -0700 Subject: [ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster Message-ID: Bugs item #1501330, was opened at 2006-06-05 20:23 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&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: Brett Cannon (bcannon) Assigned to: Greg Ward (gward) Summary: failure of test_ossaudiodev; elapsed time .1 sec faster Initial Comment: I am getting a consistent failure of test_ossaudiodev on Ubuntu Hoary on an HP xw4300 Workstation. The failure is that the test is printing out "elapsed time: 3.0 sec" while the test expects 3.1 sec. I don't know anything about sound recordings so I don't know if there is any way to calculate the expected length of the test sound file and thus know that this is a true error or the test is just working faster than normally expected. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2006-06-11 12:54 Message: Logged In: YES user_id=14422 Brett -- I'm not sure why I put 3.1 sec in there. It's probably just what popped out the first time I ran this test on my machine. Anyways, simple math reveals that the theoretical running time of the test file is ~2.93 sec: (23493 bytes) / (1 byte/sample) / (8000 samples/sec) = 2.93 sec which of course ignores the overhead of the file header, but that seems to pretty small. "sox" agrees: $ time /usr/bin/play Lib/test/audiotest.au Input Filename : Lib/test/audiotest.au Sample Size : 8-bits Sample Encoding: u-law Channels : 1 Sample Rate : 8000 Time: 00:02.93 [00:00.00] of 00:02.93 ( 100.0%) Output Buffer: 23.46K Done. /usr/bin/play Lib/test/audiotest.au 0.03s user 0.02s system 1% cpu 3.127 total Can you try that on your machine and put the output here? Anyways, the likely culprits are 1) faster hardware (less overhead opening audio device, reading file, etc) and 2) variations in sound chip frequency (8000 Hz is not always exactly 8000 Hz). I'll try to fix the test so it's a little fuzzier. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-07 09:04 Message: Logged In: YES user_id=11375 Yes, the length is calculable -- you have N bytes in the file, with so many bits per sample and so many samples per second. Perhaps the driver now buffers more and the write() returns earlier? Or you could try printing the exact duration without rounding; maybe it's 3.0999999 or something and the print is just truncating. Assigning to Greg Ward, in case he gets around to looking at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470 From noreply at sourceforge.net Sun Jun 11 21:50:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 12:50:19 -0700 Subject: [ python-Bugs-1504456 ] xmlcore needs to be documented Message-ID: Bugs item #1504456, was opened at 2006-06-11 15:50 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=1504456&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: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlcore needs to be documented Initial Comment: The change from the "xml" package to the "xmlcore" package needs to be documented for Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 From noreply at sourceforge.net Mon Jun 12 12:41:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 03:41:46 -0700 Subject: [ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable Message-ID: Bugs item #1504676, was opened at 2006-06-12 06:41 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=1504676&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: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) Summary: Make sgmllib char and entity references pluggable Initial Comment: The changes being made to sgmllib in Python 2.5 may break existing applications. This patch makes it easy for subclasses to revert to the old behavior. Additionally, it makes it easier to provide new behaviors, like supporting unicode, hexadecimal character references, and additional entities. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470 From noreply at sourceforge.net Mon Jun 12 14:26:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 05:26:29 -0700 Subject: [ python-Bugs-1284316 ] Win32: Security problem with default installation directory Message-ID: Bugs item #1284316, was opened at 2005-09-07 23:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&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: Platform-specific Status: Open Resolution: None >Priority: 5 Submitted By: Mika Eloranta (mel) Assigned to: Martin v. L??wis (loewis) Summary: Win32: Security problem with default installation directory Initial Comment: (Sorry, this is a bit long since the issue is not entirely trivial.) This problem only exists on Windows operating systems installed on an NTFS file system. Confirmed on several Windows 2000, XP and Windows 2003 Server systems. All Python versions (at least 2.x) are affected. The default installation target directory where Python is installation on Windows is directly under the system drive's root directory (e.g. "C:\python24"). The file and directory permissions inherited by the python24-directory from the root directory are not secure enough for keeping application binaries. Microsoft has, in their infinite wisdom, decided that the root directory of the system drive should allow regular (non-admin) users to create directories and files there. This set of permissions is inherited by the python directory when it is created in the default location (i.e. "C:\python24" or whatever). This "feature" allows a regular (non-admin) user to perform a priviledge escalation attack for example in the following manner: 1. Figure out the name of some DLL python (or some extension .PYD) loads using LoadLibrary() without an absolute path. 2. Copy a DLL with the same name into the python-directory (this should not be allowed, but it is!) containing some code the attacker wants to run with escalated priviledges. 3. Wait until python is run by an admin in the same machine or by the LocalSystem account. How to view the problematic part of the ACL: 1. Right-click the "C:\python24" directory in Windows Explorer 2. select Properties... -> Security -> Advanced 3. In the "Permissions" tab you will see an entry for the "Users" group, it says "Special" in the "Permissions" column 4. Select the above entry and click "Edit..." 5. Well hidden? I think so, too. The fix: The proper (default) location where application binaries should be installed is under the "c:\program files\" directory. This directory has properly set permissions by default. PS. The same problem exists in ActivePerl, Ruby and many other tools. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-12 14:26 Message: Logged In: YES user_id=21627 Lowering the priority; this is now a documented bug. ---------------------------------------------------------------------- Comment By: D. Scott Miller (dsmiller) Date: 2006-05-06 03:04 Message: Logged In: YES user_id=1517734 Here's a few possible solutions to the permissions problem that retain the idea of defaulting to an install path with no spaces without making too many assumptions about what permissions the installing admin actually wants: ----------------- Idea #1 Install by default to %systemroot%\PythonXX. Hey, Java sticks some stuff in there, right? If the idea is "this is kind of a part-of-the-OS thing, and MS does it this way for cscript.exe" then this seems to make sense. (We hope any admins who're using a %systemroot% with spaces in it know what they're doing.) Is the default name for %systemroot% different on any particular localized versions of Windows? I know it's "WINDOWS" in Japanese versions, anyway. ----------------- Idea #2 Have two folder select boxes in the installer, one for where to install Python and one for a folder from which to copy ACLs. These would default to %systemdrive%\PythonXX and %programfiles%, respectively. Have a check box to disable the ACL copying, but have it checked by default. This is still bad, as it doesn't solve the problem of being a special separate directory with its own individual ACL to maintain, but it's somewhat less bad than it is now for people who click through the installer trusting it to not open up their system to new flavors of privilege escalation. ----------------- Idea #3 Do something goofy with NTFS junctions. ----------------- Regardless of what's done, given that people expect not to have to worry about spaces these days, it may be a good idea to include an explanation/warning about the situation in the installer text. ----------------- In regards to Martin L??wis' concern about non-admin users not being able to cause the generation of .pyc files in the main Python directory tree: It's already like that on most OS's, correct? So it would just apply in cases where someone a) writes an add-on specifically targeting the Python directory tree, specifically for Windows and b) expects .pyc generation to be done later rather than scripted as part of the installation. I have no idea if that's common or not, but it seems relatively safe to break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-22 21:27 Message: Logged In: YES user_id=31435 A long time ago, Python did install (by default) under "Program Files". I changed that, because of the endless problems created by the frickin' embedded space, and rarer but subtler problems due to "Program Files" not being a DOSish 8.3 name. Overall I still think it was a good change. Note that, unlike most Windows applications (which are GUI-based), programming languages are _intended_ to be used heavily from the command line, invoked by scripts, and so on. That's what makes a space in the path endlessly error-prone. In WinXP Pro, I noticed that MS was still careful to put its own command-line/script tools (sort.exe, ipconfig.exe, cscript.exe, ..., even notepad.exe) under pure DOSish 8.3 space-free paths ;-) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-22 20:09 Message: Logged In: YES user_id=21627 I completely disagree. It was wrong to give the system default binary directory a name with a space in it, on a system that doesn't provide command line argument vectors in its standard API. ---------------------------------------------------------------------- Comment By: Mika Eloranta (mel) Date: 2005-11-19 09:46 Message: Logged In: YES user_id=109057 Wow, even easy_install.exe from setuptools fails if python is installed under "c:\program files": C:\temp>easy_install C:\program: can't open file 'files\Python24\python.exe': [Errno 2] No such file or directory IMHO the root cause to all these problems is the wrong default installation directory. If the installation directory would conform to Windows guidelines, these kind of problems would have been easily spotted by python library developers. - Mika ---------------------------------------------------------------------- Comment By: Mika Eloranta (mel) Date: 2005-11-15 12:39 Message: Logged In: YES user_id=109057 Please consider these points as well: * The "program files" directory has "sensible" ACLs set by default (the defaults are different in different OS versions). If you install your application under "program files", you do not need to worry about the permissions. * The installation directory can be added to the PATH environment variable instead of typing it every time from console... * The current default installation directory is teaching python library developers bad habits of not handling Python installed into a directory that contains spaces properly. It is actually a miracle to find a third party library that installs a working script (batch file) to "python/scripts" if the python directory contains spaces. * The "program files" directory is the standard location where applications should be installed in Windows. This is what Microsoft requires in their guidelines and most applications obey them. You would not install python to "/python24" by default in Unix would you? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-10-08 11:48 Message: Logged In: YES user_id=21627 I disagree that the default location of Python should be c:\Program Files. The Python interpreter's path name is often typed into a terminal, batch file, etc., so it needs to be convenient to type. I agree that the permissions are problematic; the proper solution would be to give c:\python24 more restrictive permissions. You can do this yourself: in the security tab, edit the permission. In "Advanced", unselect the "Inherit permission" checkbox, and choose "copy" when asked. Then edit the permissions to your liking. I can consider supporting such permission setting during installation in the future - an invocation of cacls.exe should do. Notice that this is an incompatible change: as currently all users can create files in the tree, the .pyc files are often not created during installation, but on first use. If write permissions are denied, normal users could not cause .pyc creation anymore, causing increased startup costs unless the .pyc files are created during installation. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 08:26 Message: Logged In: YES user_id=33168 Martin, do you know anything about this? (Sorry, don't know who else might know.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470 From noreply at sourceforge.net Mon Jun 12 20:09:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 11:09:59 -0700 Subject: [ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster Message-ID: Bugs item #1501330, was opened at 2006-06-05 17:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&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: Brett Cannon (bcannon) Assigned to: Greg Ward (gward) Summary: failure of test_ossaudiodev; elapsed time .1 sec faster Initial Comment: I am getting a consistent failure of test_ossaudiodev on Ubuntu Hoary on an HP xw4300 Workstation. The failure is that the test is printing out "elapsed time: 3.0 sec" while the test expects 3.1 sec. I don't know anything about sound recordings so I don't know if there is any way to calculate the expected length of the test sound file and thus know that this is a true error or the test is just working faster than normally expected. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-12 11:09 Message: Logged In: YES user_id=357491 Output with the patch: playing test sound file (expected running time: 2.93 sec) actual running time was 3.09 sec (5.5% difference) ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-06-11 09:54 Message: Logged In: YES user_id=14422 Brett -- I'm not sure why I put 3.1 sec in there. It's probably just what popped out the first time I ran this test on my machine. Anyways, simple math reveals that the theoretical running time of the test file is ~2.93 sec: (23493 bytes) / (1 byte/sample) / (8000 samples/sec) = 2.93 sec which of course ignores the overhead of the file header, but that seems to pretty small. "sox" agrees: $ time /usr/bin/play Lib/test/audiotest.au Input Filename : Lib/test/audiotest.au Sample Size : 8-bits Sample Encoding: u-law Channels : 1 Sample Rate : 8000 Time: 00:02.93 [00:00.00] of 00:02.93 ( 100.0%) Output Buffer: 23.46K Done. /usr/bin/play Lib/test/audiotest.au 0.03s user 0.02s system 1% cpu 3.127 total Can you try that on your machine and put the output here? Anyways, the likely culprits are 1) faster hardware (less overhead opening audio device, reading file, etc) and 2) variations in sound chip frequency (8000 Hz is not always exactly 8000 Hz). I'll try to fix the test so it's a little fuzzier. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-07 06:04 Message: Logged In: YES user_id=11375 Yes, the length is calculable -- you have N bytes in the file, with so many bits per sample and so many samples per second. Perhaps the driver now buffers more and the write() returns earlier? Or you could try printing the exact duration without rounding; maybe it's 3.0999999 or something and the print is just truncating. Assigning to Greg Ward, in case he gets around to looking at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470 From noreply at sourceforge.net Mon Jun 12 21:08:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 12:08:24 -0700 Subject: [ python-Bugs-1504947 ] There should be a Python build using Visual Studio 2005 Message-ID: Bugs item #1504947, was opened at 2006-06-12 12:08 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=1504947&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Vincent Manis (vmanis) Assigned to: Nobody/Anonymous (nobody) Summary: There should be a Python build using Visual Studio 2005 Initial Comment: This report is a follow-on from Bug# 1498051, which complained that Distutils doesn't recognize Visual Studio 2005. That bug was closed with a statement that extensions should be built with the same version of the MS compiler that built the Python system. Given that Visual Studio 2003 is no longer available as a commercial product from Microsoft, many people (myself included) must use Visual Studio 2005. Therefore, I am requesting that a separate `batteries included' Windows installer be provided where everything has been built with VS2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504947&group_id=5470 From noreply at sourceforge.net Mon Jun 12 22:34:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 13:34:25 -0700 Subject: [ python-Bugs-1504998 ] under Windows XP, os.walk problem with path >256? chars Message-ID: Bugs item #1504998, was opened at 2006-06-12 15:34 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=1504998&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: under Windows XP, os.walk problem with path >256? chars Initial Comment: Under Windows XP, when using os.walk to walk a tree, I get an error message for a path of 256+ characters. The error looks like error listing directory [[Errno 206] The filename or extension is too long: The path in question is 12 directories deep, if that matters. The Windows 'dir' command also doesn't like this path because of its length, but it seems like there ought to be a way to walk it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504998&group_id=5470 From noreply at sourceforge.net Tue Jun 13 01:19:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 16:19:27 -0700 Subject: [ python-Bugs-1505081 ] Wrong grammar Message-ID: Bugs item #1505081, was opened at 2006-06-12 23:19 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=1505081&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Milind (t-milich) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong grammar Initial Comment: The Python and test is written as: and_test ::= not_test | and_test "and" not_test It should be changed to : and_test ::= not_test | not_test "and" and_test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&group_id=5470 From noreply at sourceforge.net Tue Jun 13 02:12:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 17:12:10 -0700 Subject: [ python-Bugs-1505095 ] Incorrect comment in socket.py Message-ID: Bugs item #1505095, was opened at 2006-06-12 17:12 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=1505095&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: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Christensen (bruckie) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect comment in socket.py Initial Comment: socket.py includes this comment around line 125: # These classes are used by the socket() defined on Windows and BeOS # platforms to provide a best-effort implementation of the cleanup # semantics needed when sockets can't be dup()ed. # # These are not actually used on other platforms. This appears to be incorrect. It appears that behavior is the same on different OSes (other than the riscos sleeptaskw function and Windows WSA error codes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505095&group_id=5470 From noreply at sourceforge.net Tue Jun 13 08:00:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 23:00:42 -0700 Subject: [ python-Bugs-1505081 ] Wrong grammar Message-ID: Bugs item #1505081, was opened at 2006-06-12 23:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Milind (t-milich) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong grammar Initial Comment: The Python and test is written as: and_test ::= not_test | and_test "and" not_test It should be changed to : and_test ::= not_test | not_test "and" and_test ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-13 06:00 Message: Logged In: YES user_id=849994 What problem does this cause for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&group_id=5470 From noreply at sourceforge.net Tue Jun 13 08:50:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 23:50:32 -0700 Subject: [ python-Bugs-1505081 ] Wrong grammar Message-ID: Bugs item #1505081, was opened at 2006-06-12 19:19 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Milind (t-milich) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong grammar Initial Comment: The Python and test is written as: and_test ::= not_test | and_test "and" not_test It should be changed to : and_test ::= not_test | not_test "and" and_test ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-13 02:50 Message: Logged In: YES user_id=31435 The grammar is correct as-is anyway, so closing this as invalid ("and" is left-associative, that's critical to correct understanding of its short-circuit semantics, and the production for and_test is left-recursive to make that clear: "a and b and c" must be parsed as "(a and b) and c", not as "a and (b and c)" as the suggested change would force). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-13 02:00 Message: Logged In: YES user_id=849994 What problem does this cause for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&group_id=5470 From noreply at sourceforge.net Tue Jun 13 08:56:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 23:56:27 -0700 Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build Message-ID: Bugs item #1451717, was opened at 2006-03-16 23:22 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&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: Pending >Resolution: Fixed Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: OS/X on i386 framework build Initial Comment: in Makefile.pre (374) it hard codes the architecture to 'ppc' which isn't correct for the new x86 boxes. this needs to be i386 for the framework install to actually build on the new macs. regards Ian ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 14:51 Message: Logged In: YES user_id=580910 This has been fixed on the trunk. I'll backport this to 2.4.x in the near future. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-17 16:07 Message: Logged In: YES user_id=580910 BTW. The 'also' bit has been fixed in the trunk. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:21 Message: Logged In: YES user_id=580910 This is a duplicate of bug 1447587 ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2006-03-16 23:34 Message: Logged In: YES user_id=5209 also.. in plat-mac/applesingle.py the fields AS_HEADER_FORMAT and AS_ENTRY_FORMAT need a '>' infront of the definitions AS_HEADER_FORMAT=">LL16sh" AS_ENTRY_FORMAT=">lll" (this is what the system-packaged python has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 From noreply at sourceforge.net Tue Jun 13 10:34:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 01:34:37 -0700 Subject: [ python-Bugs-1504998 ] under Windows XP, os.walk problem with path >256? chars Message-ID: Bugs item #1504998, was opened at 2006-06-12 13:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504998&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: under Windows XP, os.walk problem with path >256? chars Initial Comment: Under Windows XP, when using os.walk to walk a tree, I get an error message for a path of 256+ characters. The error looks like error listing directory [[Errno 206] The filename or extension is too long: The path in question is 12 directories deep, if that matters. The Windows 'dir' command also doesn't like this path because of its length, but it seems like there ought to be a way to walk it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-13 01:34 Message: Logged In: YES user_id=33168 I'm not sure, but this may have been fixed in Python 2.5. There should be a shiny new beta coming out in the next couple of days. I believe alpha 2 also has the fix (assuming that beta 1 has it and I'm not remembering some other change). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504998&group_id=5470 From noreply at sourceforge.net Tue Jun 13 18:27:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 09:27:21 -0700 Subject: [ python-Bugs-1503789 ] Cannot write source code in UTF16 Message-ID: Bugs item #1503789, was opened at 2006-06-09 17:38 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: ---------------------------------------------- # -*- coding: UTF-16LE -*- print "Hello world" ---------------------------------------------- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. ---------------------------------------------------------------------- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-13 09:27 Message: Logged In: YES user_id=561546 That sounds good. It is probably a good time to try out the instructions to build Python on Windows. http://groups.google.com/group/comp.lang.python/browse_ thread/thread/f09c49f77bf0a578/3e076bfcafb064cd?hl=en#3e076 bfcafb064cd Can you point me to the relevant source code? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-10 05:27 Message: Logged In: YES user_id=21627 Would you like to work on a patch? There is, of course, a fairly obvious reason that this doesn't work: nobody has put effort into making it work. Personally, I suggest that you use some other encoding for source code, e.g. UTF-8. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-09 17:39 Message: Logged In: YES user_id=561546 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 From noreply at sourceforge.net Tue Jun 13 19:06:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 10:06:47 -0700 Subject: [ python-Bugs-1503789 ] Cannot write source code in UTF16 Message-ID: Bugs item #1503789, was opened at 2006-06-10 02:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: ---------------------------------------------- # -*- coding: UTF-16LE -*- print "Hello world" ---------------------------------------------- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-13 19:06 Message: Logged In: YES user_id=21627 The parser code is in the Parser subdirectory. It would be good if you could follow the existing parsing strategy, i.e. convert the input to UTF-8, and then proceed with the normal parsing procedure. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-13 18:27 Message: Logged In: YES user_id=561546 That sounds good. It is probably a good time to try out the instructions to build Python on Windows. http://groups.google.com/group/comp.lang.python/browse_ thread/thread/f09c49f77bf0a578/3e076bfcafb064cd?hl=en#3e076 bfcafb064cd Can you point me to the relevant source code? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-10 14:27 Message: Logged In: YES user_id=21627 Would you like to work on a patch? There is, of course, a fairly obvious reason that this doesn't work: nobody has put effort into making it work. Personally, I suggest that you use some other encoding for source code, e.g. UTF-8. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-10 02:39 Message: Logged In: YES user_id=561546 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 From noreply at sourceforge.net Tue Jun 13 19:16:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 10:16:45 -0700 Subject: [ python-Bugs-1504998 ] under Windows XP, os.walk problem with path >256? chars Message-ID: Bugs item #1504998, was opened at 2006-06-12 22:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504998&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: under Windows XP, os.walk problem with path >256? chars Initial Comment: Under Windows XP, when using os.walk to walk a tree, I get an error message for a path of 256+ characters. The error looks like error listing directory [[Errno 206] The filename or extension is too long: The path in question is 12 directories deep, if that matters. The Windows 'dir' command also doesn't like this path because of its length, but it seems like there ought to be a way to walk it. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-13 19:16 Message: Logged In: YES user_id=21627 First of all, it's a limitation of the Microsoft C library that you are running into; that limitation should be removed in Python 2.5, so I'm closing this as "fixed". However, that might only mean that you get a different error: The Windows API is also normally limited to MAX_PATH characters, which is 260 (including drive letter). The only exception to get around that limit is to use Unicode path names that are \\?\ escaped, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-13 10:34 Message: Logged In: YES user_id=33168 I'm not sure, but this may have been fixed in Python 2.5. There should be a shiny new beta coming out in the next couple of days. I believe alpha 2 also has the fix (assuming that beta 1 has it and I'm not remembering some other change). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504998&group_id=5470 From noreply at sourceforge.net Tue Jun 13 19:19:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 10:19:05 -0700 Subject: [ python-Feature Requests-1504947 ] There should be a Python build using Visual Studio 2005 Message-ID: Feature Requests item #1504947, was opened at 2006-06-12 21:08 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1504947&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: None Status: Open Resolution: None Priority: 5 Submitted By: Vincent Manis (vmanis) Assigned to: Nobody/Anonymous (nobody) Summary: There should be a Python build using Visual Studio 2005 Initial Comment: This report is a follow-on from Bug# 1498051, which complained that Distutils doesn't recognize Visual Studio 2005. That bug was closed with a statement that extensions should be built with the same version of the MS compiler that built the Python system. Given that Visual Studio 2003 is no longer available as a commercial product from Microsoft, many people (myself included) must use Visual Studio 2005. Therefore, I am requesting that a separate `batteries included' Windows installer be provided where everything has been built with VS2005. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-13 19:18 Message: Logged In: YES user_id=21627 Recategorizing as a feature request. I'm personally not willing to produce several different x86 windows packages. However, sources are available, so if somebody things this should be provided, they are certainly free to provide it themselves. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1504947&group_id=5470 From noreply at sourceforge.net Tue Jun 13 23:51:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 14:51:53 -0700 Subject: [ python-Bugs-992017 ] code that generates a segfault on Python 2.1-2.3 Message-ID: Bugs item #992017, was opened at 2004-07-15 16:56 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&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: 7 Submitted By: Ted Bach (bachtor) Assigned to: Nobody/Anonymous (nobody) Summary: code that generates a segfault on Python 2.1-2.3 Initial Comment: On a Redhat Linux 9 based system, the following causes a segfault: """ In python, you can call any expression. """ class foo: def __init__(s,times=1): s.times = times def __call__(s): print s.times def __mul__(s,o): return foo(o) def __coerce__(s,o): if isinstance(o,int): return o,s (foo(3)*10)() # no segfault (10*foo(3))() # segfaults # prints 10 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-13 14:51 Message: Logged In: YES user_id=357491 Rev. 46932 for 2.5 and rev. 46934 for 2.4 has the fix. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-08 10:26 Message: Logged In: YES user_id=1188172 Still persists with Python 2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=4771 Here is a shorter example: class foo: def __coerce__(self, other): return other, self foo()+1 # segfault: infinite recursion in C classobject.c seems hopelessly prone to infinite recursion in C: whenever an operation needs coercion, __coerce__ is called and the operator PyNumber_Xxx() is called again on the result. The most obvious cases of recursion are taken care of, but there are and will always be more convoluted ways to create this recursion. There might be a way to solve the problem cleanly but currently I only see the solution of adding a C recursion check (Py_EnterRecursiveCall / Py_LeaveRecursiveCall). ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 07:18 Message: Logged In: YES user_id=908995 This is not the same problem as bug #980352; this one is an infinite recusion in the instance code (deriving foo from object makes the example work). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-16 06:45 Message: Logged In: YES user_id=6656 Isn't this likely to be a dup of bug [ 980352 ] coercion results used dangerously ? I haven't thought about either very hard, but both involve __coerce__ and core dumps... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 From noreply at sourceforge.net Tue Jun 13 23:55:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 14:55:22 -0700 Subject: [ python-Bugs-992017 ] code that generates a segfault on Python 2.1-2.3 Message-ID: Bugs item #992017, was opened at 2004-07-15 16:56 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&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: 7 Submitted By: Ted Bach (bachtor) Assigned to: Nobody/Anonymous (nobody) Summary: code that generates a segfault on Python 2.1-2.3 Initial Comment: On a Redhat Linux 9 based system, the following causes a segfault: """ In python, you can call any expression. """ class foo: def __init__(s,times=1): s.times = times def __call__(s): print s.times def __mul__(s,o): return foo(o) def __coerce__(s,o): if isinstance(o,int): return o,s (foo(3)*10)() # no segfault (10*foo(3))() # segfaults # prints 10 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-13 14:55 Message: Logged In: YES user_id=357491 Actually, that's 46933, not 2 for the HEAD rev. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-13 14:51 Message: Logged In: YES user_id=357491 Rev. 46932 for 2.5 and rev. 46934 for 2.4 has the fix. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-08 10:26 Message: Logged In: YES user_id=1188172 Still persists with Python 2.4. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=4771 Here is a shorter example: class foo: def __coerce__(self, other): return other, self foo()+1 # segfault: infinite recursion in C classobject.c seems hopelessly prone to infinite recursion in C: whenever an operation needs coercion, __coerce__ is called and the operator PyNumber_Xxx() is called again on the result. The most obvious cases of recursion are taken care of, but there are and will always be more convoluted ways to create this recursion. There might be a way to solve the problem cleanly but currently I only see the solution of adding a C recursion check (Py_EnterRecursiveCall / Py_LeaveRecursiveCall). ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 07:18 Message: Logged In: YES user_id=908995 This is not the same problem as bug #980352; this one is an infinite recusion in the instance code (deriving foo from object makes the example work). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-16 06:45 Message: Logged In: YES user_id=6656 Isn't this likely to be a dup of bug [ 980352 ] coercion results used dangerously ? I haven't thought about either very hard, but both involve __coerce__ and core dumps... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 From noreply at sourceforge.net Wed Jun 14 07:14:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 22:14:10 -0700 Subject: [ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable Message-ID: Bugs item #1504676, was opened at 2006-06-12 06:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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: Sam Ruby (rubys) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make sgmllib char and entity references pluggable Initial Comment: The changes being made to sgmllib in Python 2.5 may break existing applications. This patch makes it easy for subclasses to revert to the old behavior. Additionally, it makes it easier to provide new behaviors, like supporting unicode, hexadecimal character references, and additional entities. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 01:14 Message: Logged In: YES user_id=3066 This patch certainly makes the subclass interface nicer; I like that. There is a case that it breaks (foolishly not covered by the existing tests, but clear on reading the patch that it broke). I've added the relevant test in this change: http://mail.python.org/pipermail/python-checkins/2006-June/053975.html The problem with the patch is that attribute values are transformed twice (once for entity refs, once for character refs), instead of just once, so entity ref expansions can cause character refs to be located that aren't in the markup. I'm out of time tonight, but should be able to make this patch work with the additional tests tomorrow night if sruby doesn't beat me to it. Documentation and tests for the subclass interface changes are still needed as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:09:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:09:29 -0700 Subject: [ python-Bugs-1339007 ] shelve.Shelf.__del__ throws exceptions Message-ID: Bugs item #1339007, was opened at 2005-10-26 23:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Raymond Hettinger (rhettinger) Summary: shelve.Shelf.__del__ throws exceptions Initial Comment: Python calls an object's __del__ method, even if the objects __init__ method was unsuccessful (i.e. __init__ terminated via exception.) Because of this, if there is an error while attempting to open a Shelf, the destructor is still called, even though the Shelf is not fully constructed. The code in shelve.Shelf does not check for this possibility, and therefor triggers an AttributeError. Here is an example script which should reproduce the error. ===Begin test.py====l import shelve try: shelf = shelve.open('non-existant-file', flag='r') except: pass ===End test.py===== For me, the above script produces the message: Exception exceptions.AttributeError: "DbfilenameShelf instance has no attribute 'writeback'" in ignored I can reproduce this using either Python 2.4.1 or 2.3.5. I took a quick look at the current CVS version of shelve.py, and it appears to suffer the same problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:09 Message: Logged In: YES user_id=849994 Fixed in rev. 46946, 46947 (2.4). ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2006-01-25 15:39 Message: Logged In: YES user_id=45814 Exceptions thrown in __del__ are not quite complete ignored, since the fact that they are being "ignored" is reported on sys.stderr. The bug in question results in spurious, confusing messages being issued to sys.stderr. I say it is a bug. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:10 Message: Logged In: YES user_id=1188172 Is this a bug? As exceptions in __del__ are ignored, this should do no harm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:13:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:13:47 -0700 Subject: [ python-Bugs-1505095 ] Incorrect comment in socket.py Message-ID: Bugs item #1505095, was opened at 2006-06-13 00:12 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505095&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: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Bruce Christensen (bruckie) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect comment in socket.py Initial Comment: socket.py includes this comment around line 125: # These classes are used by the socket() defined on Windows and BeOS # platforms to provide a best-effort implementation of the cleanup # semantics needed when sockets can't be dup()ed. # # These are not actually used on other platforms. This appears to be incorrect. It appears that behavior is the same on different OSes (other than the riscos sleeptaskw function and Windows WSA error codes). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:13 Message: Logged In: YES user_id=849994 Thanks for reporting, this was already fixed in rev. 43746/7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505095&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:19:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:19:42 -0700 Subject: [ python-Bugs-1503765 ] logger.config problems with comma separated lists Message-ID: Bugs item #1503765, was opened at 2006-06-09 23:04 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&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: cuppatea (cuppatea) >Assigned to: Vinay Sajip (vsajip) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:20:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:20:31 -0700 Subject: [ python-Bugs-1503765 ] logger.config problems with comma separated lists Message-ID: Bugs item #1503765, was opened at 2006-06-09 23:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&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: cuppatea (cuppatea) Assigned to: Vinay Sajip (vsajip) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:20 Message: Logged In: YES user_id=849994 Attaching a real patch and assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:29:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:29:36 -0700 Subject: [ python-Bugs-1501122 ] Lang ref '<' description in 5.9 not consistent with __lt__ Message-ID: Bugs item #1501122, was opened at 2006-06-05 17:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501122&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: Lang ref '<' description in 5.9 not consistent with __lt__ Initial Comment: >From the reference manual section 5.9: "The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily." The last sentence may apply to built-in types, but '<' may be evaluated via __lt__ for user defined types, and there are no such restrictions as I read the documentation. If this section is only referring to built-in types it shuld be clearly stated. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:29 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 46949, 46950 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501122&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:42:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:42:28 -0700 Subject: [ python-Bugs-914375 ] modulefinder is not documented Message-ID: Bugs item #914375, was opened at 2004-03-11 19:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Thomas Heller (theller) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:42 Message: Logged In: YES user_id=849994 There seems to be a libmodulefinder.tex, but it is not very thorough. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-06-16 18:51 Message: Logged In: YES user_id=11105 If Just doesn't appear ;-) please assign to me. I should at least describe the api that is actually *used* in py2exe. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 18:21 Message: Logged In: YES user_id=11375 Just, it looks like you're responsible for modulefinder, so I'm reassigning this to you. It would be helpful if you could take a look at the docs and see if anything is documented that should be private. Please unassign (or close?) this bug if you're not connected to modulefinder. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 20:14 Message: Logged In: YES user_id=11375 I've written a crude first cut at this, but the module's code is very hard to read and it's not clear which bits are public and which aren't. The module's author should do this task (and use some docstrings in the code, too) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:47:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:47:48 -0700 Subject: [ python-Bugs-637547 ] "u#" doesn't check object type Message-ID: Bugs item #637547, was opened at 2002-11-13 04:00 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637547&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: Unicode Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: M.-A. Lemburg (lemburg) Summary: "u#" doesn't check object type Initial Comment: PyArg_ParseTuple(arg, "u#", p) doesn't check type of argument. So passing string object, PyArg_ParseTuple() doesn't report error and returns broken Unicode string. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:47 Message: Logged In: YES user_id=849994 The "u" format code doesn't accept buffers anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637547&group_id=5470 From noreply at sourceforge.net Wed Jun 14 10:10:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 01:10:42 -0700 Subject: [ python-Bugs-905389 ] str.join() intercepts TypeError raised by iterator Message-ID: Bugs item #905389, was opened at 2004-02-26 21:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&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.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: str.join() intercepts TypeError raised by iterator Initial Comment: For str.join(), if it is passed an iterator and that iterator raises a TypeError, that exception is caught by the join method and replaced by its own TypeError exception. SyntaxError and IndexError exceptions are uneffected. Example: Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 ... IDLE 1.0.2 >>> def gen(n): if not isinstance(n, int): raise TypeError, "gen() TypeError" if n<0: raise IndexError, "gen() IndexError" for i in range(n): yield str(i) >>> ''.join(gen(5)) '01234' >>> ''.join(gen(-1)) Traceback (most recent call last): File "", line 1, in -toplevel- ''.join(gen(-1)) File "", line 5, in gen raise IndexError, "gen() IndexError" IndexError: gen() IndexError >>> ''.join(gen(None)) Traceback (most recent call last): File "", line 1, in -toplevel- ''.join(gen(None)) TypeError: sequence expected, generator found >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:10 Message: Logged In: YES user_id=849994 This is fixed on the trunk. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-06-05 19:13 Message: Logged In: YES user_id=113328 Unicode objects do not have this behaviour. For example: >>> u''.join(gen(None)) Traceback (most recent call last): File "", line 1, in ? File "", line 3, in gen TypeError: gen() TypeError The offending code is at line 1610 or so of stringobject.c. The equivalent Unicode code starts at line 3955 of unicodeobject.c. The string code does a 2-pass approach to calculate the size of the result, allocate space, and then build the value. The Unicode version resizes as it goes along. This *may* be a significant speed optimisation (on the assumption that strings are more commonly used than Unicode objects), but I can't test (no MSVC7 to build with). If the speed issue is not significant, I'd recommend rewriting the string code to use the same approach the Unicode code uses. Otherwise, the documentation for str.join should clarify these points: 1. The sequence being joined is materialised as a tuple (PySequence_Fast) - this may have an impact on generators which use a lot of memory. 2. TypeErrors produced by materialising the sequence being joined will be caught and re-raised with a different message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&group_id=5470 From noreply at sourceforge.net Wed Jun 14 10:15:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 01:15:34 -0700 Subject: [ python-Bugs-1505841 ] Add support for GNU --long options (interpreter) Message-ID: Bugs item #1505841, was opened at 2006-06-14 11:15 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=1505841&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jari Aalto (jaalto) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for GNU --long options (interpreter) Initial Comment: This is forwarded wishlist from Debian bug tracking system. http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi? bug=289007 It would be good if Python supported standard GNU long options. Please support both short and long forms for all options. Like python --help python --version ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505841&group_id=5470 From noreply at sourceforge.net Wed Jun 14 10:32:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 01:32:15 -0700 Subject: [ python-Bugs-1153163 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153163, was opened at 2005-02-28 01:09 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&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: 5 Submitted By: Hugh Secker-Walker (hughsw) Assigned to: Nobody/Anonymous (nobody) Summary: reflected operator not used when operands have the same type Initial Comment: The reflected operators, e.g. __radd__, are used when the left operand does not have the non-reflected operator, *unless* the right operand is of the same type. The documentation on the "Emulating numeric types" page doesn't mention this peculiar exclusion. Of the reflected operators it says: "These methods are called to implement the binary arithmetic operations (+, -, *, /, %, divmod(), pow(), **, <<, >>, &, ^, |) with reflected (swapped) operands. These functions are only called if the left operand does not support the corresponding operation. For instance, to evaluate the expression x-y, where y is an instance of a class that has an __rsub__() method, y.__rsub__(x) is called." This code demonstrates the correct behavior and then the problem: class A(object): def __radd__(self, other): return '__radd__', other print None + A() print A() + A() giving.... ('__radd__', None) Traceback (most recent call last): File "C:/Temp/reflectedbug.py", line 6, in -toplevel- print A() + A() TypeError: unsupported operand type(s) for +: 'A' and 'A' I've replaced None in the first print statement with many kinds of builtin objects, instances of other classes, and with instances of subclasses of A. In all these cases the __radd__ operator is used as documented. I've only seen the problem when the two operands are of the same type. This problem also occurs during the backing-off to plain operators that occurs when augmented operators, e.g. __iadd__, aren't implemented by the type and the operands are of the same type. This problem is present in 2.4 on Linux and Windows, and in the current CVS version (2.5a0, 27-Feb-05) on Linux. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:32 Message: Logged In: YES user_id=849994 I added some wording to the docs along your suggestions. Fixed in rev. 46952, 46953. ---------------------------------------------------------------------- Comment By: Hugh Secker-Walker (hughsw) Date: 2005-03-02 03:25 Message: Logged In: YES user_id=1146279 Upon reflection and offline discussion it appears to me that Python is behaving as designed and that the documentation is buggy in that it fails to mention the special cases demonstrated in this bug report. The two special cases that the documentation should mention are: 1) The reflected operator is never used if the two operands are of the same type, regardless of whether the non-reflected operator exists. The necessity of this isn't clear to me. 2) If the type of the right-hand operand is a subclass of the type of the left-hand operand, and if the right-hand operand overloads the reflected operator from whatever is (or isn't) implemented by the left-hand operand, then the reflected operator of the right-hand operand will be used, regardless of the presence of the non-reflected operator for either type. This behavior is necessary for subclasses to overload parent class operators. -Hugh ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 05:08 Message: Logged In: YES user_id=593130 I believe Python's designer(s) intend that if A()+A() is valid, then A will have an __add__ method. __rxxx__ is only intended for backup use with mixed types. So your example sends a mixed message to the interpreter. If the current behavior is both intended and still necessary, the manual sentence "These functions are only called if the left operand does not support the corresponding operation" could be augmented with "and has a different type than the right operand" ---------------------------------------------------------------------- Comment By: Hugh Secker-Walker (hughsw) Date: 2005-03-01 04:36 Message: Logged In: YES user_id=1146279 The problem is in the SLOT1BINFULL() macro near line 4020 in typeobject.c. In two places it ensures that the reflected (reversed, swapped, rop, you name it) operator won't be called if the two operands are of the same type. Removing these two exclusions fixes the problem. However, this being my third day ever modifying Python source code, for all intents and purposes, I have no idea why the exclusions were there (efficiency?). And, elsewhere, I saw high-level code that had a similar check on operands having the same type with a comment that talked about avoiding an infinite loop that could happen if there's coercion and other subtly involved.... FWIW, with the changes I made, 256 tests are OK and 35 tests are skipped -- as is usual on my Linux system. I can post a trivial patch and figure out how to add a regression test, but expert analysis is needed. Also, the code in this macro (and perhaps helped by abstract.c) implements curious and not-documented-on-the-Emulating-numeric-types-page semantics: if the operand on the right is a subtype of the operand on the left and if the right operand overloads the reflected operator, then the reflected operator will be called, even if the left-hand operand implements the regular operator! This is either a bug or it should be documented, preferably with some rationale. E.g. class A(object): def __add__(self, other): return 'A.__add__', other class B(A): def __radd__(self, other): return 'B.__radd__', other >>> B()+A() ('A.__add__', <__main__.A object at 0x00B65A30>) >>> B()+B() ('A.__add__', <__main__.B object at 0x00B836F0>) >>> 1+B() ('B.__radd__', 1) >>> A()+B() ('B.__radd__', <__main__.A object at 0x00B65A30>) Where the last one is what's curious or a bug. -Hugh ---------------------------------------------------------------------- Comment By: Hugh Secker-Walker (hughsw) Date: 2005-02-28 06:09 Message: Logged In: YES user_id=1146279 I've looked into this a little. Newbie that I am, I don't know where the x = slotw(v, w); call goes (in binary_op1() in abstract.c near line 377).... AFAICT, this code in abstract.c behaves reasonably, so problem would seem to be in the tp_as_number slot-function that's getting called. And whereever that is, it's not the binary-op functions in classobject.c that I thought it would be.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470 From noreply at sourceforge.net Wed Jun 14 10:33:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 01:33:21 -0700 Subject: [ python-Bugs-1505841 ] Add support for GNU --long options (interpreter) Message-ID: Bugs item #1505841, was opened at 2006-06-14 08:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505841&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: Feature Request >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jari Aalto (jaalto) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for GNU --long options (interpreter) Initial Comment: This is forwarded wishlist from Debian bug tracking system. http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi? bug=289007 It would be good if Python supported standard GNU long options. Please support both short and long forms for all options. Like python --help python --version ... ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:33 Message: Logged In: YES user_id=849994 This is already tracked in #1481112. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505841&group_id=5470 From noreply at sourceforge.net Wed Jun 14 10:42:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 01:42:28 -0700 Subject: [ python-Bugs-1202018 ] mimetypes.py does not find mime.types on Mac OS X Message-ID: Bugs item #1202018, was opened at 2005-05-14 16:57 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan H. Holek (shh42) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes.py does not find mime.types on Mac OS X Initial Comment: Python 2.3 and 2.4 (dunno about 2.5) The mimetypes.py library does not find the mime.types files on Mac OS X. They are in: /etc/cups/mime.types and /etc/httpd/mime.types respectively. As a result not all mimetypes are recognized by Python. The one in / etc/cups is fairly limited, so including the Apache one as well seems like a good idea. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:42 Message: Logged In: YES user_id=849994 Added some mime.types locations in rev. 46954. ---------------------------------------------------------------------- Comment By: Stefan H. Holek (shh42) Date: 2005-05-14 16:59 Message: Logged In: YES user_id=864871 This is a with a standalone build of Python, I am not talking about the Python shipping with the system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&group_id=5470 From noreply at sourceforge.net Wed Jun 14 10:50:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 01:50:40 -0700 Subject: [ python-Bugs-1117556 ] SimpleHTTPServer and mimetypes: almost together Message-ID: Bugs item #1117556, was opened at 2005-02-06 23:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117556&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew L Daniel (mdaniel) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer and mimetypes: almost together Initial Comment: SimpleHTTPServer.py from python2.4 (and python2.3, so this is an old bug that hasn't bothered anyone before now), uses mimetypes for mime-type detection. The issue is that it only uses 50% of mimetypes, in two different ways. I argue that SimpleHTTPServer should not be copying mimetypes type-map into its own variable instead of leveraging the functionality found in mimetypes.guess_type (which guesses without regard to case, btw). If, however, you guys stick with your own extension_map, this bug is really about calling ``if not mimetypes.inited: mimetypes.init()'' before doing any such copying. This allows mimetypes to find mime.types on the local host and populate the types_map with lots of meaningful mime types. If it doesn't find any mime.types, no harm done. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:50 Message: Logged In: YES user_id=849994 Thanks, fixed in 46955, 46956 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117556&group_id=5470 From noreply at sourceforge.net Wed Jun 14 11:02:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 02:02:23 -0700 Subject: [ python-Bugs-1229380 ] No struct.pack exception for some out of range integers Message-ID: Bugs item #1229380, was opened at 2005-06-28 23:30 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Bob Ippolito (etrepum) Summary: No struct.pack exception for some out of range integers Initial Comment: struct.pack("B", -1) generates an OverflowError exception since the B format corresponds to the "unsigned char" type which can have values between 0 and 255. But struct.pack("I", -1) and struct.pack("L", -1) do not generate these errors, even if struct.pack("I", -1L) and struct.pack("L", -1L) do (notice the final L). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-26 13:16 Message: Logged In: YES user_id=139309 The test suite now covers this issue and it's fixed in revision 46320. Note that this is definitely a backwards incompatible change and we might have to change it to a warning or something stupid like that. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-24 10:25 Message: Logged In: YES user_id=849994 Assigning to Bob since he rewrote/extended the struct module for 2.5. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-04-27 14:46 Message: Logged In: YES user_id=971153 Also it appears that there is some kind of interference between range checking and byte-order chars: import struct; struct.pack("H", 70000) #Exception import struct; struct.pack(">H", 70000) # no exception ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 20:52 Message: Logged In: YES user_id=849994 Attaching patch, raises struct.error. Neal, please look over it. Note that I find struct's error handling confusing: it's not clear from the docs in which cases OverflowError is raised, and in which struct.error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470 From noreply at sourceforge.net Wed Jun 14 11:18:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 02:18:26 -0700 Subject: [ python-Bugs-756924 ] SIGSEGV causes hung threads (Linux) Message-ID: Bugs item #756924, was opened at 2003-06-18 23:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756924&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: Threads Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Jones (morngnstar) Assigned to: Nobody/Anonymous (nobody) Summary: SIGSEGV causes hung threads (Linux) Initial Comment: When a segmentation fault happens on Linux in any thread but the main thread, the program exits, but zombie threads remain behind. Steps to reproduce: 1. Download attached tar and extract files zombie.py and zombieCmodule.c. 2. Compile and link zombieCmodule.c as a shared library (or whatever other method you prefer for making a Python extension module). 3. Put the output from step 2 (zombieC.so) in your lib/python directory. 4. Run python2.2 zombie.py. 5. After the program exits, run ps. zombie.py launches several threads that just loop forever, and one that calls a C function in zombieC. The latter prints "NULL!" then segfaults intentionally, printing "Segmentation fault". Then the program exits, returning control back to the shell. Expected, and Python 2.1 behavior: No Python threads appear in the output of ps. Actual Python 2.2 behavior: 5 Python threads appear in the output of ps. To kill them, you have to apply kill -9 to each one individually. Not only does this bug leave around messy zombie threads, but the threads left behind hold on to program resources. For example, if the program binds a socket, that port cannot be bound again until someone kills the threads. Of course programs should not generate segfaults, but if they do they should fail gracefully. I have identified the cause of this bug. The old Python 2.1 behavior can be restored by removing these lines of Python/thread_pthread.h: sigfillset(&newmask); SET_THREAD_SIGMASK(SIG_BLOCK, &newmask, &oldmask); ... and ... SET_THREAD_SIGMASK(SIG_SETMASK, &oldmask, NULL); I guess even SIGSEGV gets blocked by this code, and somehow that prevents the default behavior of segfaults from working correctly. I'm not suggesting that removing this code is a good way to fix this bug. This is just an example to show that it seems to be the blocking of signals that causes this bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 09:18 Message: Logged In: YES user_id=849994 It seems that the patch at 960406 was applied and fixed this problem. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 17:19 Message: Logged In: YES user_id=119306 The patch in is probably a better change to consider rather than the LinuxThreads specific workarounds of 948614 or the false synchronous/ asynchronous dichotomy of 949332. (948614 was just looking at things in terms of LinuxThreads specific quirks, and when comments started popping up about similar problems in HP/UX and others it became apparent that a more general approach was needed. 949332 was a hope that a minimally intrusive variation might get be more palatable for 2.3.4, but I can perfectly understand your reluctance.) The new patch, 960406, seems to solve the problems Jason Lowe reported in (at least with my testing under Linux, Solaris, Irix, HP/UX, and True64 Unix) but does not exhibit the problems described here. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 15:43 Message: Logged In: YES user_id=29957 This will not be in 2.3.4, as I've already stated. a) We've already cut the release candidate, and the final release is less than 12 hours away b) this is a high-risk patch -- anything in the area of threads and signals is very risky. Here's how it should go forward: First, the trunk should be patched. This fix can then be in 2.4a1. Once we're through to 2.4 final, we'll know whether the fix is good enough for the 2.3 series. Finally, after 2.4 final comes out, there will be a 2.3.5. This fix can be in that, assuming it's fine in 2.4. ---------------------------------------------------------------------- Comment By: Dieter Maurer (dmaurer) Date: 2004-05-26 11:28 Message: Logged In: YES user_id=265829 The Python documentation currently asserts that signals are delivered only to the main thread. I think we can deviate from this assertion for signals that are not normally used by applications but are used by the OS to indicate abnormal execution conditions (like SIGSEGV, SIGBUS and friends). We should at least make sure that such abnormal conditions lead to a proper process shutdown -- as early as possible. I doubt that we should change the assertion for signals usually used by applications. Patch 949332 seems to be an appropriate short term solution - until we come up with something better. I would really like it to land already in Python 2.3.4. I will apply it for our productive Python environments because I am convinced that it will improve behaviour compared to the current state. I can report back should we see unexpected behaviour. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-20 18:38 Message: Logged In: YES user_id=119306 The callback interface seems to have been added in readline 2.1, from 1997. There seem to be configure tests in the current Modules/readline.c code to search for features new to readline 2.1 so my current approach would be upping the minimum readline version from 2.0 to 2.1. If needed I could test for the callback interface and use it if available, but fall back to the readline() interface otherwise (and leave the thread and signal handling issues in place when used with older readline.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-20 17:02 Message: Logged In: YES user_id=6656 This sounds cool! The only thing to be aware of is readline versioning... are these alternate interfaces a recent thing? ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-20 12:16 Message: Logged In: YES user_id=119306 I have an approach to have readline work well with threads while still acknowledging KeyboardInterrrupt. Using the alternate readline interface of rl_callback_handler_install() and rl_callback_read_char() along with a select(), we can recognize the interrupt signal when select returns EINTR and not need the signal handler at all. I just need to try my patch on a few more systems and try to put Anthony at ease. ---------------------------------------------------------------------- Comment By: Jason Lowe (jasonlowe) Date: 2004-05-13 17:25 Message: Logged In: YES user_id=56897 There didn't seem to be an outcome from the python-dev discussion regarding system() and pthread_atfork(). The thread indicates that system() indeed is supposed to call atfork handlers, so therefore RedHat 9 is violating the pthread standard in that sense. (Whether or not they'll fix it is another issue.) There's also mention that os.system() may be changed to not call system() because of the atfork() problem. If the changes to avoid system() are implemented, would the pthread_atfork() approach still be problematic? As Martin Loewis points out, we could always implement the signal fixup in the child directly after the fork() if Python routines are being used to do the fork() in the first place. However if we're concerned about native modules that directly call fork() then it seems our choices are a pthread_atfork() approach or an approach where SIGINT isn't blocked. Without an async-signal-safe way to route a signal from one thread to another, I don't see how we can leave SIGINT unblocked in all threads. Re: Py_AddPendingCall. That approach might work in many cases, but I assume it doesn't work well when all threads are currently busy in native modules that are not well-behaved. For example, I have two threads: one in readline() and the other blocked in a native call that, like readline(), doesn't return control on EINTR. If the SIGINT is sent to the readline thread, the signal handler could check the thread ID and do the longjmp() since we're the proper thread to do so. If the SIGINT is sent to the other thread, the callback added by Py_AddPendingCall() won't necessarily be processed any time soon because no threads are going to return control (in a timely manner) to Python. To make matters worse, apparently even something as simple as pthread_self(), which we'd use to get the thread ID, isn't async-signal-safe on all platforms. From what I've read, none of the pthread functions are guaranteed to be async-signal-safe. :-( ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-13 16:48 Message: Logged In: YES user_id=119306 pthread_kill(). That is annoying, I have something nearly done that used it. I didn't double check the safety of pthread_kill. I saw that posix says that kill is safe to call from interrupt handlers and went from there. Can we note that we need a pthread_kill in a call to Py_AddPendingCall, and then handle it later? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-13 16:25 Message: Logged In: YES user_id=6656 Just to make life more entertaining, pthread_atfork isn't what you want, either. http://mail.python.org/pipermail/python-dev/2003-December/041309.html ---------------------------------------------------------------------- Comment By: Jason Lowe (jasonlowe) Date: 2004-05-13 16:20 Message: Logged In: YES user_id=56897 Argh! I thought we had a relatively clean solution, but it appears there's a stumbling block with the pthread_kill() approach. pthread_kill() is not guaranteed to be async-signal-safe, and nuggets found on the net indicate there's no portable way to redirect a process signal from one thread to another: http://groups.google.com/groups?q=pthread_kill+async+safe&start=30&hl=en&lr=&selm=3662B6A8.861984D5%40zko.dec.com&rnum=32 http://www.redhat.com/archives/phil-list/2003-December/msg00049.html Given that we can't safely call pthread_kill() from the SIGINT handler directly, there might be another way to solve our problems with pthread_atfork(). Here's my thinking: - Block SIGINT in all threads except the main (readline) thread. - Register via child process handler via pthread_atfork() that sets the SIGINT action for the child process back to the default. Unfortunately this fix isn't localized to the readline module as desired, but it may solve the problems. SIGINT routing will be forced to the readline thread, and child processes won't have SIGINT blocked, solving bug 756940. The IRIX thread signal delivery model (i.e.: broadcast) may cause problems since SIGINT may be pending when we attempt to set the action to default. Having SIGINT pending when the handler is changed to default would kill the child process. Maybe having the child process set the disposition to ignore and then to default would safely clear any pending SIGINT signal? I'll try to run some experiments with the pthread_atfork() approach soon, but work and home life for me is particularly busy lately. Apologies in advance if it takes me a while to respond or submit patches. If we're interested in a timely fix, would it be useful to break up the fix in two stages? I think we can all agree that the current approach of blocking ALL signals in created threads is a Bad Thing. What if we implement a quick, partial fix by simply change the existing code to only block SIGINT? This should be a two-line change to thread_pthread.h where "sigemptyset(&newmask); sigaddset(&newmask, SIGINT);" is used instead of "sigfillset(&newmask);". I see this partial fix having a number of benefits: - Easy change to make. No extra stuff to check for in configure or calls to things that may not exist or work properly. - Much less risky than trying to fix all the problems at once. The change only opens up signals to threads that Python-2.1 is already allowing through. - Should solve the SIGSEGV zombie problem and Guido's SIGTERM annoyance, although it would still have the problem reported in bug 756940. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-12 14:39 Message: Logged In: YES user_id=29957 This seems like a pragmatic and sensible approach to take, to me. It should probably be tested on the HP/UX boxes (google for 'HP/UX testdrive') I particularly like the idea of just putting a test in to block readline in the non-main thread. It seems the pythonic approach - since we can't guarantee behaviour that's anything but sane, it seems like a plan. Or at least make it issue a warning saying "don't do this" when readline is invoked from a non-main thread. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-12 14:11 Message: Logged In: YES user_id=6380 Sounds good. This solves the problem in the readline module, where it originates. BTW, if we can simplify things by only allowing readline() to be called from the main thread, that's fine with me. Doing console I/O from threads is insane anyway. We can start by assuming the signal broadcast problem is restricted to IRIX, and configure appropriately: define a test symbol for this and in configure, set this when IRIX is detected. ---------------------------------------------------------------------- Comment By: Jason Lowe (jasonlowe) Date: 2004-05-12 13:54 Message: Logged In: YES user_id=56897 SIGINT is 'special' because that's the signal behind the problems reported in bug 465673. Given the readline module's setjmp/longjmp mechanism to process SIGINT, we simply cannot allow one thread to do the setjmp() and another thread to do the longjmp() when it receives SIGINT. Without the setjmp/longjmp stuff, SIGINT is no more special than any other asynchronous signal like SIGTERM, SIGUSR1, etc. It'd be great if we could get the desired behavior for SIGINT out of the readline module without setjmp/longjmp, but without help from the readline library I don't see an easy way to do this. The readline library insists on continuing the readline() call after a SIGINT is handled, and there doesn't appear to be any way to get it to abort the current readline() call short of modifying the readline library. If we're stuck with the setjmp/longjmp mechanism, I think we can solve the issues regarding readline() being called from another thread and exec'd processes from threads by using the pthread_kill() technique mentioned earlier. The steps would look something like this: - Do not block any signals (including SIGINT) in any threads. - When we initialize the readline module's jmp_buf via setjmp(), save off the current thread ID. Probably want to check for existing ownership of jmp_buf and flag an error if detected. - When the readline module SIGINT handler is invoked, check if the current thread owns jmp_buf. If we are the owning thread then execute the longjmp (or siglongjmp). If we're not the owning thread, then have the current thread execute pthread_kill(jmp_buf_owner_thread, SIGINT) and little else. This will defer the SIGINT to the only thread that can really process it correctly. - Since SIGINT isn't blocked in any thread, processes exec'd from threads should get the default behavior for SIGINT rather than having it blocked. The above algorithm has a race condition on thread implementations where all threads receive SIGINT. The race can cause SIGINT to be processed more than once. The jmp_buf owning thread might finish the processing of SIGINT before another thread starts its processing and re-sends SIGINT to the jmp_buf owning thread. If there's a way to know via configure that we're on a thread implementation that broadcasts SIGINT, we could #ifdef the code to use something like the getpid() hack in signalmodule.c to do the right thing. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-11 23:41 Message: Logged In: YES user_id=119306 The only thing special about SIGINT is that the readline module uses PyOS_setsig to set it, and when readline's special SIGINT handler is set, it throws all of the careful thread handling in Modules/sigmodule.c: signal_handler out the window. Now that I say it out loud, PyOS_setsig some consideration on its own. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-11 23:04 Message: Logged In: YES user_id=6380 And I think it is possible to call readline() from any thread. (Though it would be a problem if multiple threads were doing this simultaneously :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-11 22:54 Message: Logged In: YES user_id=6380 But if you still block SIGINT (why is SIGINT special?) in all threads, processes forked from threads will be started with SIGINT blocked, and that's still wrong. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-11 22:46 Message: Logged In: YES user_id=119306 I was handwaving a bit over the "arrangements" to make with the siglongjump. It is probable that blocking SIGINT from all spawned threads will be the easiest. It will also work in both the pthreads and LWP case (signal sent to one unblocked thread in the process) and the LinuxThreads and SGI threads case (signal broadcast to the process group, which includes each thread individually.) The only thing I wanted to double check was whether readline could be executed by any thread other than the main thread. If so, the SIGINT handler needs to check not whether it is the main thread, but rather if it is the (or *a*?) thread that currently is in the middle of a readline call. ---------------------------------------------------------------------- Comment By: Jason Lowe (jasonlowe) Date: 2004-05-11 19:57 Message: Logged In: YES user_id=56897 Ack. I thought I was logged in for that previous comment which was from me (jasonlowe). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-05-11 19:52 Message: Logged In: NO I agree, the original patch I submitted is horribly ham-fisted because it blocks all signals. I'm kicking myself for not forseeing the problems with SIGSEGV, SIGTERM, etc. as reported in 756924. The original problem I was trying to fix was that the wrong thread (i.e.: any thread but the main thread) would receive the SIGINT and end up doing the longjmp() to the context saved by the main thread. Then we have two threads executing on the main thread's stack which is a Bad Thing. With the way the readline support currently handles SIGINT via setjmp()/longjmp(), you really want the main thread and only the main thread to get the SIGINT and perform that longjmp(). Would it be reasonable to block only SIGINT (and not other signals) for all threads but the main thread? That would force SIGINT to be handled by the main thread and eliminate the worry that the wrong thread will do the longjmp() into the main thread's context in the readline code. I agree with large parts of langmead's proposed approach to fixing this, but I do have concerns about the combination of these two parts: * Remove the section of thread creation that blocks signals. * Change readline.c to use more thread safe constructs where available (arrange so that the longjmp out of the signal handler is only executed for the thread that is using readline, and use siglongjmp if available) According to the book "Programming with Threads" by Kleinman, Shah, and Smaalders: "Asynchronously generated signals are sent to the process as a whole where they may be serviced by any thread that has the signal unmasked. If more than one thread is able to receive a signal sent to the process, only one is chosen." If we leave SIGINT unmasked on all threads, then the signal handler will need to check the thread ID, and if not the main thread, use pthread_kill(main_thread, SIGINT) to defer the work to the main thread. In that sense, it'd be simpler to block SIGINT in all threads and force the system to route the SIGINT to the main thread directly. Of course if a particular threads implementation doesn't have the desired asynchronous signal routing behavior, maybe leaving SIGINT unmasked and using the pthread_kill(main_thread, SIGINT) technique could work around that. So to sum up, I'm in complete agreement with unblocking most if not all signals in other threads and with langmead's proposals to leverage the benefits provided by sigaction() and siglongjmp() when possible. I have one question though. Would it be reasonable to force SIGINT to be handled only by the main thread, or is there a need for Python threads other than the main thread to handle/receive SIGINT? If the latter then the setjmp()/longjmp() mechanism currently used in the readline module is going to be problematic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-11 13:59 Message: Logged In: YES user_id=6380 I'm beginning to think that langmead may be on to something: that blocking all signals in all threads is Just Plain Wrong (tm). The Zope SIGSEGV problem is just an example; I have my own beef with SIGTERM, which ends up blocked (together with all other signals) in child processes started from a thread. I would love to see langmead's patch! (For Python 2.4.) Make sure to test the behavior from 465673 (and possible 219772?) after removing the signal blocking but before adding the new fixes, and again after applying those, to make sure 465673 is really gone. Also, I'd like to hear from jasonlowe, who submitted bug 465673 and the patch that caused all the problems, 468347. Maybe his signal-fu has increased since 2001. It would be a miracle to get this into 2.3.4 though... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-11 08:52 Message: Logged In: YES user_id=6656 That does indeed sound reasonable, but not for 2.3.4 (professional cowardice, I'm afraid). Good luck! ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-10 22:46 Message: Logged In: YES user_id=119306 The original bug that added the signal blocking, #465673, seems to be exposing itself via a combination of threads and readline. Is it possible that it is the problem is there and not within the signal handling code itself? (especially since it installs and removes a SIGINT handler, possibly causing a race condition with the code within the signal handler when it re-installs itself. On systems that have sigaction, should python need to re-install handlers at all? ) I'm tempted to try to the following, and if it works submit a patch. Does this seem like it would be the right direction? * Remove the section of thread creation that blocks signals. * Look for sections of code may have reentrancy issues, like: ** On machines with reliable signals, keep the signal handler installed, rather than reinstalling it within the handler. ** Change Py_AddPendingCall to use a real semaphore, if available, rather than a busy flag. ** Change readline.c to use more thread safe constructs where available (arrange so that the longjmp out of the signal handler is only executed for the thread that is using readline, and use siglongjmp if available) and then see if issues like this one are solved without reintroducing issues from 465673. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-10 20:06 Message: Logged In: YES user_id=31435 Unassigned (was assigned to Guido, but doesn't sound like he's going to do more with it). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-10 19:47 Message: Logged In: YES user_id=6380 I agree with Anthony, too much risk for 2.3.4. I don't claim to understand this code any more; in particular the signal blocking code that's currently there wasn't written by me and if I checked it in, I did it hoping for the best... Langmead is right about signal asynchrony. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-10 18:45 Message: Logged In: YES user_id=119306 Unfortunately, in pthreads the "synchronous" doesn't apply to a signal number, but its method of delivery. You can deliver a "SIGSEGV" asynchronously with the "kill" command, and you send normally asynchronous signals with pthread_kill. What does is unblock signals like SIGSEGV which are likely to be sent synchronously from the OS and are unlikely to be handled by normal processes as asynchronous handlers. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-10 16:08 Message: Logged In: YES user_id=29957 I'd strongly prefer that this go into the trunk, and sooner, rather than later. I'd even more strongly prefer that this not go anywhere near the release23-maint branch, at least until _after_ 2.3.4 is done. If there ends up being a nice easy way to do this, great! We can cut a 2.3.5 around the same time as 2.4 final. Putting this into 2.3.4 seems, to me, to be a hell of a risk. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-10 01:13 Message: Logged In: YES user_id=31435 Whether you're off the hook depends on whether you're determined to be . I don't run on Unixish systems, so I'm not a lot of use here. The problem you've had with unkillable subprocesses also affects Zope, and you'll recall that the zdaemon business tries to keep Zope sites running via signal cruft. As people have tried to move from Python 2.1 to Python 2.3, they're discovering that Zope sites fail hard because of the signal- blocking added after 2.1: "when an external python module segfaults during a zope request ... the remaining worker threads are deadlocked", from http://tinyurl.com/2qslw and zdaemon doesn't do its job then. Andrew has in mind a scheme for not blocking "synchronous" signals, which makes sense to me, but I'm out of touch with this stuff. If you can't review it, who can? It would sure be nice to get a resolution into 2.3.4, although I understand that may be perceived as too risky. The alternative from my immediate POV is that people running Zope-based apps on some Unixish systems stay away from Python 2.3, which is a real shame. For that matter, unless this is resolved, I suppose they'll stay away from Python 2.4 too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-07 21:26 Message: Logged In: YES user_id=6380 (You had me confused for a bit -- I thought you meant Python 2.3, but you meant file revision 2.3, which was in 1994...) It can't be as simple as that; the 1994 code (rev 2.3) initializes both main_pid and main_thread, and checks one or the other in different places. The NOTES in that version don't shed much light on the issue except claiming that checking getpid() is a hack that works on three platforms named: SGI, Solaris, and POSIX threads. The code that is re-initializing main_pid in PyOS_AfterFork()was added much later (rev 2.30, in 1997). Here's my theory. On SGI IRIX, like on pre-2.6-kernel-Linux, getpid() differs per thread, and SIGINT is sent to each thread. The getpid() test here does the right thing: it only sets the flag once (in the handler in the main thread). On Solaris, the getpid() test is a no-op, which is fine sice only one thread gets the signal handler. Those were the only two cases that the getpid() test really cared for; the NOTES section speculated that it would also work with POSIX threads if the signal was only delivered to the main thread. Conclusion: the getpid() test was *not* a mistake, and replacing it with a get_thread_ident() test is not the right answer. But the getpid() test is probably not correct for all pthreads implementations, and some fix may be necessary. I also agree that blocking all signals is too aggressive, but am not sure what to do about this either. (It has caused some problems in my own code where I was spawning a subprocess in a thread, and the subprocess inherited the blocked signals, causing it to be unkillable except through SIGKILL.) Am I off the hook now? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-07 16:50 Message: Logged In: YES user_id=31435 Assigned to Guido to get an answer to one of the questions here: Guido, signal_handler() checks getpid() against main_pid, and has ever since revision 2.3 (when you first taught signalmodule.c about threads). But on every pthreads box except for Linux, get_pid() should always equal main_pid (even after a fork). What was the intent? I read the comments the same as Andrew does here, that the intent was to check thread identity, not process identity. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-07 13:59 Message: Logged In: YES user_id=119306 mwh wrote: "when there's a modern, actually working implementation of pthreads, I don't think we actually need to block signals at all." The bug report that caused the patch to be created was originally reported on Solaris, which has a more correct pthreads implementation. I'm now wondering if that problem was not caused by signals being handled by the spawned threads, but rather that the signal handler does a check for "if (getpid() == main_pid)" rather than "(PyThread_get_thread_ident() == main_thread)". One a standard's compliant pthreads implementation, and even on Solaris, getpid() will always "==" "main_pid". For the Linux case, we may have a more modern working threads implementation now, but when the old LinuxThreads style behavior was out and deployed for 8 years or so, it will probably be around for a while. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-07 13:48 Message: Logged In: YES user_id=119306 There are two different thread related patches that I submitted, I agree that is pretty radical. (Its the one that tests at configure time for LinuxThreads peculiarities and alters the thread spawning and signal related activities accordingly.) A different related signal patch might be more appealing to you. It only unblocks signals like segmentation faults that creates synchronously sends to itself and that a pthreads implementation will always send to the faulting thread. (whether it blocks it or not.) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-07 13:06 Message: Logged In: YES user_id=29957 Any patches in this area, I'd prefer to see on the trunk, along with tests to exercise it (and confirm that it's not breaking something else). We can then give it a solid testing during the 2.4 release cycle. I don't want to have to stretch the bugfix release cycle out to have alphas, betas and the like. This seems like huge piles of no-fun. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-07 12:56 Message: Logged In: YES user_id=6656 Note that there is an attempt at a configure test in 948614, but it seems very LinuxThreads specific. I agree with Anthony that this area is very scary. The last thing we want to do a fortnight before release is break things somewhere they currently work. On the gripping hand, when there's a modern, actually working implementation of pthreads, I don't think we actually need to block signals at all. I certainly don't have the threads-fu to come up with appropriate configure/pyport.h magic though. I'm not sure I have the energy to test a patch on all the testdrive, snake farm and SF compile farm machines either. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-07 12:39 Message: Logged In: YES user_id=29957 We're a week out from release-candidate, and this seems (to me) to be an area that's fraught with risk. The terms "HP/UX" and "threads" have also cropped up, which, for me, is a marker of "here be sodding great big dragons". I don't mind delaying the release if it's necessary, and there's a definite path to getting a nice clean fix in that won't break things for some other class of platform. This stuff looks like being a beast to test for, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-06 20:05 Message: Logged In: YES user_id=31435 Boosting priority, hoping to attract interest before 2.3.4. Patch 949332 looks relevant. ---------------------------------------------------------------------- Comment By: Kjetil Jacobsen (kjetilja) Date: 2004-05-05 08:28 Message: Logged In: YES user_id=5685 I've experienced similar behaviour with hung threads on other platforms such as HP/UX, so we should consider letting through some signals to all threads on all platforms. For instance, very few apps use signal handlers for SIGILL, SIGFPE, SIGSEGV, SIGBUS and SIGABRT, so unblocking those signals should not cause much breakage compared to the breakage caused by blocking all signals. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-04 14:44 Message: Logged In: YES user_id=31435 Noting that this has become a semi-frequent topic on the zope-dev mailing list, most recently in the "Segfault and Deadlock" thread starting here: ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-04 14:00 Message: Logged In: YES user_id=119306 The issue is that the threading implementation in Linux kernels previous to 2.6 diverged from the pthreads standard for signal handling. Normally signals are sent to the process and can be handled by any thread. In the LinuxThreads implementation of pthreads, signals are sent to a specific thread. If that thread blocks signals (which is what happens to all threads spawned in Python 2.2) then those signals do not get routed to a thread with them unblocked (what Python calls the "main thread") The new threading facility in Linux 2.6, the NPTL, does not have this signal handling bug. A simple python script that shows the problem is included below. This will hang in Linux kernels before 2.6 or RedHat customized kernels before RH9. #!/usr/bin/python import signal import thread import os def handle_signals(sig, frame): pass def send_signals(): os.kill(os.getpid(), signal.SIGSEGV) signal.signal(signal.SIGSEGV, handle_signals) thread.start_new_thread(send_signals, ()) signal.pause() ---------------------------------------------------------------------- Comment By: Greg Jones (morngnstar) Date: 2003-06-18 23:54 Message: Logged In: YES user_id=554883 Related to Bug #756940. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756924&group_id=5470 From noreply at sourceforge.net Wed Jun 14 11:34:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 02:34:13 -0700 Subject: [ python-Bugs-895567 ] os.listdir fails for pathprefix \\?\d:... Message-ID: Bugs item #895567, was opened at 2004-02-12 09:15 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&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: Windows Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guenter Kruschina (kruschina) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir fails for pathprefix \\?\d:... Initial Comment: The function os.listdir() fails with arguments beggining with \\?\... . This is necessary under windows to switch off pathchecking for all Win32-Widecharacter functions. The problem is located in the posixmodule. A diff -u will show the solution for this problem: --- posixmodule.c 2004-01-30 16:51:18.768574400 +0100 +++ posixmodule.c.org 2003-12-03 02:21:01.000000000 +0100 @@ -1386,7 +1386,7 @@ len = wcslen(wnamebuf); wch = (len > 0) ? wnamebuf[len-1] : L'\0'; if (wch != L'/' && wch != L'\\' && wch != L':') - wnamebuf[len++] = L'\\'; + wnamebuf[len++] = L'/'; wcscpy(wnamebuf + len, L"*.*"); if ((d = PyList_New(0)) == NULL) return NULL; By the way: The functions isdir..isfile...etc also does not work with the pathprefix \\?\ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 09:34 Message: Logged In: YES user_id=849994 It seems that someone applied the patch. Closing this accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&group_id=5470 From noreply at sourceforge.net Wed Jun 14 14:59:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 05:59:47 -0700 Subject: [ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable Message-ID: Bugs item #1504676, was opened at 2006-06-12 06:41 Message generated for change (Comment added) made by rubys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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: Sam Ruby (rubys) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make sgmllib char and entity references pluggable Initial Comment: The changes being made to sgmllib in Python 2.5 may break existing applications. This patch makes it easy for subclasses to revert to the old behavior. Additionally, it makes it easier to provide new behaviors, like supporting unicode, hexadecimal character references, and additional entities. ---------------------------------------------------------------------- >Comment By: Sam Ruby (rubys) Date: 2006-06-14 08:59 Message: Logged In: YES user_id=141556 updated patch with test case. Note that in the pre-existing code tag data values are transformed twice -- this should be corrected and ideally the code for handing references should be unified. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 01:14 Message: Logged In: YES user_id=3066 This patch certainly makes the subclass interface nicer; I like that. There is a case that it breaks (foolishly not covered by the existing tests, but clear on reading the patch that it broke). I've added the relevant test in this change: http://mail.python.org/pipermail/python-checkins/2006-June/053975.html The problem with the patch is that attribute values are transformed twice (once for entity refs, once for character refs), instead of just once, so entity ref expansions can cause character refs to be located that aren't in the markup. I'm out of time tonight, but should be able to make this patch work with the additional tests tomorrow night if sruby doesn't beat me to it. Documentation and tests for the subclass interface changes are still needed as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470 From noreply at sourceforge.net Wed Jun 14 15:02:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 06:02:26 -0700 Subject: [ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable Message-ID: Bugs item #1504676, was opened at 2006-06-12 06:41 Message generated for change (Comment added) made by rubys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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: Sam Ruby (rubys) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make sgmllib char and entity references pluggable Initial Comment: The changes being made to sgmllib in Python 2.5 may break existing applications. This patch makes it easy for subclasses to revert to the old behavior. Additionally, it makes it easier to provide new behaviors, like supporting unicode, hexadecimal character references, and additional entities. ---------------------------------------------------------------------- >Comment By: Sam Ruby (rubys) Date: 2006-06-14 09:02 Message: Logged In: YES user_id=141556 Note that the pre-existing code transforms tag data twice. Ideally, the handing for entities in attributes and data would be unified. ---------------------------------------------------------------------- Comment By: Sam Ruby (rubys) Date: 2006-06-14 08:59 Message: Logged In: YES user_id=141556 updated patch with test case. Note that in the pre-existing code tag data values are transformed twice -- this should be corrected and ideally the code for handing references should be unified. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 01:14 Message: Logged In: YES user_id=3066 This patch certainly makes the subclass interface nicer; I like that. There is a case that it breaks (foolishly not covered by the existing tests, but clear on reading the patch that it broke). I've added the relevant test in this change: http://mail.python.org/pipermail/python-checkins/2006-June/053975.html The problem with the patch is that attribute values are transformed twice (once for entity refs, once for character refs), instead of just once, so entity ref expansions can cause character refs to be located that aren't in the markup. I'm out of time tonight, but should be able to make this patch work with the additional tests tomorrow night if sruby doesn't beat me to it. Documentation and tests for the subclass interface changes are still needed as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470 From noreply at sourceforge.net Wed Jun 14 15:06:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 06:06:34 -0700 Subject: [ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable Message-ID: Bugs item #1504676, was opened at 2006-06-12 06:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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: Sam Ruby (rubys) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make sgmllib char and entity references pluggable Initial Comment: The changes being made to sgmllib in Python 2.5 may break existing applications. This patch makes it easy for subclasses to revert to the old behavior. Additionally, it makes it easier to provide new behaviors, like supporting unicode, hexadecimal character references, and additional entities. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 09:06 Message: Logged In: YES user_id=3066 Thanks. I'll look into this again tonight. ---------------------------------------------------------------------- Comment By: Sam Ruby (rubys) Date: 2006-06-14 09:02 Message: Logged In: YES user_id=141556 Note that the pre-existing code transforms tag data twice. Ideally, the handing for entities in attributes and data would be unified. ---------------------------------------------------------------------- Comment By: Sam Ruby (rubys) Date: 2006-06-14 08:59 Message: Logged In: YES user_id=141556 updated patch with test case. Note that in the pre-existing code tag data values are transformed twice -- this should be corrected and ideally the code for handing references should be unified. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 01:14 Message: Logged In: YES user_id=3066 This patch certainly makes the subclass interface nicer; I like that. There is a case that it breaks (foolishly not covered by the existing tests, but clear on reading the patch that it broke). I've added the relevant test in this change: http://mail.python.org/pipermail/python-checkins/2006-June/053975.html The problem with the patch is that attribute values are transformed twice (once for entity refs, once for character refs), instead of just once, so entity ref expansions can cause character refs to be located that aren't in the markup. I'm out of time tonight, but should be able to make this patch work with the additional tests tomorrow night if sruby doesn't beat me to it. Documentation and tests for the subclass interface changes are still needed as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470 From noreply at sourceforge.net Wed Jun 14 17:12:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 08:12:43 -0700 Subject: [ python-Feature Requests-1506122 ] Add "compose" function to the functools Message-ID: Feature Requests item #1506122, was opened at 2006-06-14 19:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "compose" function to the functools Initial Comment: I think it would be very usefull to have something similar to Haskell's "dot" operator in Python, IMO it should be something like this (untested): def compose(f, g): return lambda *args, **kws: f(g(*args, **kws)) but C-coded. So, _functools can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&group_id=5470 From noreply at sourceforge.net Wed Jun 14 18:02:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 09:02:42 -0700 Subject: [ python-Feature Requests-1506171 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506171, was opened at 2006-06-14 20:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470 From noreply at sourceforge.net Wed Jun 14 18:33:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 09:33:30 -0700 Subject: [ python-Feature Requests-1506190 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506190, was opened at 2006-06-14 20:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&group_id=5470 From noreply at sourceforge.net Wed Jun 14 18:46:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 09:46:57 -0700 Subject: [ python-Bugs-805015 ] PyUnicode_FromEncodedObject Message-ID: Bugs item #805015, was opened at 2003-09-12 11:39 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805015&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: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: PyUnicode_FromEncodedObject Initial Comment: There's a bug, either in the code or docs for PyUnicode_FromEncodedObject. The docs read: "Unicode objects are passed back as-is with incremented refcount. Note: These cannot be decoded; passing a non-NULL value for encoding will result in a TypeError." 'tain't so; the following shows that the error is unconditional. if (obj == NULL) { PyErr_BadInternalCall(); return NULL; } #if 0 /* For b/w compatibility we also accept Unicode objects provided that no encodings is given and then redirect to PyObject_Unicode() which then applies the additional logic for Unicode subclasses. NOTE: This API should really only be used for object which represent *encoded* Unicode ! */ if (PyUnicode_Check(obj)) { if (encoding) { PyErr_SetString(PyExc_TypeError, "decoding Unicode is not supported"); return NULL; } return PyObject_Unicode(obj); } #else if (PyUnicode_Check(obj)) { PyErr_SetString(PyExc_TypeError, "decoding Unicode is not supported"); return NULL; } #endif ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 16:46 Message: Logged In: YES user_id=849994 Fixed in rev. 46961. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805015&group_id=5470 From noreply at sourceforge.net Wed Jun 14 18:49:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 09:49:43 -0700 Subject: [ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt Message-ID: Bugs item #1099364, was opened at 2005-01-10 10:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&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: Wont Fix Priority: 7 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input() displays wrong unicode prompt Initial Comment: I have observed a problem when running Python 2.4, Windows version (python-2.4.msi) and using raw_input() with unicode prompt string in a console program (ran in the DOS window). I do use the following sitecustomize.py file to set the default encoding in the English Windows 2000 Server: sitecustomize.py ================================= import sys sys.setdefaultencoding('cp1250') ================================= test.py ================================= # -*- coding: cp1250 -*- s = u'string with accented letters (different than this)' print s # OK val = raw_input(s) # s displayed differently (wrong) ================================= See the test.png (captured from screen) and the test.py for the used string -- inside the attached zip file. The "type test.py" (result visible on the captured screen) displays the string definition also wrongly, because the DOS window uses different encoding than cp1250. The print command prints the string correctly, converting the internal unicode string to the encoding that the is defined by the output environment. However, the raw_input() probably does convert the unicode string to the cp1250 and does not do the same (more clever) thing that the print does. I did not use the unicode in older Python (2.3.4), so I do not know what was the behaviour earlier. Could you confirm the bug? Sorry if the bug is well known. Petr ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 16:49 Message: Logged In: YES user_id=849994 Per python-dev discussion, this is still expected behavior (and a wart). ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-08-08 08:37 Message: Logged In: YES user_id=771873 As the patch #1214889 that would have solved the problem on lower levels was rejected, the problem should be reopened and the raw_input() internals should be implemented similarly to print. Thanks, Petr ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-28 06:40 Message: Logged In: YES user_id=1188172 You'll have to explicitly encode the unicode string using raw_input(s.encode(sys.stdout.encoding)). As said, this behaviour will change if the patch mentioned is accepted. ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-06-28 05:56 Message: Logged In: YES user_id=771873 Should I understand it that there is no bug, but I do use it incorrectly? I cannot agree that this is expected behaviour. (I am not the only one who found this strange.) Of course, the sys.stdout.encoding is different for a DOS window (cp852) than the default encoding (cp1250). Windows simply behaves this way when working with DOS window (because of legacy DOS applications). I do not complain on behaviour of sys.stdout.write() but on behaviour of raw_input(). The output of raw_input() prompt should be displayed the same way as the print diplays the results to the user. The raw_input() is used for building user interface. Its prompt should not be displayed differently in windows that use different encoding (i.e. DOS console vs. say IDLE console). In other words, how should I use raw_input() to make it working correctly? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-26 20:34 Message: Logged In: YES user_id=1188172 Actually, your sys.stdout.encoding is set to something different than cp1250, which is why the result of DOS type looks the same as the one of print. This is because print observes sys.stdout.encoding, while sys.stdout.write uses the system default encoding, which is, as you set it, cp1250 and is displayed wrong on the console. Closing this bug, as it is currently expected behaviour (but will perhaps change when patch #1214889 is accepted). ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 14:34 Message: Logged In: YES user_id=771873 Python 2.4.1 for Windows behaves the same way. Petr ---------------------------------------------------------------------- Comment By: Petr Prikryl (prikryl) Date: 2005-04-14 14:26 Message: Logged In: YES user_id=771873 New observation: sys.stdout.write(s) behaves visually on the screen exactly as the raw_input(s) does. So, print does something more when displaying on the screen... Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 From noreply at sourceforge.net Wed Jun 14 18:55:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 09:55:20 -0700 Subject: [ python-Feature Requests-1506190 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506190, was opened at 2006-06-14 16:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 16:55 Message: Logged In: YES user_id=849994 Duplicate of #1506171. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&group_id=5470 From noreply at sourceforge.net Wed Jun 14 19:03:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 10:03:57 -0700 Subject: [ python-Feature Requests-1506211 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506211, was opened at 2006-06-14 21:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&group_id=5470 From noreply at sourceforge.net Wed Jun 14 19:15:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 10:15:35 -0700 Subject: [ python-Feature Requests-1506216 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506216, was opened at 2006-06-14 21:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&group_id=5470 From noreply at sourceforge.net Wed Jun 14 19:25:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 10:25:04 -0700 Subject: [ python-Feature Requests-1506211 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506211, was opened at 2006-06-14 17:03 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 17:25 Message: Logged In: YES user_id=849994 Se #1506171. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&group_id=5470 From noreply at sourceforge.net Wed Jun 14 19:26:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 10:26:09 -0700 Subject: [ python-Feature Requests-1506216 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506216, was opened at 2006-06-14 17:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 17:26 Message: Logged In: YES user_id=849994 See #1506171. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&group_id=5470 From noreply at sourceforge.net Wed Jun 14 21:35:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 12:35:45 -0700 Subject: [ python-Feature Requests-1506296 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506296, was opened at 2006-06-14 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506296&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506296&group_id=5470 From noreply at sourceforge.net Wed Jun 14 22:15:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 13:15:28 -0700 Subject: [ python-Feature Requests-1506313 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506313, was opened at 2006-06-15 00:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&group_id=5470 From noreply at sourceforge.net Wed Jun 14 22:45:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 13:45:38 -0700 Subject: [ python-Feature Requests-1506324 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506324, was opened at 2006-06-15 00:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&group_id=5470 From noreply at sourceforge.net Wed Jun 14 22:57:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 13:57:30 -0700 Subject: [ python-Feature Requests-1506313 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506313, was opened at 2006-06-14 20:15 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 20:57 Message: Logged In: YES user_id=849994 See #1506296. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&group_id=5470 From noreply at sourceforge.net Wed Jun 14 22:58:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 13:58:05 -0700 Subject: [ python-Feature Requests-1506324 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506324, was opened at 2006-06-14 20:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 20:58 Message: Logged In: YES user_id=849994 See #1506296. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&group_id=5470 From noreply at sourceforge.net Wed Jun 14 23:14:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 14:14:56 -0700 Subject: [ python-Feature Requests-1506340 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506340, was opened at 2006-06-15 01:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&group_id=5470 From noreply at sourceforge.net Wed Jun 14 23:18:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 14:18:10 -0700 Subject: [ python-Feature Requests-1506340 ] Add some dicts to datetime module Message-ID: Feature Requests item #1506340, was opened at 2006-06-15 01:14 Message generated for change (Comment added) made by gregory_p You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add some dicts to datetime module Initial Comment: I think it would be nice to have dicts like weekdays = {0:'Monday', ...} isoweekdays = {1:'Monday', ...} months = {1:'January', ...} in the datetime module. IMO they are rather usefull. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Gregory Petrosyan (gregory_p) Date: 2006-06-15 01:18 Message: Logged In: YES user_id=1405187 I am terribly sorry for that many duplicates of this and other tickets. This is a strange bug, i don't know why this had happened. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&group_id=5470 From noreply at sourceforge.net Thu Jun 15 00:26:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 15:26:12 -0700 Subject: [ python-Bugs-516412 ] Python gettext doesn't support libglade Message-ID: Bugs item #516412, was opened at 2002-02-12 16:01 Message generated for change (Comment added) made by nshmyrev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Christian Reis (kiko_async) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade Initial Comment: Libglade is a library that parses XML and generates GTK-based UIs in runtime. It is written in C and supports a number of languages through bindings. James Henstridge has maintained a set of bindings for Python for some time now. These bindings work very well, _except for internationalization_. The reason seems now straightforward to me. Python's gettext.py is a pure python implementation, and because of it, bindtextdomain/textdomain are never called. This causes any C module that uses gettext to not activate the support, and not use translation because of it. Using Martin's intl.so module things work great, but it is a problem for us having to redistribute it with our application. Any other suggestions to fix? ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-15 02:26 Message: Logged In: YES user_id=598622 I am still seeing this with meld application meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-03-27 21:53 Message: Logged In: YES user_id=21627 This is fixed with configure 1.291 configure.in 1.301 pyconfig.h.in 1.25 liblocale.tex 1.28 NEWS 1.369 _localemodule.c 2.29 Notice that applications that want to change the C library's domain bindings will have to invoke locale.bindtextdomain; I decided not to provide automatic forwarding from gettext.bindtextdomain to locale.bindtextdomain, since the C library and Python may have different message catalog formats (e.g. on Solaris); this might confuse the C library. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-02-13 05:15 Message: Logged In: YES user_id=146903 Some libraries (libglade in this case) translate some messages on behalf of the application (libglade translates messages in the input file using the default translation domain, or some other domain specified by the programmer). This is a case of wanting python's gettext module to cooperate with the C level gettext library. For libglade, this could be achieved by making the gettext.bindtextdomain() and gettext.textdomain() calls to call the equivalent C function in addition to what they do now. For most messages in gtk+ itself, it will use dgettext() for most messages already, so isn't a problem. The exception to this is places where it allows other libraries (or the app) to register new stock items, which get translated with a programmer specified domain. As of gettext 0.10.40, there should be no license problems, as the license for the libintl library was changed from GPL to LGPL. It should be a fairly simple to implement this; just needs a patch :) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-02-13 04:17 Message: Logged In: YES user_id=21627 How does gtk invoke gettext? It sounds buggy in the respect that it expects the textdomain to be set globally; a library should not do that. Instead, the right thing (IMO) would be if gtk called dgettext, using an application-supplied domain name. It would be then the matter of the Python gtk wrapper to expose the GTK APIs for setting the text domain. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-12 16:52 Message: Logged In: NO If what you want is a way to call bindtextdomain/textdomain from Python, feel free to supply a patch or ask martin to add intl.so to the distribution. --Guido (@#$% SF always logs me out :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 From noreply at sourceforge.net Thu Jun 15 08:03:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 23:03:43 -0700 Subject: [ python-Bugs-516412 ] Python gettext doesn't support libglade Message-ID: Bugs item #516412, was opened at 2002-02-12 14:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Christian Reis (kiko_async) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade Initial Comment: Libglade is a library that parses XML and generates GTK-based UIs in runtime. It is written in C and supports a number of languages through bindings. James Henstridge has maintained a set of bindings for Python for some time now. These bindings work very well, _except for internationalization_. The reason seems now straightforward to me. Python's gettext.py is a pure python implementation, and because of it, bindtextdomain/textdomain are never called. This causes any C module that uses gettext to not activate the support, and not use translation because of it. Using Martin's intl.so module things work great, but it is a problem for us having to redistribute it with our application. Any other suggestions to fix? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-15 08:03 Message: Logged In: YES user_id=21627 Please don't add messages to a bug report that was closed four years ago. Add a new bug report, explaining your problem. Please be precise in stating what "this" is that you are seeing. ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-15 00:26 Message: Logged In: YES user_id=598622 I am still seeing this with meld application meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-03-27 19:53 Message: Logged In: YES user_id=21627 This is fixed with configure 1.291 configure.in 1.301 pyconfig.h.in 1.25 liblocale.tex 1.28 NEWS 1.369 _localemodule.c 2.29 Notice that applications that want to change the C library's domain bindings will have to invoke locale.bindtextdomain; I decided not to provide automatic forwarding from gettext.bindtextdomain to locale.bindtextdomain, since the C library and Python may have different message catalog formats (e.g. on Solaris); this might confuse the C library. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-02-13 03:15 Message: Logged In: YES user_id=146903 Some libraries (libglade in this case) translate some messages on behalf of the application (libglade translates messages in the input file using the default translation domain, or some other domain specified by the programmer). This is a case of wanting python's gettext module to cooperate with the C level gettext library. For libglade, this could be achieved by making the gettext.bindtextdomain() and gettext.textdomain() calls to call the equivalent C function in addition to what they do now. For most messages in gtk+ itself, it will use dgettext() for most messages already, so isn't a problem. The exception to this is places where it allows other libraries (or the app) to register new stock items, which get translated with a programmer specified domain. As of gettext 0.10.40, there should be no license problems, as the license for the libintl library was changed from GPL to LGPL. It should be a fairly simple to implement this; just needs a patch :) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-02-13 02:17 Message: Logged In: YES user_id=21627 How does gtk invoke gettext? It sounds buggy in the respect that it expects the textdomain to be set globally; a library should not do that. Instead, the right thing (IMO) would be if gtk called dgettext, using an application-supplied domain name. It would be then the matter of the Python gtk wrapper to expose the GTK APIs for setting the text domain. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-12 14:52 Message: Logged In: NO If what you want is a way to call bindtextdomain/textdomain from Python, feel free to supply a patch or ask martin to add intl.so to the distribution. --Guido (@#$% SF always logs me out :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 From noreply at sourceforge.net Thu Jun 15 10:54:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 01:54:50 -0700 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 19:29 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&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.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-15 01:54 Message: Logged In: YES user_id=413 Fixed. I wrapped all DB calls in Lib/bsddb/__init__.py with bsddb.dbutils.DeadlockWrap() and the hammer.py test now works rather than deadlocking. python svn commit r46969 ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-06-07 22:45 Message: Logged In: YES user_id=413 I've added the e.set_lk_detect(db.DB_LOCK_DEFAULT) To the _openDBEnv function so that at the very least the bad threaded behaviour is upgraded from a deadlock to an exception. I'm trying to decide if doing all the DeadlockWrap wrapping is worth it (and if theres an automatic python classish way to do it rather than manually identifying and wrapping all db calls) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:54 Message: Logged In: YES user_id=413 modifying bsddb/__init__.py to wrap all calls with DeadlockWrap will be a bit of a pita (but would be doable). I've attached an example wrapped_hammer.py that demonstrates the _openDBEnv change as well as DeadlockWrap wrapping to work properly. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:31 Message: Logged In: YES user_id=413 oh good i see you already suggested the simple thread calling lock_detect that I was about to suggest. :) regardless a thread isn't needed. see dbenv.set_lk_detect which tells BerkeleyDB to run deadlock detection automatically anytime a lock conflict occurs. http://www.sleepycat.com/docs/api_c/env_set_lk_detect.html Just add e.set_lk_detect(db.DB_LOCK_DEFAULT) to bsddb/__init__.py's _openDBEnv() function. That causes hammer.py to get DBLockDeadlockError exceptions as expected (dying if the main thread gets one). No lock_detect thread needed. The bsddb legacy interface in __init__.py could have all of its database accesses wrapped in the bsddb.dbutils.DeadlockWrap function. to prevent this. (testing now) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 20:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 18:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-05 18:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 12:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 10:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 09:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 07:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 00:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 00:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 23:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-27 22:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 16:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 11:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 15:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 12:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 12:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 12:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 11:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 10:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 09:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 09:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 16:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 01:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Thu Jun 15 11:05:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 02:05:41 -0700 Subject: [ python-Bugs-834461 ] simple bsddb interface potential for deadlock with threads Message-ID: Bugs item #834461, was opened at 2003-11-02 01:30 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: simple bsddb interface potential for deadlock with threads Initial Comment: >From Lib/bsddb/__init__.py # FIXME-20031101-greg: I believe there is still the potential # for deadlocks in a multithreaded environment if someone # attempts to use the any of the cursor interfaces in one # thread while doing a put or delete in another thread. The # reason is that _checkCursor and _closeCursors are not atomic # operations. Doing our own locking around self.dbc, # self.saved_dbc_key and self._iter_cursors could prevent this. # TODO: A test case demonstrating the problem needs to be written. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-11-02 19:29 Message: Logged In: YES user_id=413 A fix for my first comment about the memory leak has been committed that uses weak references and callbacks so that DBCursor objects are always destroyed and their references removed from _DBWithCursor's pool when the iterator that created them is destroyed. The potential threading deadlock issues still stand. Lockng seems like it could have a serious performance impact by surrounding way too many database operations (all cursor operations, iterator use and __delitem__, __setitem__ and close) with locks. what should be done: _DBWithCursor __delitem__, __setitem__ and close methods need to prevent any cursors from being created until they have completed. But for performance reasons multiple database read operations should be allowed at the same time (get, cursor methods or iterators). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-11-02 01:47 Message: Logged In: YES user_id=413 While I'm at it, I think there might be a memory leak in my __iter__ and iteritems() implementation when the resulting generator objects are destroyed without completing their iteration (as will happen in UserDict.DictMixIn.popitem among other things). They add their DBCursor to _DBWithCursor._iter_cursors but only ever delete it from that hash before a return rather than a yield. The solution to this should be simple: have _closeCursors() empty the _iter_cursors hash after calling close() on all of the cursors. __iter__ and iteritems() already ignore a KeyError when trying to remove their cursor from the map when returning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&group_id=5470 From noreply at sourceforge.net Thu Jun 15 18:06:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 09:06:28 -0700 Subject: [ python-Bugs-1506758 ] If MAXFD too high, popen2/subprocess produce MemoryErrors Message-ID: Bugs item #1506758, was opened at 2006-06-15 16:06 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=1506758&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: Peter Vetere (pav3901) Assigned to: Nobody/Anonymous (nobody) Summary: If MAXFD too high, popen2/subprocess produce MemoryErrors Initial Comment: Both the subprocess and the popen2 modules use the range(...) function to iterate over and close inherited file descriptors when a subprocess is spawned. In the OS environment, it possible (using ulimit -n) to set SC_OPEN_MAX (and thus MAXFD in these modules) to a very high value. This can exhaust the limitations of the range() function, producing a MemoryError. The better thing to do would be to use xrange() instead. In particular, this bug occurs in subprocess._close_fds() and popen2._run_child(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&group_id=5470 From noreply at sourceforge.net Thu Jun 15 18:15:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 09:15:54 -0700 Subject: [ python-Bugs-1506758 ] If MAXFD too high, popen2/subprocess produce MemoryErrors Message-ID: Bugs item #1506758, was opened at 2006-06-15 16:06 Message generated for change (Comment added) made by pav3901 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&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: Peter Vetere (pav3901) Assigned to: Nobody/Anonymous (nobody) Summary: If MAXFD too high, popen2/subprocess produce MemoryErrors Initial Comment: Both the subprocess and the popen2 modules use the range(...) function to iterate over and close inherited file descriptors when a subprocess is spawned. In the OS environment, it possible (using ulimit -n) to set SC_OPEN_MAX (and thus MAXFD in these modules) to a very high value. This can exhaust the limitations of the range() function, producing a MemoryError. The better thing to do would be to use xrange() instead. In particular, this bug occurs in subprocess._close_fds() and popen2._run_child(). ---------------------------------------------------------------------- >Comment By: Peter Vetere (pav3901) Date: 2006-06-15 16:15 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&group_id=5470 From noreply at sourceforge.net Thu Jun 15 18:24:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 09:24:46 -0700 Subject: [ python-Bugs-1506776 ] Misleading error message from PyObject_GenericSetAttr Message-ID: Bugs item #1506776, was opened at 2006-06-15 12:24 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=1506776&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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading error message from PyObject_GenericSetAttr Initial Comment: When an extension type Foo defines tp_getattr, but leaves tp_setattr NULL, an attempt to set an attribute bar results in an AttributeError with the message "'Foo' object has no attribute 'bar'". This message is misleading because the object may have the attribute 'bar' as implemented in tp_getattr. It would be better to change the message to "'Foo' object has only read-only attributes (assign to .bar)" as in the case tp_setattro == tp_setattr == NULL in PyObject_SetAttr . I've also noticed that the exceptions raised from PyObject_SetAttr are TypeErrors. Shouldn't PyObject_GenericSetAttr raise a TypeError if tp_setattr is null but tp_getattr is not? This would be consistent with the errors from read-only descriptors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506776&group_id=5470 From noreply at sourceforge.net Thu Jun 15 19:03:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 10:03:19 -0700 Subject: [ python-Bugs-1506799 ] list bug Message-ID: Bugs item #1506799, was opened at 2006-06-15 22: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=1506799&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: SPlyer (splyer) Assigned to: Nobody/Anonymous (nobody) Summary: list bug Initial Comment: When i define class with list member(in class body, not in __init__ or other method) that list become common for all instances of the class. So when i change list member in one instance it also will changed in all the other instances. OS - Windows XP(SP2) [code] class TestClass: t = [] def __init__ (self): pass a = TestClass() b = TestClass() a.t.append(123) print b.t [/code] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506799&group_id=5470 From noreply at sourceforge.net Thu Jun 15 19:14:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 10:14:04 -0700 Subject: [ python-Bugs-1506799 ] list bug Message-ID: Bugs item #1506799, was opened at 2006-06-15 13:03 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506799&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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: SPlyer (splyer) Assigned to: Nobody/Anonymous (nobody) Summary: list bug Initial Comment: When i define class with list member(in class body, not in __init__ or other method) that list become common for all instances of the class. So when i change list member in one instance it also will changed in all the other instances. OS - Windows XP(SP2) [code] class TestClass: t = [] def __init__ (self): pass a = TestClass() b = TestClass() a.t.append(123) print b.t [/code] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-15 13:14 Message: Logged In: YES user_id=31435 Closing as Not-a-Bug. That's exactly what should happen. If you want a different `t` per instance, use a different `t` per instance instead of sharing a common `t` across all instances -- you simply got what you asked for here. If that's not what you want, then, e.g., put "self.t = []" in your __init__ method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506799&group_id=5470 From noreply at sourceforge.net Thu Jun 15 21:31:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 12:31:12 -0700 Subject: [ python-Bugs-1506758 ] If MAXFD too high, popen2/subprocess produce MemoryErrors Message-ID: Bugs item #1506758, was opened at 2006-06-15 16:06 Message generated for change (Comment added) made by pav3901 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&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: Peter Vetere (pav3901) Assigned to: Nobody/Anonymous (nobody) Summary: If MAXFD too high, popen2/subprocess produce MemoryErrors Initial Comment: Both the subprocess and the popen2 modules use the range(...) function to iterate over and close inherited file descriptors when a subprocess is spawned. In the OS environment, it possible (using ulimit -n) to set SC_OPEN_MAX (and thus MAXFD in these modules) to a very high value. This can exhaust the limitations of the range() function, producing a MemoryError. The better thing to do would be to use xrange() instead. In particular, this bug occurs in subprocess._close_fds() and popen2._run_child(). ---------------------------------------------------------------------- >Comment By: Peter Vetere (pav3901) Date: 2006-06-15 19:31 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 ---------------------------------------------------------------------- Comment By: Peter Vetere (pav3901) Date: 2006-06-15 16:15 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&group_id=5470 From noreply at sourceforge.net Thu Jun 15 23:50:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 14:50:04 -0700 Subject: [ python-Bugs-1506945 ] pydoc fails on package in ZIP archive Message-ID: Bugs item #1506945, was opened at 2006-06-15 16:50 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=1506945&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: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Dunn (christopherdunn) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc fails on package in ZIP archive Initial Comment: I have Foo/__init__.py and Foo/bar.py in a ZIP archive, test.zip, which is in the PYTHONPATH. pydoc works on Foo.bar, but fails on package Foo. % pydoc Foo Traceback (most recent call last): File "~/bin/pydoc", line 5, in ? pydoc.cli() File "../python-2.4/lib/python2.4/pydoc.py", line 2228, in cli help.help(arg) File "../python-2.4/lib/python2.4/pydoc.py", line 1682, in help elif request: doc(request, 'Help on %s:') File "../python-2.4/lib/python2.4/pydoc.py", line 1468, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "../python-2.4/lib/python2.4/pydoc.py", line 296, in document if inspect.ismodule(object): return self.docmodule(*args) File "../python-2.4/lib/python2.4/pydoc.py", line 1053, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 20] Not a directory: 'test.zip/Foo' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506945&group_id=5470 From noreply at sourceforge.net Fri Jun 16 00:07:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 15:07:05 -0700 Subject: [ python-Bugs-1506951 ] pydoc fails on package in ZIP archive Message-ID: Bugs item #1506951, was opened at 2006-06-15 17:07 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=1506951&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: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Dunn (christopherdunn) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc fails on package in ZIP archive Initial Comment: I have Foo/__init__.py and Foo/bar.py in a ZIP archive, test.zip, which is in the PYTHONPATH. pydoc works on Foo.bar, but fails on package Foo. % pydoc Foo Traceback (most recent call last): File "~/bin/pydoc", line 5, in ? pydoc.cli() File "../python-2.4/lib/python2.4/pydoc.py", line 2228, in cli help.help(arg) File "../python-2.4/lib/python2.4/pydoc.py", line 1682, in help elif request: doc(request, 'Help on %s:') File "../python-2.4/lib/python2.4/pydoc.py", line 1468, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "../python-2.4/lib/python2.4/pydoc.py", line 296, in document if inspect.ismodule(object): return self.docmodule(*args) File "../python-2.4/lib/python2.4/pydoc.py", line 1053, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 20] Not a directory: 'test.zip/Foo' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506951&group_id=5470 From noreply at sourceforge.net Fri Jun 16 00:08:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 15:08:33 -0700 Subject: [ python-Bugs-1506945 ] pydoc fails on package in ZIP archive Message-ID: Bugs item #1506945, was opened at 2006-06-15 16:50 Message generated for change (Settings changed) made by christopherdunn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506945&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: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Christopher Dunn (christopherdunn) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc fails on package in ZIP archive Initial Comment: I have Foo/__init__.py and Foo/bar.py in a ZIP archive, test.zip, which is in the PYTHONPATH. pydoc works on Foo.bar, but fails on package Foo. % pydoc Foo Traceback (most recent call last): File "~/bin/pydoc", line 5, in ? pydoc.cli() File "../python-2.4/lib/python2.4/pydoc.py", line 2228, in cli help.help(arg) File "../python-2.4/lib/python2.4/pydoc.py", line 1682, in help elif request: doc(request, 'Help on %s:') File "../python-2.4/lib/python2.4/pydoc.py", line 1468, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "../python-2.4/lib/python2.4/pydoc.py", line 296, in document if inspect.ismodule(object): return self.docmodule(*args) File "../python-2.4/lib/python2.4/pydoc.py", line 1053, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 20] Not a directory: 'test.zip/Foo' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506945&group_id=5470 From noreply at sourceforge.net Fri Jun 16 11:32:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 02:32:42 -0700 Subject: [ python-Bugs-1507166 ] HTTPResponse instance has no attribute 'code' Message-ID: Bugs item #1507166, was opened at 2006-06-16 11:32 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=1507166&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: yodalf (yodalf) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPResponse instance has no attribute 'code' Initial Comment: I get this error : Traceback (most recent call last): File "ogbot.py", line 247, in ? main() File "ogbot.py", line 89, in main handle = urlopen(req) File "/usr/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/lib/python2.4/urllib2.py", line 364, in open response = meth(req, response) File "/usr/lib/python2.4/urllib2.py", line 468, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' When I use req = Request("http://some/url.php?session=%s"%(session), data, headers) handle = urlopen(req) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507166&group_id=5470 From noreply at sourceforge.net Fri Jun 16 13:22:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 04:22:58 -0700 Subject: [ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon Message-ID: Bugs item #1507224, was opened at 2006-06-16 13:22 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=1507224&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: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 From noreply at sourceforge.net Fri Jun 16 17:34:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 08:34:13 -0700 Subject: [ python-Bugs-1507379 ] Broken example in optparse module documentation Message-ID: Bugs item #1507379, was opened at 2006-06-16 17:34 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=1507379&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: Michal Krenek (Mikos) (mikos01) Assigned to: Nobody/Anonymous (nobody) Summary: Broken example in optparse module documentation Initial Comment: I have found two bugs in optaparse module documentation. There is example code on http://docs.python.org/lib/optparse-callback-example-6.html, but it doesn't work. First bug is that callback function is named 'vararg_callback', but in parser.add_option is 'callback=varargs' (so to fix it, that callback function must be renamed). Second bug is that there is missing 'dest="some_destination"' argument in parser.add_option. Without it whole example doesn't work (it is throwing 'TypeError: attribute name must be string' exception). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507379&group_id=5470 From noreply at sourceforge.net Sat Jun 17 01:45:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 16:45:37 -0700 Subject: [ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable Message-ID: Bugs item #1504676, was opened at 2006-06-12 06:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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: Sam Ruby (rubys) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make sgmllib char and entity references pluggable Initial Comment: The changes being made to sgmllib in Python 2.5 may break existing applications. This patch makes it easy for subclasses to revert to the old behavior. Additionally, it makes it easier to provide new behaviors, like supporting unicode, hexadecimal character references, and additional entities. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-16 19:45 Message: Logged In: YES user_id=3066 I've commited a modified version of this as revision 46995. The changes I made: - avoid creating a function dynamically when parsing a start tag (used a method instead of a nested def) - indirect the codepoint -> str conversion performed by convert_charref() through a convert_codepoint() method - updated documentation ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 09:06 Message: Logged In: YES user_id=3066 Thanks. I'll look into this again tonight. ---------------------------------------------------------------------- Comment By: Sam Ruby (rubys) Date: 2006-06-14 09:02 Message: Logged In: YES user_id=141556 Note that the pre-existing code transforms tag data twice. Ideally, the handing for entities in attributes and data would be unified. ---------------------------------------------------------------------- Comment By: Sam Ruby (rubys) Date: 2006-06-14 08:59 Message: Logged In: YES user_id=141556 updated patch with test case. Note that in the pre-existing code tag data values are transformed twice -- this should be corrected and ideally the code for handing references should be unified. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-14 01:14 Message: Logged In: YES user_id=3066 This patch certainly makes the subclass interface nicer; I like that. There is a case that it breaks (foolishly not covered by the existing tests, but clear on reading the patch that it broke). I've added the relevant test in this change: http://mail.python.org/pipermail/python-checkins/2006-June/053975.html The problem with the patch is that attribute values are transformed twice (once for entity refs, once for character refs), instead of just once, so entity ref expansions can cause character refs to be located that aren't in the markup. I'm out of time tonight, but should be able to make this patch work with the additional tests tomorrow night if sruby doesn't beat me to it. Documentation and tests for the subclass interface changes are still needed as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470 From noreply at sourceforge.net Sat Jun 17 07:50:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 22:50:27 -0700 Subject: [ python-Bugs-1507166 ] HTTPResponse instance has no attribute 'code' Message-ID: Bugs item #1507166, was opened at 2006-06-16 02:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507166&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: yodalf (yodalf) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPResponse instance has no attribute 'code' Initial Comment: I get this error : Traceback (most recent call last): File "ogbot.py", line 247, in ? main() File "ogbot.py", line 89, in main handle = urlopen(req) File "/usr/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/lib/python2.4/urllib2.py", line 364, in open response = meth(req, response) File "/usr/lib/python2.4/urllib2.py", line 468, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' When I use req = Request("http://some/url.php?session=%s"%(session), data, headers) handle = urlopen(req) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-16 22:50 Message: Logged In: YES user_id=33168 Can you attach a file with a complete python program that demonstrates this problem? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507166&group_id=5470 From noreply at sourceforge.net Sat Jun 17 07:52:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 22:52:14 -0700 Subject: [ python-Bugs-1507379 ] Broken example in optparse module documentation Message-ID: Bugs item #1507379, was opened at 2006-06-16 08:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507379&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michal Krenek (Mikos) (mikos01) Assigned to: Nobody/Anonymous (nobody) Summary: Broken example in optparse module documentation Initial Comment: I have found two bugs in optaparse module documentation. There is example code on http://docs.python.org/lib/optparse-callback-example-6.html, but it doesn't work. First bug is that callback function is named 'vararg_callback', but in parser.add_option is 'callback=varargs' (so to fix it, that callback function must be renamed). Second bug is that there is missing 'dest="some_destination"' argument in parser.add_option. Without it whole example doesn't work (it is throwing 'TypeError: attribute name must be string' exception). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-16 22:52 Message: Logged In: YES user_id=33168 Sorry, you must file a bug report with optik. http://sourceforge.net/projects/optik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507379&group_id=5470 From noreply at sourceforge.net Sat Jun 17 09:54:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 00:54:17 -0700 Subject: [ python-Bugs-1507166 ] HTTPResponse instance has no attribute 'code' Message-ID: Bugs item #1507166, was opened at 2006-06-16 11:32 Message generated for change (Settings changed) made by yodalf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507166&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: Closed Resolution: None Priority: 5 Submitted By: yodalf (yodalf) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPResponse instance has no attribute 'code' Initial Comment: I get this error : Traceback (most recent call last): File "ogbot.py", line 247, in ? main() File "ogbot.py", line 89, in main handle = urlopen(req) File "/usr/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/lib/python2.4/urllib2.py", line 364, in open response = meth(req, response) File "/usr/lib/python2.4/urllib2.py", line 468, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' When I use req = Request("http://some/url.php?session=%s"%(session), data, headers) handle = urlopen(req) ---------------------------------------------------------------------- >Comment By: yodalf (yodalf) Date: 2006-06-17 09:54 Message: Logged In: YES user_id=1278568 Sorry, The problem came from an external module (urlgrabber) which aparently was not up to date. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-17 07:50 Message: Logged In: YES user_id=33168 Can you attach a file with a complete python program that demonstrates this problem? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507166&group_id=5470 From noreply at sourceforge.net Sat Jun 17 20:44:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 11:44:53 -0700 Subject: [ python-Bugs-812986 ] turtle.py deferres exec of stmnts with tracer(0) Message-ID: Bugs item #812986, was opened at 2003-09-26 12:33 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&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: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gregor Lingl (glingl) Assigned to: Martin v. L??wis (loewis) Summary: turtle.py deferres exec of stmnts with tracer(0) Initial Comment: interactive use of turtle.py becomes impossible, e.g.when issuing tracer(0) because in this case apparently updating of Canvas-Widget is deferred ... ... until the next tracer(1) (one can observe this when running the demo() ) Inserting a _canvas.update() call in _draw_turtle() for the case that tracing is off seems to work: def _draw_turtle(self,position=[]): if not self._tracing: self._canvas.update() # <== insert this line! return if position == []: # etc.etc. I have attached a corrected version as turtle_.py Gregor Lingl ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 20:44 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r47007. ---------------------------------------------------------------------- Comment By: Gregor Lingl (glingl) Date: 2003-09-29 00:08 Message: Logged In: YES user_id=505031 OH! Here is the file mentioned above ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-28 16:52 Message: Logged In: YES user_id=2772 You did not attach a file. You must select a filename *and* turn on the checkbox to do so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812986&group_id=5470 From noreply at sourceforge.net Sat Jun 17 21:04:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 12:04:18 -0700 Subject: [ python-Bugs-815924 ] tkMessageBox functions reject type and ico Message-ID: Bugs item #815924, was opened at 2003-10-01 17:19 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815924&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: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Diggins (tdiggins) Assigned to: Martin v. L??wis (loewis) Summary: tkMessageBox functions reject type and ico Initial Comment: Python 2.2.x -> Python 2.3 I've noticed a small separation between documentation and reality in tkMessageBox. According to Fredrik Lundh's documentation of tkMessageBox (in the various online guides & ?printed) you can send type and icon keywords to tkMessageBox's convenience functions (like askquestion) However this doesn't work. Don't know if it used to. So I'm not sure if the docs should be amended or amend the code (originally submitted by Fredrik). An attempt to clear up this bug but was rejected (I think, because they also added a feature). see BUG 761144 https://sourceforge.net/tracker/? func=detail&atid=105470&aid=761144&group_id=5470) A simple way to clean up this would be to amend the first three lines of _show as attached. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 21:04 Message: Logged In: YES user_id=21627 Thanks for the patch; I committed something similar as r47008. Please submit unified diffs in the future; this makes it easier to process them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815924&group_id=5470 From noreply at sourceforge.net Sun Jun 18 21:33:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 12:33:12 -0700 Subject: [ python-Bugs-1508253 ] logging fileConfig swallows handler exception Message-ID: Bugs item #1508253, was opened at 2006-06-18 14:33 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=1508253&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: tdir (tdir) Assigned to: Nobody/Anonymous (nobody) Summary: logging fileConfig swallows handler exception Initial Comment: If you specify a handler such as a RotatingFileHandler and the path you provide in the args specification ('option') is bad, config.fileConfig() catches the exception and 'swallows' it. The result is later on, when that handler is specified for a logger, you get an exception saying there is no such handler. A much friendlier behavior would be for fileConfig() to raise an exception so the real cause of the problem can be easily identified. Also, if there is a bug in the code itself, it would also get swallowed in similar fashion. In general, silently swallowing exceptions is rarely the best choice IMHO. Example ini with bad path (assuming /bad/path does not exist): [handler_defaultrotatingfile] class=handlers.RotatingFileHandler args=("/bad/path/logdir/my_log.log", 'w', 100000, 10) formatter=std ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470 From noreply at sourceforge.net Sun Jun 18 23:09:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 14:09:20 -0700 Subject: [ python-Bugs-1437051 ] "continue" in .pdbrc has no effect Message-ID: Bugs item #1437051, was opened at 2006-02-22 14:13 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437051&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: Coolheads Consulting (coolheads) Assigned to: Nobody/Anonymous (nobody) Summary: "continue" in .pdbrc has no effect Initial Comment: I'm using Python 2.4.2 under Debian Woody; uname -a: Linux bruno 2.4.23 i686 GNU/Linux The documentation for pdb says that commands in .pdbrc will be executed just as if they were typed in at the pdb prompt. However, "c", "cont", and "continue" have no effect. It would be nice if this would work. I discovered this problem because I need to be able to call Python scripts from within a Makefile, and it is convenient, when one of them goes awry (say, because of a key error exception), to already be in the debugger when such exceptions are raised. However, I can't call a Python script with the debugger from a makefile because execution always stops at the beginning of the script, waiting for a "continue" to be typed in at the prompt. I thought I could solve the problem with a "continue" in the .pdbrc in the local directory. However, every way I can think of to say "continue", including aliasing it, has no effect in the .pdbrc. Is there another way to accomplish what I'm trying to do? Steve Newcomb srn at coolheads.com ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 14:09 Message: Logged In: YES user_id=971153 The problem is limited to step/next/continue... "l", "break", etc do work. As far as I can tell the following is happening 1. .pdbrc is read (but not executed!) on pdb startup 2. it's executed when pdb first time enters the interaction() 3. if rc file contains, "continue", then do_continue() IS executed but it has no effect, because pdb's interaction() does not return and simply proceeds with user's input.. (do_continue()/do_next()/do_step() work by setting up a stopping condition and returning to interpreter) The problem can be fixed by having execRcLines check every command's return status and returning as soon as any command returns 1.. Of course, the rest of rclines would need to be executed later... For the record, gdb's .gdbinit files do allow commands like "run"/"continue"/etc If there is any interest in this fix, I can submit a patch ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 18:00 Message: Logged In: YES user_id=593130 I wonder whether the .pdbrc is being read and executed when you think it is. Is the problem actually specific to 'continue'? If you put 'list' in the file, do you get a listing? It might help if you gave the exact command line you use to start the Python script. I don't know if this is really a bug. You might get answers about 'another way' on python- list/comp.lang.python. (I don't know ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437051&group_id=5470 From noreply at sourceforge.net Mon Jun 19 00:19:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 15:19:47 -0700 Subject: [ python-Bugs-1506776 ] Misleading error message from PyObject_GenericSetAttr Message-ID: Bugs item #1506776, was opened at 2006-06-15 16:24 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506776&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: Wont Fix Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading error message from PyObject_GenericSetAttr Initial Comment: When an extension type Foo defines tp_getattr, but leaves tp_setattr NULL, an attempt to set an attribute bar results in an AttributeError with the message "'Foo' object has no attribute 'bar'". This message is misleading because the object may have the attribute 'bar' as implemented in tp_getattr. It would be better to change the message to "'Foo' object has only read-only attributes (assign to .bar)" as in the case tp_setattro == tp_setattr == NULL in PyObject_SetAttr . I've also noticed that the exceptions raised from PyObject_SetAttr are TypeErrors. Shouldn't PyObject_GenericSetAttr raise a TypeError if tp_setattr is null but tp_getattr is not? This would be consistent with the errors from read-only descriptors. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-18 22:19 Message: Logged In: YES user_id=849994 Unfortunately the message "object has only readonly attrs" isn't quite right either, since there may be other attributes that can be set and deleted. I tried to come up with a better message but couldn't find one. The exception type cannot be changed for sure, because of backwards compatibility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506776&group_id=5470 From noreply at sourceforge.net Mon Jun 19 04:08:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 19:08:19 -0700 Subject: [ python-Bugs-1508369 ] logging module formatter problem with %(filename)s Message-ID: Bugs item #1508369, was opened at 2006-06-18 21:08 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=1508369&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: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Hess (david_k_hess) Assigned to: Jack Jansen (jackjansen) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 From noreply at sourceforge.net Mon Jun 19 04:21:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 19:21:43 -0700 Subject: [ python-Bugs-1497962 ] Leak in tarfile.py Message-ID: <200606190221.k5J2LhSX011300@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1497962, was opened at 05/30/06 23:42 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&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: Closed Resolution: None Priority: 5 Submitted By: Jens J?rgen Mortensen (jensj) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in tarfile.py Initial Comment: There is a leak when using the tarfile module and the extractfile method. Here is a simple example: $ echo "grrr" > x.txt $ tar cf x.tar x.txt $ python Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> import tarfile >>> tar = tarfile.open('x.tar', 'r') >>> f = tar.extractfile('x.txt') >>> f.read() 'grrr\n' >>> del f >>> gc.set_debug(gc.DEBUG_LEAK) >>> print gc.collect() gc: collectable gc: collectable gc: collectable 3 >>> print gc.garbage [, {'name': 'x.txt', 'read': >, 'pos': 0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset': 512L, 'linebuffer': '', 'size': 5L}, >] >>> ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 06/18/06 19:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 06/01/06 16:09 Message: Logged In: YES user_id=31435 There's no evidence of a leak here -- quite the contrary. As the docs say, DEBUG_LEAK implies DEBUG_SAVEALL, and DEBUG_SAVEALL results in _all_ cyclic trash getting appended to gc.garbage. If you don't mess with gc.set_debug(), you'll discover that gc.garbage is empty at the end. In addition, note that the DEBUG_LEAK output plainly says: gc: collectable ... That's also telling you that it found collectable cyclic trash (which it would have reclaimed had you not forced it to get appended to gc.garbage instead). If gc had found uncollectable cycles, these msgs would have started with gc: uncollectable ... instead. Most directly, if I run your tarfile open() and file extraction in an infinite loop (without messing with gc.set_debug()), the process memory use does not grow over time. Unless you have other evidence of an actual leak, this report should be closed without action. Yes, there are reference cycles here, but they're of kinds cyclic gc reclaims. ---------------------------------------------------------------------- Comment By: Jens J?rgen Mortensen (jensj) Date: 06/01/06 13:08 Message: Logged In: YES user_id=716463 Problem is that the ExfileObject hat an attribute (self.read) that is a method bound to itself (self._readsparse or self._readnormal). One solution is to add "del self.read" to the close method, but someone might forget to close the object and still get the leak. Another solution is to change the end of __init__ to: if tarinfo.issparse(): self.sparse = tarinfo.sparse else: self.sparse = None and add a read method: def read(self, size=None): if self.sparse is None: return self._readnormal(size) else: return self._readsparse(size) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470 From noreply at sourceforge.net Mon Jun 19 06:56:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 21:56:35 -0700 Subject: [ python-Bugs-1508253 ] logging fileConfig swallows handler exception Message-ID: Bugs item #1508253, was opened at 2006-06-18 12:33 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: tdir (tdir) >Assigned to: Vinay Sajip (vsajip) Summary: logging fileConfig swallows handler exception Initial Comment: If you specify a handler such as a RotatingFileHandler and the path you provide in the args specification ('option') is bad, config.fileConfig() catches the exception and 'swallows' it. The result is later on, when that handler is specified for a logger, you get an exception saying there is no such handler. A much friendlier behavior would be for fileConfig() to raise an exception so the real cause of the problem can be easily identified. Also, if there is a bug in the code itself, it would also get swallowed in similar fashion. In general, silently swallowing exceptions is rarely the best choice IMHO. Example ini with bad path (assuming /bad/path does not exist): [handler_defaultrotatingfile] class=handlers.RotatingFileHandler args=("/bad/path/logdir/my_log.log", 'w', 100000, 10) formatter=std ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470 From noreply at sourceforge.net Mon Jun 19 13:42:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 04:42:28 -0700 Subject: [ python-Bugs-1508564 ] "...." (four dots) confuses doctest's ellipsis matching Message-ID: Bugs item #1508564, was opened at 2006-06-19 21: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=1508564&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: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "...." (four dots) confuses doctest's ellipsis matching Initial Comment: Consider this snippet: from doctest import OutputChecker, ELLIPSIS print OutputChecker().check_output('AAA....', 'AAA.BBB', ELLIPSIS) I expect that to print True, but instead it prints False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&group_id=5470 From noreply at sourceforge.net Mon Jun 19 14:20:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 05:20:41 -0700 Subject: [ python-Bugs-1508564 ] "...." (four dots) confuses doctest's ellipsis matching Message-ID: Bugs item #1508564, was opened at 2006-06-19 07:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&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: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "...." (four dots) confuses doctest's ellipsis matching Initial Comment: Consider this snippet: from doctest import OutputChecker, ELLIPSIS print OutputChecker().check_output('AAA....', 'AAA.BBB', ELLIPSIS) I expect that to print True, but instead it prints False. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-19 08:20 Message: Logged In: YES user_id=31435 Sorry, but this won't change. As in most simple parsers, a "maximal munch" rule is at work for recognizing multi-character tokens: your pattern gets parsed as "AAA" "." not as "AAA." or as "AAA...." Therefore it matches all and only those strings that begin with "AAA" and end with ".". The maximal-munch rules gives an easy-to-predict way of resolving ambiguous inputs, but you're stuck with the way it picks. Because of this, there is no direct way to use ELLIPSIS to get the effect I'm guessing you want (i.e., I'm guessing you want it parsed as "AAA." ). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&group_id=5470 From noreply at sourceforge.net Mon Jun 19 15:48:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 06:48:32 -0700 Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string Message-ID: Bugs item #1472251, was opened at 2006-04-18 12:16 Message generated for change (Settings changed) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: 3 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'run' crashes when the it's first argument is non-string Initial Comment: Pdb 'run/runeval' commands fails to check the type of given argument.When argument to 'run/runeval' is non-string the functions crashes with further impilications on (correctly)invoking this functions: Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31) >>> def x(): pass >>> import pdb >>> pdb.run(x()) Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 363, in run cmd = cmd+'\n' TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run('x()') > /home/jkk/python/python-svn/Lib/pdb.py(1113)run() -> Pdb().run(statement, globals, locals) (Pdb) # CTRL-D pressed Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/home/jkk/python/python-svn/Lib/bdb.py", line 67, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit The solution is to simply ensure that the first argument passed to the 'run/runeval' functions is string. ---------------------------------------------------------------------- >Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-06-19 13:48 Message: Logged In: YES user_id=1491175 You're right,but don't you think that this kind of switching between namespaces could confuse users? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-23 03:36 Message: Logged In: YES user_id=971153 Well, I don't see anything in bdb's run which could overwrite your namespace.. What seems to be happenning in your example is that bdb's first line event happens while bdb is still in run(), so you when you see pdb's prompt, are in bdb's namespace not in yours.. If you do "next" you will get where you should be.. bagira:~> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) >>> def x(): print "in x" >>> import pdb >>> pdb.run( x()) in x TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run( 'x()' ) > /usr/lib/python2.4/pdb.py(987)run() -> Pdb().run(statement, globals, locals) (Pdb) n #now you are back in your namespace > (1)?() (Pdb) p x #and you get your symbols back (Pdb) p pdb (Pdb) n in x --Return-- > (1)?()->None What do you think? ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-05-22 09:20 Message: Logged In: YES user_id=1491175 The point is that when you want to invoke pdb.run correctly (with string argument) after getting TypeError as in above example, your namespace is probably overwritten or deleted so that you don't have access to previously defined symbols. >>> def x():pass >>> import pdb >>> pdb.run(x()) TypeError >>> pdb.run('x()') > /home/jkk/python-svn/Lib/pdb.py(1122)run() -> Pdb().run(statement, globals, locals) (Pdb) pdb *** NameError: name 'pdb' is not defined (Pdb) x *** NameError: name 'x' is not defined ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-21 23:25 Message: Logged In: YES user_id=971153 I would not classify your example as a crash. You passed a wrong value (None in your case) into pdb.run() and got back a TypeError...Isn't it an expected response? E.g if you do: >>>max(13) You'll also get: "TypeError" Am I missing something? Could you clarify? ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-04-18 12:36 Message: Logged In: YES user_id=1491175 Patch is in #1472257 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 From noreply at sourceforge.net Mon Jun 19 16:35:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 07:35:47 -0700 Subject: [ python-Bugs-1508564 ] "...." (four dots) confuses doctest's ellipsis matching Message-ID: Bugs item #1508564, was opened at 2006-06-19 11:42 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&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: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "...." (four dots) confuses doctest's ellipsis matching Initial Comment: Consider this snippet: from doctest import OutputChecker, ELLIPSIS print OutputChecker().check_output('AAA....', 'AAA.BBB', ELLIPSIS) I expect that to print True, but instead it prints False. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-19 12:20 Message: Logged In: YES user_id=31435 Sorry, but this won't change. As in most simple parsers, a "maximal munch" rule is at work for recognizing multi-character tokens: your pattern gets parsed as "AAA" "." not as "AAA." or as "AAA...." Therefore it matches all and only those strings that begin with "AAA" and end with ".". The maximal-munch rules gives an easy-to-predict way of resolving ambiguous inputs, but you're stuck with the way it picks. Because of this, there is no direct way to use ELLIPSIS to get the effect I'm guessing you want (i.e., I'm guessing you want it parsed as "AAA." ). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508564&group_id=5470 From noreply at sourceforge.net Mon Jun 19 16:39:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 07:39:55 -0700 Subject: [ python-Bugs-1508369 ] logging module formatter problem with %(filename)s Message-ID: Bugs item #1508369, was opened at 2006-06-19 02:08 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&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: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Hess (david_k_hess) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 From noreply at sourceforge.net Mon Jun 19 19:44:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 10:44:30 -0700 Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation Message-ID: Bugs item #1501934, was opened at 2006-06-07 01:57 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Wouters (twouters) Assigned to: Jeremy Hylton (jhylton) Summary: incorrect LOAD/STORE_GLOBAL generation Initial Comment: Python 2.5 compiles the following piece of code differently than Python 2.4: g = 1 def f(): g += 1 In Python 2.4, this raises an UnboundLocalError. In current svn trunk, it will increment the global g by 1. (dis.dis shows that it actually compiles into LOAD/STORE_GLOBAL opcodes.) It seems the compiler doesn't treat augmented assignment as assignment for the purpose of determining locals, as this still fails correctly: g = 1 def f(): g += 1 g = 5 I can't find where this optimization happens nowadays, but it feels like a short fix. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-06-19 19:44 Message: Logged In: YES user_id=34209 Possibly related is the discovery of free variables (used when forming closures) and optimized-out codeblocks: >>> def foo(x): ... def bar(): ... if 0: ... print x ... return bar In 2.4, there is no closure: >>> foo.func_code.co_cellvars () >>> foo(5).func_closure >>> In 2.5, there is: >>> foo.func_code.co_cellvars ('x',) >>> foo(5).func_closure (,) (I don't think it's unreasonable to declare the old behaviour bugged, though :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470 From noreply at sourceforge.net Mon Jun 19 20:48:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 11:48:42 -0700 Subject: [ python-Bugs-1508833 ] os.spawnv fails when argv is a length 1 tuple Message-ID: Bugs item #1508833, was opened at 2006-06-19 11:48 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=1508833&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: ncloud (ncloud) Assigned to: Nobody/Anonymous (nobody) Summary: os.spawnv fails when argv is a length 1 tuple Initial Comment: os.spawnv fails when argv is a length 1 tuple. For example, this will fail: os.spawnv (os.P_WAIT, '/bin/pwd', ('/bin/pwd')) Bug exists on Python 2.4.3 on FreeBSD. Bug exists on Python 2.3.5 on Gentoo Linux. Longer example: ---- $ cat test.py import os path = '/bin/pwd' print print 'calling os.spawnv with length 1 tuple...' print 'exit code:', os.spawnv ( os.P_WAIT, path, ( path ) ) print print 'calling os.spawnv with length 1 list...' print 'exit code:', os.spawnv ( os.P_WAIT, path, [ path ] ) print ---- ---- $ python test.py calling os.spawnv with length 1 tuple... exit code: 127 calling os.spawnv with length 1 list... /home/private exit code: 0 ---- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&group_id=5470 From noreply at sourceforge.net Mon Jun 19 21:20:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 12:20:27 -0700 Subject: [ python-Bugs-1508848 ] failed to load tuxedo libs Message-ID: Bugs item #1508848, was opened at 2006-06-19 19: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=1508848&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.3 Status: Open Resolution: None Priority: 5 Submitted By: William Ding (dingwen_ca) Assigned to: Nobody/Anonymous (nobody) Summary: failed to load tuxedo libs Initial Comment: we have a tuxedo(BEA) python extension, the extension works very well under solaris/AIX, it has issue with HPUX(PA-RISC or ITANINM) with python 2.3.2 and 2.3.5 >>> import tuxedo # /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxedo.p yc has bad mtime import tuxedo # from /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxed o.py # can't create /usr1/arbor/3p/terrapin/HPUX/python/modules/tux edo.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/re.py import re # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.py import sre # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compile. pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co mpile.py import sre_compile # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compi le.pyc import _sre # builtin # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_constant s.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co nstants.py import sre_constants # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_const ants.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse.py c matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_pa rse.py import sre_parse # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse .pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/string.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/string .py import string # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/string.py c shl_load /usr1/arbor/3ppython/HPUX/lib/python2.3/lib- dynload/strop.so shl_findsym initstrop import strop # dynamically loaded from /usr1/arbor/3ppython/HPUX/lib/python2.3/lib- dynload/strop.so shl_load _tuxedowsnmodule.so /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_strpresend' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_strencdec' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_sfilter' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_sformat' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_finit' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. _tuxedowsnmodule.so is our python interface lib, from 'ldd -r' output, the lib itself should not have any issue, but when we tried to load it to python, it complained, bash-3.00$ ldd _tuxedowsnmodule.so libwsc.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libpthread.so.1 => /usr/lib/hpux64/libpthread.so.1 libnsl.so.1 => /usr/lib/hpux64/libnsl.so.1 libm.so.1 => /usr/lib/hpux64/libm.so.1 libc.so.1 => /usr/lib/hpux64/libc.so.1 libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libgiconv.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgiconv.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libxti.so.1 => /usr/lib/hpux64/libxti.so.1 libdl.so.1 => /usr/lib/hpux64/libdl.so.1 bash-3.00$ ldd -r _tuxedowsnmodule.so libwsc.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libpthread.so.1 => /usr/lib/hpux64/libpthread.so.1 libnsl.so.1 => /usr/lib/hpux64/libnsl.so.1 libm.so.1 => /usr/lib/hpux64/libm.so.1 libc.so.1 => /usr/lib/hpux64/libc.so.1 libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libgiconv.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgiconv.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libxti.so.1 => /usr/lib/hpux64/libxti.so.1 libdl.so.1 => /usr/lib/hpux64/libdl.so.1 symbol not found: Py_InitModule4 (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyModule_GetDict (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyExc_IOError (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_AsString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFloat_FromDouble (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyEval_SaveThread (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_Malloc (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_SetObject (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_Occurred (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFloat_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyExc_TypeError (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyInt_FromLong (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyEval_RestoreThread (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_GetAttrString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyInt_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyCObject_AsVoidPtr (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyType_IsSubtype (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyTuple_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyInt_AsLong (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_Size (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_CallFunction (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_Init (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_CallMethod (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFile_AsFile (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyArg_ParseTuple (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyImport_ImportModule (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_NewException (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_FromString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyDict_GetItemString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyDict_SetItemString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFloat_AsDouble (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyType_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: Py_FindMethod (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFile_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_FromStringAndSize (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyCObject_FromVoidPtr (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_SetString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: _Py_NoneStruct (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: Py_BuildValue (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: main (/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl) symbol not found: main (/usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl) symbol not found: main (/usr/lib/hpux64/libc.so.1) we looked at the python source code, and think we found the cause of the issue: case $ac_sys_system/$ac_sys_release in AIX*) DYNLOADFILE="dynload_aix.o";; BeOS*) DYNLOADFILE="dynload_beos.o";; hp*|HP*) DYNLOADFILE="dynload_hpux.o";; Darwin/*) DYNLOADFILE="dynload_next.o";; atheos*) DYNLOADFILE="dynload_atheos.o";; *) # use dynload_shlib.c and dlopen() if we have it; otherwise stub # out any dynamic loading if test "$ac_cv_func_dlopen" = yes then DYNLOADFILE="dynload_shlib.o" else DYNLOADFILE="dynload_stub.o" fi where on hpux the file dynload_hpux is used. Looking inside Python/dynload_hpux.c; flags = BIND_FIRST | BIND_DEFERRED; if (Py_VerboseFlag) { flags = BIND_FIRST | BIND_IMMEDIATE | BIND_NONFATAL | BIND_VERBOSE; printf("shl_load %s\n",pathname); } lib = shl_load(pathname, flags, 0); /* XXX Chuck Blake once wrote that 0 should be BIND_NOSTART? */ if (lib == NULL) { char buf[256]; if (Py_VerboseFlag) perror(pathname); PyOS_snprintf(buf, sizeof(buf), "Failed to load %.200s", pathname); PyErr_SetString(PyExc_ImportError, buf); return NULL; } We looked through the shl_load man page and found that Python should be using the option BIND_TOGETHER. I tried it and it loads the tuxedo module. shl_load man page; BIND_TOGETHER When used with BIND_FIRST, the library being mapped and its dependent libraries will be bound together. This is the default behavior for all shl_load() requests not using BIND_FIRST. So we changed the /Python- 2.3.2/Python/dynaload_hpux.c to; flags = BIND_FIRST | BIND_DEFERRED | BIND_TOGETHER; if (Py_VerboseFlag) { flags = BIND_FIRST | BIND_IMMEDIATE | BIND_TOGETHER | BIND_NONFATAL | BIND_VERBOSE; printf("shl_load %s\n",pathname); } Not sure if there is version of python without the bug, and if it is possible to patch 2.3.2 and 2.3.5 OS tested: B.11.23 U 9000/800 (PA-RISC and ITANIUM) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508848&group_id=5470 From noreply at sourceforge.net Mon Jun 19 21:54:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 12:54:00 -0700 Subject: [ python-Bugs-1508864 ] threading.Timer breaks when you change system time on win32 Message-ID: Bugs item #1508864, was opened at 2006-06-19 14: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=1508864&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer breaks when you change system time on win32 Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 From noreply at sourceforge.net Mon Jun 19 22:00:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 13:00:54 -0700 Subject: [ python-Bugs-1508833 ] os.spawnv fails when argv is a length 1 tuple Message-ID: Bugs item #1508833, was opened at 2006-06-19 11:48 Message generated for change (Settings changed) made by ncloud You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&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: Invalid Priority: 5 Submitted By: ncloud (ncloud) Assigned to: Nobody/Anonymous (nobody) Summary: os.spawnv fails when argv is a length 1 tuple Initial Comment: os.spawnv fails when argv is a length 1 tuple. For example, this will fail: os.spawnv (os.P_WAIT, '/bin/pwd', ('/bin/pwd')) Bug exists on Python 2.4.3 on FreeBSD. Bug exists on Python 2.3.5 on Gentoo Linux. Longer example: ---- $ cat test.py import os path = '/bin/pwd' print print 'calling os.spawnv with length 1 tuple...' print 'exit code:', os.spawnv ( os.P_WAIT, path, ( path ) ) print print 'calling os.spawnv with length 1 list...' print 'exit code:', os.spawnv ( os.P_WAIT, path, [ path ] ) print ---- ---- $ python test.py calling os.spawnv with length 1 tuple... exit code: 127 calling os.spawnv with length 1 list... /home/private exit code: 0 ---- ---------------------------------------------------------------------- >Comment By: ncloud (ncloud) Date: 2006-06-19 13:00 Message: Logged In: YES user_id=1542556 My apologies. I'm new to python and had not realize that ( x ) is not a tuple, while ( x, ) is a tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&group_id=5470 From noreply at sourceforge.net Mon Jun 19 22:54:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 13:54:35 -0700 Subject: [ python-Bugs-1508833 ] os.spawnv fails when argv is a length 1 tuple Message-ID: Bugs item #1508833, was opened at 2006-06-19 18:48 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&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: Closed Resolution: Invalid Priority: 5 Submitted By: ncloud (ncloud) Assigned to: Nobody/Anonymous (nobody) Summary: os.spawnv fails when argv is a length 1 tuple Initial Comment: os.spawnv fails when argv is a length 1 tuple. For example, this will fail: os.spawnv (os.P_WAIT, '/bin/pwd', ('/bin/pwd')) Bug exists on Python 2.4.3 on FreeBSD. Bug exists on Python 2.3.5 on Gentoo Linux. Longer example: ---- $ cat test.py import os path = '/bin/pwd' print print 'calling os.spawnv with length 1 tuple...' print 'exit code:', os.spawnv ( os.P_WAIT, path, ( path ) ) print print 'calling os.spawnv with length 1 list...' print 'exit code:', os.spawnv ( os.P_WAIT, path, [ path ] ) print ---- ---- $ python test.py calling os.spawnv with length 1 tuple... exit code: 127 calling os.spawnv with length 1 list... /home/private exit code: 0 ---- ---------------------------------------------------------------------- Comment By: ncloud (ncloud) Date: 2006-06-19 20:00 Message: Logged In: YES user_id=1542556 My apologies. I'm new to python and had not realize that ( x ) is not a tuple, while ( x, ) is a tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508833&group_id=5470 From noreply at sourceforge.net Tue Jun 20 01:59:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 16:59:30 -0700 Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat Message-ID: Bugs item #1295808, was opened at 2005-09-19 21:44 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&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: Trent Mick (tmick) Assigned to: Martin v. L??wis (loewis) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-06-19 23:59 Message: Logged In: YES user_id=34892 Sending Modules/expat/expat_external.h Adding Modules/expat/pyexpatns.h Transmitting file data .. Committed revision 47034. I upgraded Python's expat to 2.0.0 immediately before and checked that no new symbols where added (i.e. no new #define's necessary for the patch). ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-19 00:25 Message: Logged In: YES user_id=34892 As well, *possibly* the same should be done for Python's bz2.so, although the only relevant exported symbol is Util_UnivNewlineRead nm bz2.so \ | grep -v " [a-zBUA] " \ | grep -v "_fini\|_init\|initbz2" ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-18 23:58 Message: Logged In: YES user_id=34892 Attempted summary to get this patch into Python 2.5: As Neal points out this is a duplicate of . The patch on *that* bug fixes the specific issue, but does not solve the general problem (as 'mwh' pointed out in the comments there). I think we should 1. apply this patch 2. then perhaps update our expat version (see http://python.org/sf/1433435, http://mail.python.org/pipermail/python-dev/2006-March/062287.html), 3. then update Modules/expat/pyexpatns.h (that this patch adds) for any new symbols in the new version of Expat. Neal, Martin, Michael, what do you think? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-01-24 23:34 Message: Logged In: YES user_id=34892 > This seems to be a duplicate of bug #1075984. You are right. > Trent, is this patch sufficient to meet your embedding > needs so that nothing else needs to be done? Yes. > I do not think this patch can be applied to 2.4. That's fine. Getting this into Python >=2.5 would be good enough. Martin, Have you had a chance to review this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 From noreply at sourceforge.net Tue Jun 20 02:00:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 17:00:36 -0700 Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat Message-ID: Bugs item #1295808, was opened at 2005-09-19 21:44 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&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: Closed Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) >Assigned to: Trent Mick (tmick) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-06-19 23:59 Message: Logged In: YES user_id=34892 Sending Modules/expat/expat_external.h Adding Modules/expat/pyexpatns.h Transmitting file data .. Committed revision 47034. I upgraded Python's expat to 2.0.0 immediately before and checked that no new symbols where added (i.e. no new #define's necessary for the patch). ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-19 00:25 Message: Logged In: YES user_id=34892 As well, *possibly* the same should be done for Python's bz2.so, although the only relevant exported symbol is Util_UnivNewlineRead nm bz2.so \ | grep -v " [a-zBUA] " \ | grep -v "_fini\|_init\|initbz2" ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-18 23:58 Message: Logged In: YES user_id=34892 Attempted summary to get this patch into Python 2.5: As Neal points out this is a duplicate of . The patch on *that* bug fixes the specific issue, but does not solve the general problem (as 'mwh' pointed out in the comments there). I think we should 1. apply this patch 2. then perhaps update our expat version (see http://python.org/sf/1433435, http://mail.python.org/pipermail/python-dev/2006-March/062287.html), 3. then update Modules/expat/pyexpatns.h (that this patch adds) for any new symbols in the new version of Expat. Neal, Martin, Michael, what do you think? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-01-24 23:34 Message: Logged In: YES user_id=34892 > This seems to be a duplicate of bug #1075984. You are right. > Trent, is this patch sufficient to meet your embedding > needs so that nothing else needs to be done? Yes. > I do not think this patch can be applied to 2.4. That's fine. Getting this into Python >=2.5 would be good enough. Martin, Have you had a chance to review this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 From noreply at sourceforge.net Tue Jun 20 06:30:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 21:30:39 -0700 Subject: [ python-Feature Requests-1509060 ] Interrupt/kill threads w/exception Message-ID: Feature Requests item #1509060, was opened at 2006-06-20 04:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509060&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Bock (oliverbock) Assigned to: Nobody/Anonymous (nobody) Summary: Interrupt/kill threads w/exception Initial Comment: When unsophisticated (but not evil) users write Python macros, they occasionally write infinite loops. It would be nice if it was possible to interrupt threads to break these loops. The safety of rasing an exception in another thread was noted in http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Anton Wilson wrote a patch for this some time ago: http://mail.python.org/pipermail/python-list/2003-February/148999.html Note that this won't help if the thread is blocked on I/O. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509060&group_id=5470 From noreply at sourceforge.net Tue Jun 20 06:39:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 21:39:44 -0700 Subject: [ python-Bugs-1508848 ] failed to load tuxedo libs Message-ID: Bugs item #1508848, was opened at 2006-06-19 12:20 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508848&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.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: William Ding (dingwen_ca) Assigned to: Nobody/Anonymous (nobody) Summary: failed to load tuxedo libs Initial Comment: we have a tuxedo(BEA) python extension, the extension works very well under solaris/AIX, it has issue with HPUX(PA-RISC or ITANINM) with python 2.3.2 and 2.3.5 >>> import tuxedo # /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxedo.p yc has bad mtime import tuxedo # from /usr1/arbor/3p/terrapin/HPUX/python/modules/tuxed o.py # can't create /usr1/arbor/3p/terrapin/HPUX/python/modules/tux edo.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/re.py import re # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/re.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.py import sre # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compile. pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co mpile.py import sre_compile # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_compi le.pyc import _sre # builtin # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_constant s.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_co nstants.py import sre_constants # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_const ants.pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse.py c matches /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_pa rse.py import sre_parse # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/sre_parse .pyc # /usr1/arbor/3ppython/HPUX/lib/python2.3/string.pyc matches /usr1/arbor/3ppython/HPUX/lib/python2.3/string .py import string # precompiled from /usr1/arbor/3ppython/HPUX/lib/python2.3/string.py c shl_load /usr1/arbor/3ppython/HPUX/lib/python2.3/lib- dynload/strop.so shl_findsym initstrop import strop # dynamically loaded from /usr1/arbor/3ppython/HPUX/lib/python2.3/lib- dynload/strop.so shl_load _tuxedowsnmodule.so /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_strpresend' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_strencdec' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_sfilter' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_sformat' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. /usr/lib/hpux64/dld.so: Unsatisfied code symbol '_finit' in load module '/usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl'. _tuxedowsnmodule.so is our python interface lib, from 'ldd -r' output, the lib itself should not have any issue, but when we tried to load it to python, it complained, bash-3.00$ ldd _tuxedowsnmodule.so libwsc.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libpthread.so.1 => /usr/lib/hpux64/libpthread.so.1 libnsl.so.1 => /usr/lib/hpux64/libnsl.so.1 libm.so.1 => /usr/lib/hpux64/libm.so.1 libc.so.1 => /usr/lib/hpux64/libc.so.1 libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libgiconv.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgiconv.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libxti.so.1 => /usr/lib/hpux64/libxti.so.1 libdl.so.1 => /usr/lib/hpux64/libdl.so.1 bash-3.00$ ldd -r _tuxedowsnmodule.so libwsc.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libwsc.sl libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libpthread.so.1 => /usr/lib/hpux64/libpthread.so.1 libnsl.so.1 => /usr/lib/hpux64/libnsl.so.1 libm.so.1 => /usr/lib/hpux64/libm.so.1 libc.so.1 => /usr/lib/hpux64/libc.so.1 libbuft.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libbuft.sl libgpnet.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgpnet.sl libgiconv.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libgiconv.sl libfml.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl libfml32.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libengine.sl => /usr1/arbor/3p/tuxedo/HPUX/lib/libengine.sl libxti.so.1 => /usr/lib/hpux64/libxti.so.1 libdl.so.1 => /usr/lib/hpux64/libdl.so.1 symbol not found: Py_InitModule4 (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyModule_GetDict (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyExc_IOError (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_AsString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFloat_FromDouble (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyEval_SaveThread (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_Malloc (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_SetObject (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_Occurred (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFloat_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyExc_TypeError (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyInt_FromLong (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyEval_RestoreThread (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_GetAttrString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyInt_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyCObject_AsVoidPtr (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyType_IsSubtype (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyTuple_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyInt_AsLong (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_Size (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_CallFunction (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_Init (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyObject_CallMethod (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFile_AsFile (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyArg_ParseTuple (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyImport_ImportModule (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_NewException (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_FromString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyDict_GetItemString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyDict_SetItemString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFloat_AsDouble (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyType_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: Py_FindMethod (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyFile_Type (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyString_FromStringAndSize (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyCObject_FromVoidPtr (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: PyErr_SetString (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: _Py_NoneStruct (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: Py_BuildValue (/usr1/arbor/3p/terrapin/HPUX/lib/_tuxedowsnmodule.so) symbol not found: main (/usr1/arbor/3p/tuxedo/HPUX/lib/libfml.sl) symbol not found: main (/usr1/arbor/3p/tuxedo/HPUX/lib/libfml32.sl) symbol not found: main (/usr/lib/hpux64/libc.so.1) we looked at the python source code, and think we found the cause of the issue: case $ac_sys_system/$ac_sys_release in AIX*) DYNLOADFILE="dynload_aix.o";; BeOS*) DYNLOADFILE="dynload_beos.o";; hp*|HP*) DYNLOADFILE="dynload_hpux.o";; Darwin/*) DYNLOADFILE="dynload_next.o";; atheos*) DYNLOADFILE="dynload_atheos.o";; *) # use dynload_shlib.c and dlopen() if we have it; otherwise stub # out any dynamic loading if test "$ac_cv_func_dlopen" = yes then DYNLOADFILE="dynload_shlib.o" else DYNLOADFILE="dynload_stub.o" fi where on hpux the file dynload_hpux is used. Looking inside Python/dynload_hpux.c; flags = BIND_FIRST | BIND_DEFERRED; if (Py_VerboseFlag) { flags = BIND_FIRST | BIND_IMMEDIATE | BIND_NONFATAL | BIND_VERBOSE; printf("shl_load %s\n",pathname); } lib = shl_load(pathname, flags, 0); /* XXX Chuck Blake once wrote that 0 should be BIND_NOSTART? */ if (lib == NULL) { char buf[256]; if (Py_VerboseFlag) perror(pathname); PyOS_snprintf(buf, sizeof(buf), "Failed to load %.200s", pathname); PyErr_SetString(PyExc_ImportError, buf); return NULL; } We looked through the shl_load man page and found that Python should be using the option BIND_TOGETHER. I tried it and it loads the tuxedo module. shl_load man page; BIND_TOGETHER When used with BIND_FIRST, the library being mapped and its dependent libraries will be bound together. This is the default behavior for all shl_load() requests not using BIND_FIRST. So we changed the /Python- 2.3.2/Python/dynaload_hpux.c to; flags = BIND_FIRST | BIND_DEFERRED | BIND_TOGETHER; if (Py_VerboseFlag) { flags = BIND_FIRST | BIND_IMMEDIATE | BIND_TOGETHER | BIND_NONFATAL | BIND_VERBOSE; printf("shl_load %s\n",pathname); } Not sure if there is version of python without the bug, and if it is possible to patch 2.3.2 and 2.3.5 OS tested: B.11.23 U 9000/800 (PA-RISC and ITANIUM) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-19 21:39 Message: Logged In: YES user_id=33168 Python 2.3 is no longer supported. There was a problem with not supporting .so extensions on HP-UX for ia64. That was committed to Python 2.5 in revision 46046 from Bug/Patch #1481770. You can try to apply that patch to Python 2.3 and see if it fixes the problem. I don't know if the patch was backported to 2.4. If your fix works for you, I suggest running with it. If this problem still affects Python 2.4 or later, please re-open this bug report. Note: No Python developer has access to HP boxes AFAIK. It's very hard for us to verify these changes. We have no HP-UX boxes running the buildbot http://www.python.org/dev/buildbot/all/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508848&group_id=5470 From noreply at sourceforge.net Tue Jun 20 08:25:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 23:25:54 -0700 Subject: [ python-Feature Requests-1433435 ] Use new expat version 2.0 Message-ID: Feature Requests item #1433435, was opened at 2006-02-17 09:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&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: XML Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Use new expat version 2.0 Initial Comment: New expat version 2.0 is released. This one schould be used in the next python release (2.5). I checked the repository and feature request and there is no note about usage of new expat versions. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 06:25 Message: Logged In: YES user_id=849994 The patch was applied in rev. 47033. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-07 13:26 Message: Logged In: YES user_id=1326842 There is a patch now: #1462338 upgrade pyexpat to expat 2.0.0 http://www.python.org/sf/1462338 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470 From noreply at sourceforge.net Tue Jun 20 10:17:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 01:17:44 -0700 Subject: [ python-Bugs-1509132 ] compiler module builds incorrect AST for TryExceptFinally Message-ID: Bugs item #1509132, was opened at 2006-06-20 10:17 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=1509132&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: Adrien Di Mascio (adimasci) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module builds incorrect AST for TryExceptFinally Initial Comment: the finally clause in a try ... except ... finally statement is seen as a "else" clause by transformer.py. There is no special code to handle finally clauses for a try / except node (Maybe ast.TryExcept should accept a finally_ argument after the else_ one) Python version : 2.5b1 (r46858) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&group_id=5470 From noreply at sourceforge.net Tue Jun 20 15:21:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 06:21:08 -0700 Subject: [ python-Bugs-1504456 ] xmlcore needs to be documented Message-ID: Bugs item #1504456, was opened at 2006-06-11 15:50 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&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: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlcore needs to be documented Initial Comment: The change from the "xml" package to the "xmlcore" package needs to be documented for Python 2.5. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-20 09:20 Message: Logged In: YES user_id=11375 I've added this to rev. 47044 of the "What's New". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 From noreply at sourceforge.net Tue Jun 20 17:57:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 08:57:03 -0700 Subject: [ python-Bugs-1509132 ] compiler module builds incorrect AST for TryExceptFinally Message-ID: Bugs item #1509132, was opened at 2006-06-20 08:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&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: Fixed Priority: 5 Submitted By: Adrien Di Mascio (adimasci) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module builds incorrect AST for TryExceptFinally Initial Comment: the finally clause in a try ... except ... finally statement is seen as a "else" clause by transformer.py. There is no special code to handle finally clauses for a try / except node (Maybe ast.TryExcept should accept a finally_ argument after the else_ one) Python version : 2.5b1 (r46858) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 15:57 Message: Logged In: YES user_id=849994 Thanks for reporting! I fixed this and will commit as soon as the trunk is unfrozen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&group_id=5470 From noreply at sourceforge.net Wed Jun 21 01:17:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 16:17:25 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-06 01:14 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-21 09:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-03 07:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-03 06:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-04-06 01:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Wed Jun 21 10:47:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 01:47:18 -0700 Subject: [ python-Feature Requests-1509798 ] replace dist/src/Tools/scripts/which.py with tmick's which Message-ID: Feature Requests item #1509798, was opened at 2006-06-21 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&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: 5 Submitted By: wrstl prmpft (wrstlprmpft) Assigned to: Nobody/Anonymous (nobody) Summary: replace dist/src/Tools/scripts/which.py with tmick's which Initial Comment: see http://starship.python.net/~tmick/#which The author agrees with me in his README. Even better: include which as a module in the standard library so it can be used programmatically and as:: python -m which ... or maybe:: python -m os.which ... cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509798&group_id=5470 From noreply at sourceforge.net Wed Jun 21 19:45:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 10:45:30 -0700 Subject: [ python-Bugs-1509132 ] compiler module builds incorrect AST for TryExceptFinally Message-ID: Bugs item #1509132, was opened at 2006-06-20 08:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&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: Adrien Di Mascio (adimasci) Assigned to: Nobody/Anonymous (nobody) Summary: compiler module builds incorrect AST for TryExceptFinally Initial Comment: the finally clause in a try ... except ... finally statement is seen as a "else" clause by transformer.py. There is no special code to handle finally clauses for a try / except node (Maybe ast.TryExcept should accept a finally_ argument after the else_ one) Python version : 2.5b1 (r46858) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-21 17:45 Message: Logged In: YES user_id=849994 Fixed in rev. 47057. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 15:57 Message: Logged In: YES user_id=849994 Thanks for reporting! I fixed this and will commit as soon as the trunk is unfrozen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1509132&group_id=5470 From noreply at sourceforge.net Wed Jun 21 21:35:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 12:35:52 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-21 13:35 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=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Wed Jun 21 23:16:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 14:16:36 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-21 12:35 Message generated for change (Comment added) made by mnot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 14:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Thu Jun 22 00:59:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 15:59:52 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-21 21:35 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-22 00:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 23:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Thu Jun 22 01:57:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 16:57:31 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-21 13:35 Message generated for change (Comment added) made by mitchchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- >Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-21 17:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-21 16:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 15:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Thu Jun 22 02:14:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 17:14:46 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 12:19 Message generated for change (Comment added) made by theaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- >Comment By: Tim Heaney (theaney) Date: 2006-06-22 00:14 Message: Logged In: YES user_id=827666 Sorry, I haven't had a chance to look at this again. I just installed Python-2.5b1 and it's still the same way. Here's what I did to fix things up after the make altinstall... # cd /usr/local/bin # for file in pydoc idle smtpd.py python-config; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done Now, how to fix up the Makefile.pre and setup.py so this isn't necessary... ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-06 11:19 Message: Logged In: YES user_id=827666 I'm not sure I know how. It looks like the downloaded files have the following shebang lines Tools/scripts/pydoc => #!/usr/bin/env python Tools/scripts/idle => #! /usr/bin/env python Lib/smtpd.py => #! /usr/bin/env python Misc/python-config.in => #!@BINDIR@/python whereas the installed files have /usr/local/bin/pydoc => #!/usr/local/bin/python /usr/local/bin/idle => #!/usr/local/bin/python /usr/local/bin/smtpd.py => #!/usr/local/bin/python /usr/local/bin/python-config => #!/usr/local/bin/python so they're already getting rewritten somewhere. We want both their names and their shebang lines to have the version /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5 It seems that python-config appears in the Makefile, so adding something like sed -e "s, at BINDIR@,$(BINDIR)," < $(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE) $(INSTALL_SCRIPT) python-config $(BINDIR)/python-config$(VERSION)$(EXE) rm python-config to Makefile.pre.in in an altlibainstall section or something might be all we need for that. The others are named in setup.py # Scripts to install scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] but I haven't worked out where they get rewritten or installed yet. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 20:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Thu Jun 22 05:57:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 20:57:15 -0700 Subject: [ python-Feature Requests-513840 ] entity unescape for sgml/htmllib Message-ID: Feature Requests item #513840, was opened at 2002-02-06 12:55 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=513840&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: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: entity unescape for sgml/htmllib Initial Comment: The parsers defined in htmllib and sgmllib do not provide any facilities for unescaping a tag attribute which has an embedded html entityref (i.e., they do not provide a way to convert "a&amp;b" to "a&b"). The parser in HTMLParser unescapes all tag attributes automatically. I'm not sure that's the right approach for sgmllib and htmllib (since it might break existing code), but it seems to me that one of the modules ought to provide a function or method which can do the unescaping if needed. (I'm not familiar with either the SGML or the HTML specification, but I assume one of them mandates the escaping of '&' (e.g.) in tag attributes. If so, then it seems appropriate for one of the modules to provide a function which undoes the mandated transformation.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-21 23:57 Message: Logged In: YES user_id=3066 This request is making me reconsider some other changes that have already been made on the trunk (and are now in 2.5b1). Reading this, I thought "Doesn't it already do that?" Turns out that in Python 2.4, it doesn't. Both versions handle this in parsed character data; the difference is confined to attribute values. I'd like to propose adding a Boolean configuration attribute on the parser instance that, when set, causes the parser to decode entity and character references. By default, it would be unset. This would support backward compatibility and make it easier to get attribute value decoding. Another possibility would be to revert the new feature and add a separate method to perform the decoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=513840&group_id=5470 From noreply at sourceforge.net Thu Jun 22 14:20:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 05:20:11 -0700 Subject: [ python-Bugs-1510580 ] Setting category fails with -W switch Message-ID: Bugs item #1510580, was opened at 2006-06-22 08: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=1510580&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: A.M. Kuchling (akuchling) Assigned to: Brett Cannon (bcannon) Summary: Setting category fails with -W switch Initial Comment: This command reports an "invalid warning category" error, but it shouldn't. ./python -W'ignore:Not importing directory:ImportWarning' I think the change to new-style exceptions exposed this problem. warnings.py contains the following code to trigger this error: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise _OptionError("invalid warning category: %r" % (category,)) The new-style exceptions mean that the first isinstance() now returns False. I think there may be two fixes needed. First, I think it should be "isinstance(cat, types.ClassType) or isinstance(cat, type)". Second issue: hould the warnings.py code use "and" instead of "or"? Surely if issubclass(cat, Warning) is True, the category is certainly OK; no? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470 From noreply at sourceforge.net Thu Jun 22 15:50:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 06:50:14 -0700 Subject: [ python-Bugs-1510580 ] Setting category fails with -W switch Message-ID: Bugs item #1510580, was opened at 2006-06-22 08:20 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&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: A.M. Kuchling (akuchling) Assigned to: Brett Cannon (bcannon) Summary: Setting category fails with -W switch Initial Comment: This command reports an "invalid warning category" error, but it shouldn't. ./python -W'ignore:Not importing directory:ImportWarning' I think the change to new-style exceptions exposed this problem. warnings.py contains the following code to trigger this error: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise _OptionError("invalid warning category: %r" % (category,)) The new-style exceptions mean that the first isinstance() now returns False. I think there may be two fixes needed. First, I think it should be "isinstance(cat, types.ClassType) or isinstance(cat, type)". Second issue: hould the warnings.py code use "and" instead of "or"? Surely if issubclass(cat, Warning) is True, the category is certainly OK; no? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-22 09:50 Message: Logged In: YES user_id=11375 Once the problem is fixed, the attached patch adds some tests for warning parsing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:05:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:05:31 -0700 Subject: [ python-Bugs-1510580 ] Setting category fails with -W switch Message-ID: Bugs item #1510580, was opened at 2006-06-22 05:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&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: A.M. Kuchling (akuchling) Assigned to: Brett Cannon (bcannon) Summary: Setting category fails with -W switch Initial Comment: This command reports an "invalid warning category" error, but it shouldn't. ./python -W'ignore:Not importing directory:ImportWarning' I think the change to new-style exceptions exposed this problem. warnings.py contains the following code to trigger this error: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise _OptionError("invalid warning category: %r" % (category,)) The new-style exceptions mean that the first isinstance() now returns False. I think there may be two fixes needed. First, I think it should be "isinstance(cat, types.ClassType) or isinstance(cat, type)". Second issue: hould the warnings.py code use "and" instead of "or"? Surely if issubclass(cat, Warning) is True, the category is certainly OK; no? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-22 09:05 Message: Logged In: YES user_id=357491 Well, the docs for warnings (http://docs.python.org/dev/lib/warning-categories.html) say that a category must subclass Warning. So I removed the ClassType check entirely, and that causes test_exceptions to segfault. Lovely. I will try to look at this Friday. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-22 06:50 Message: Logged In: YES user_id=11375 Once the problem is fixed, the attached patch adds some tests for warning parsing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:13:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:13:10 -0700 Subject: [ python-Bugs-1510580 ] Setting category fails with -W switch Message-ID: Bugs item #1510580, was opened at 2006-06-22 05:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&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: A.M. Kuchling (akuchling) Assigned to: Brett Cannon (bcannon) Summary: Setting category fails with -W switch Initial Comment: This command reports an "invalid warning category" error, but it shouldn't. ./python -W'ignore:Not importing directory:ImportWarning' I think the change to new-style exceptions exposed this problem. warnings.py contains the following code to trigger this error: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise _OptionError("invalid warning category: %r" % (category,)) The new-style exceptions mean that the first isinstance() now returns False. I think there may be two fixes needed. First, I think it should be "isinstance(cat, types.ClassType) or isinstance(cat, type)". Second issue: hould the warnings.py code use "and" instead of "or"? Surely if issubclass(cat, Warning) is True, the category is certainly OK; no? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-22 09:13 Message: Logged In: YES user_id=357491 Turns out Armin's r47061 checkin fixed it; for some reason I had not rebuilt. Doing a distclean and re-running tests before committing the change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-22 09:05 Message: Logged In: YES user_id=357491 Well, the docs for warnings (http://docs.python.org/dev/lib/warning-categories.html) say that a category must subclass Warning. So I removed the ClassType check entirely, and that causes test_exceptions to segfault. Lovely. I will try to look at this Friday. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-22 06:50 Message: Logged In: YES user_id=11375 Once the problem is fixed, the attached patch adds some tests for warning parsing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:37:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:37:20 -0700 Subject: [ python-Bugs-1508253 ] logging fileConfig swallows handler exception Message-ID: Bugs item #1508253, was opened at 2006-06-18 19:33 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Works For Me Priority: 5 Submitted By: tdir (tdir) Assigned to: Vinay Sajip (vsajip) Summary: logging fileConfig swallows handler exception Initial Comment: If you specify a handler such as a RotatingFileHandler and the path you provide in the args specification ('option') is bad, config.fileConfig() catches the exception and 'swallows' it. The result is later on, when that handler is specified for a logger, you get an exception saying there is no such handler. A much friendlier behavior would be for fileConfig() to raise an exception so the real cause of the problem can be easily identified. Also, if there is a bug in the code itself, it would also get swallowed in similar fashion. In general, silently swallowing exceptions is rarely the best choice IMHO. Example ini with bad path (assuming /bad/path does not exist): [handler_defaultrotatingfile] class=handlers.RotatingFileHandler args=("/bad/path/logdir/my_log.log", 'w', 100000, 10) formatter=std ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:37 Message: Logged In: YES user_id=308438 Can you give some more details? I don't get the problem: see the transcript below. ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging.config >>> logging.config.fileConfig("junk.ini") Traceback (most recent call last): File "", line 1, in ? File "C:\Python\lib\logging\config.py", line 83, in fileConfig handlers = _install_handlers(cp, formatters) File "C:\Python\lib\logging\config.py", line 151, in _install_handlers h = apply(klass, args) File "C:\Python\lib\logging\handlers.py", line 109, in __init__ BaseRotatingHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\handlers.py", line 61, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\__init__.py", line 770, in __init__ stream = open(filename, mode) IOError: [Errno 2] No such file or directory: '/bad/path/junk.log' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:39:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:39:20 -0700 Subject: [ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers Message-ID: Bugs item #1470422, was opened at 2006-04-14 15:48 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&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: Closed >Resolution: Postponed Priority: 5 Submitted By: Michael Tsai (michaeltsai) Assigned to: Vinay Sajip (vsajip) Summary: Logging doesn't report the correct filename or line numbers Initial Comment: I have a logger that prints out %(filename)s:%(lineno)d along with the message. Instead of printing the file and line in my code where I call the logger, it prints out a location in logging/__init__.py. I was able to fix this, at least for my purposes, by changing logging.currentframe from sys._getframe to lambda:sys._getframe(3). ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:39 Message: Logged In: YES user_id=308438 Michael, I'll close this now, please feel free to re-open and reassign to me when you can reproduce the problem more predictably. ---------------------------------------------------------------------- Comment By: Michael Tsai (michaeltsai) Date: 2006-04-21 19:04 Message: Logged In: YES user_id=817528 I'm running on Mac OS X 10.4.6. Here's a simple script: """#!/usr/local/bin/python2.4 import logging logging.basicConfig(format=u"%(filename)s:%(lineno)d %(message)s") log = logging.getLogger("test") log.error(u"this is an error") """ Unfortunately, it doesn't reliably fail; most of the time it works. I haven't figured out how to trigger it. It does reliably fail when I use a frozen system created with "py2app -A" in which the Python libraries are symlinked in (rather than in a Zip). Then, logging._srcfile is "logging/__init__.py", but __file__ is something like "/ System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ logging/__init__.py" Maybe py2app shouldn't set sys.frozen in this case? Anyway, I don't think that's the real problem, because I've seen this happen when not using py2app (but, sorry, I'm not able to reliably duplicate it at this time). My patch isn't really the right fix, but I do think it works because, at least with the current logging module, currentframe() is always called with the same sequence of frames on the top of the stack. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-04-21 18:20 Message: Logged In: YES user_id=308438 Please can you provide a small script which demonstrates the problem? Which platform are you running on? Is there anything unusual about your setup (e.g. running from a frozen system)? I'm not sure your patch is the correct solution. The system looks up the call stack until a file is found which is not the source file of the logging module itself - that is presumed to be the caller. However, determining the source file of the logging module can come unstuck in scenarios such as py2exe-ified programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:46:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:46:12 -0700 Subject: [ python-Bugs-1501699 ] method format of logging.Formatter caches incorrectly Message-ID: Bugs item #1501699, was opened at 2006-06-06 15:14 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Boris Lorbeer (blorbeer) Assigned to: Vinay Sajip (vsajip) Summary: method format of logging.Formatter caches incorrectly Initial Comment: The format method of logging.Formatter is buggy in that it doesn't call the method formatException if the cache record.exc_text is set. If you have two Formatters that should format the same log record differently (i.e. each has its own overriding formatException method), the formatException method of the second formatter will never be called because the cache has been set by the first formatter. The proper way of using the cache is IMHO to check the cache only in the method formatException of logging.Formatter. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:46 Message: Logged In: YES user_id=308438 It's not a bug, it's by design. The formatException method only takes the exception info as a parameter, and to change the method signature now could break some people's code, right? A solution would be for you to also override the format method in your custom formatter classes and set record.exc_text to None if you want to invalidate the cache before calling the base class implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:49:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:49:50 -0700 Subject: [ python-Bugs-1510580 ] Setting category fails with -W switch Message-ID: Bugs item #1510580, was opened at 2006-06-22 05:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&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: A.M. Kuchling (akuchling) Assigned to: Brett Cannon (bcannon) Summary: Setting category fails with -W switch Initial Comment: This command reports an "invalid warning category" error, but it shouldn't. ./python -W'ignore:Not importing directory:ImportWarning' I think the change to new-style exceptions exposed this problem. warnings.py contains the following code to trigger this error: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise _OptionError("invalid warning category: %r" % (category,)) The new-style exceptions mean that the first isinstance() now returns False. I think there may be two fixes needed. First, I think it should be "isinstance(cat, types.ClassType) or isinstance(cat, type)". Second issue: hould the warnings.py code use "and" instead of "or"? Surely if issubclass(cat, Warning) is True, the category is certainly OK; no? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-22 09:49 Message: Logged In: YES user_id=357491 r47072 has just the check for the subclass of Warning and added your tests. Thanks, Andrew. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-22 09:13 Message: Logged In: YES user_id=357491 Turns out Armin's r47061 checkin fixed it; for some reason I had not rebuilt. Doing a distclean and re-running tests before committing the change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-22 09:05 Message: Logged In: YES user_id=357491 Well, the docs for warnings (http://docs.python.org/dev/lib/warning-categories.html) say that a category must subclass Warning. So I removed the ClassType check entirely, and that causes test_exceptions to segfault. Lovely. I will try to look at this Friday. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-22 06:50 Message: Logged In: YES user_id=11375 Once the problem is fixed, the attached patch adds some tests for warning parsing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470 From noreply at sourceforge.net Thu Jun 22 20:17:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 11:17:35 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-05 11:14 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2006-06-22 14:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 19:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-02 17:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-02 16:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-04-05 11:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Thu Jun 22 20:36:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 11:36:34 -0700 Subject: [ python-Feature Requests-1510853 ] Add Windows 9x/ME (lack of) support information to README.TX Message-ID: Feature Requests item #1510853, was opened at 2006-06-22 15:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&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: ajaksu (ajaksu2) Assigned to: Nobody/Anonymous (nobody) Summary: Add Windows 9x/ME (lack of) support information to README.TX Initial Comment: I suggest that following informative note should be added as a new sub-section in README.TXT's "Unsupported systems" (which really needs mentioning MacOS 9). The sub-section idea regards README.TXT only talking about already unsupported platforms. Motivation: As one of the few Windows 98 users that program in Python AND installed the 2.5 beta1, I was greeted by Tools/msi/msi.py's warning message. However, no further information was available in the downloaded release or in the online beta documents (What's New, release notes, etc.). Best regards, Daniel Diniz ----- Warning on install in Windows 98 and Windows Me Following Microsoft's closing of Extended Support for Windows 98/ME (July 11, 2006), Python 2.6 will stop supporting these platforms. Python development and maintainability becomes easier (and more reliable) when platform specific code targeting OSes with few users and no dedicated expert developers is taken out. The vendor also warns that the OS versions listed above "can expose customers to security risks" and recommends upgrade. For a more detailed discussion regarding no-longer-supported and resupporting platforms, as well as a list of platforms that became or will be unsupported, see PEP 11. Current behavior The Python 2.5 installer presents a warning message on those systems: "Warning: Python 2.5.x is the last Python release for Windows 9x." Suggested readings PEP 11: Removing support for little used platforms (http://www.python.org/dev/peps/pep-0011) End of support for Windows 98, Windows Me, and Windows XP Service Pack 1 (http://www.microsoft.com/windows/support/endofsupport.mspx) Copyright This document has been placed in the public domain. ------ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470 From noreply at sourceforge.net Thu Jun 22 20:59:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 11:59:52 -0700 Subject: [ python-Feature Requests-1510853 ] Add Windows 9x/ME (lack of) support information to README.TX Message-ID: Feature Requests item #1510853, was opened at 2006-06-22 18:36 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&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: ajaksu (ajaksu2) >Assigned to: A.M. Kuchling (akuchling) Summary: Add Windows 9x/ME (lack of) support information to README.TX Initial Comment: I suggest that following informative note should be added as a new sub-section in README.TXT's "Unsupported systems" (which really needs mentioning MacOS 9). The sub-section idea regards README.TXT only talking about already unsupported platforms. Motivation: As one of the few Windows 98 users that program in Python AND installed the 2.5 beta1, I was greeted by Tools/msi/msi.py's warning message. However, no further information was available in the downloaded release or in the online beta documents (What's New, release notes, etc.). Best regards, Daniel Diniz ----- Warning on install in Windows 98 and Windows Me Following Microsoft's closing of Extended Support for Windows 98/ME (July 11, 2006), Python 2.6 will stop supporting these platforms. Python development and maintainability becomes easier (and more reliable) when platform specific code targeting OSes with few users and no dedicated expert developers is taken out. The vendor also warns that the OS versions listed above "can expose customers to security risks" and recommends upgrade. For a more detailed discussion regarding no-longer-supported and resupporting platforms, as well as a list of platforms that became or will be unsupported, see PEP 11. Current behavior The Python 2.5 installer presents a warning message on those systems: "Warning: Python 2.5.x is the last Python release for Windows 9x." Suggested readings PEP 11: Removing support for little used platforms (http://www.python.org/dev/peps/pep-0011) End of support for Windows 98, Windows Me, and Windows XP Service Pack 1 (http://www.microsoft.com/windows/support/endofsupport.mspx) Copyright This document has been placed in the public domain. ------ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 18:59 Message: Logged In: YES user_id=849994 Andrew? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470 From noreply at sourceforge.net Thu Jun 22 21:02:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 12:02:54 -0700 Subject: [ python-Bugs-1508253 ] logging fileConfig swallows handler exception Message-ID: Bugs item #1508253, was opened at 2006-06-18 19:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Pending Resolution: Works For Me Priority: 5 Submitted By: tdir (tdir) Assigned to: Vinay Sajip (vsajip) Summary: logging fileConfig swallows handler exception Initial Comment: If you specify a handler such as a RotatingFileHandler and the path you provide in the args specification ('option') is bad, config.fileConfig() catches the exception and 'swallows' it. The result is later on, when that handler is specified for a logger, you get an exception saying there is no such handler. A much friendlier behavior would be for fileConfig() to raise an exception so the real cause of the problem can be easily identified. Also, if there is a bug in the code itself, it would also get swallowed in similar fashion. In general, silently swallowing exceptions is rarely the best choice IMHO. Example ini with bad path (assuming /bad/path does not exist): [handler_defaultrotatingfile] class=handlers.RotatingFileHandler args=("/bad/path/logdir/my_log.log", 'w', 100000, 10) formatter=std ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:37 Message: Logged In: YES user_id=308438 Can you give some more details? I don't get the problem: see the transcript below. ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging.config >>> logging.config.fileConfig("junk.ini") Traceback (most recent call last): File "", line 1, in ? File "C:\Python\lib\logging\config.py", line 83, in fileConfig handlers = _install_handlers(cp, formatters) File "C:\Python\lib\logging\config.py", line 151, in _install_handlers h = apply(klass, args) File "C:\Python\lib\logging\handlers.py", line 109, in __init__ BaseRotatingHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\handlers.py", line 61, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\__init__.py", line 770, in __init__ stream = open(filename, mode) IOError: [Errno 2] No such file or directory: '/bad/path/junk.log' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470 From noreply at sourceforge.net Thu Jun 22 21:08:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 12:08:42 -0700 Subject: [ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon Message-ID: Bugs item #1507224, was opened at 2006-06-16 11:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&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: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Martin v. L??wis (loewis) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 19:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 From noreply at sourceforge.net Thu Jun 22 22:32:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 13:32:42 -0700 Subject: [ python-Bugs-1506758 ] If MAXFD too high, popen2/subprocess produce MemoryErrors Message-ID: Bugs item #1506758, was opened at 2006-06-15 18:06 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter Vetere (pav3901) >Assigned to: Peter ? strand (astrand) Summary: If MAXFD too high, popen2/subprocess produce MemoryErrors Initial Comment: Both the subprocess and the popen2 modules use the range(...) function to iterate over and close inherited file descriptors when a subprocess is spawned. In the OS environment, it possible (using ulimit -n) to set SC_OPEN_MAX (and thus MAXFD in these modules) to a very high value. This can exhaust the limitations of the range() function, producing a MemoryError. The better thing to do would be to use xrange() instead. In particular, this bug occurs in subprocess._close_fds() and popen2._run_child(). ---------------------------------------------------------------------- >Comment By: Peter ? strand (astrand) Date: 2006-06-22 22:32 Message: Logged In: YES user_id=344921 Patch 1506760 has been applied. ---------------------------------------------------------------------- Comment By: Peter Vetere (pav3901) Date: 2006-06-15 21:31 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 ---------------------------------------------------------------------- Comment By: Peter Vetere (pav3901) Date: 2006-06-15 18:15 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&group_id=5470 From noreply at sourceforge.net Fri Jun 23 00:53:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 15:53:11 -0700 Subject: [ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure Message-ID: Bugs item #1510984, was opened at 2006-06-22 18: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=1510984&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: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 From noreply at sourceforge.net Fri Jun 23 01:18:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 16:18:20 -0700 Subject: [ python-Bugs-1508253 ] logging fileConfig swallows handler exception Message-ID: Bugs item #1508253, was opened at 2006-06-18 14:33 Message generated for change (Comment added) made by tdir You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Works For Me Priority: 5 Submitted By: tdir (tdir) Assigned to: Vinay Sajip (vsajip) Summary: logging fileConfig swallows handler exception Initial Comment: If you specify a handler such as a RotatingFileHandler and the path you provide in the args specification ('option') is bad, config.fileConfig() catches the exception and 'swallows' it. The result is later on, when that handler is specified for a logger, you get an exception saying there is no such handler. A much friendlier behavior would be for fileConfig() to raise an exception so the real cause of the problem can be easily identified. Also, if there is a bug in the code itself, it would also get swallowed in similar fashion. In general, silently swallowing exceptions is rarely the best choice IMHO. Example ini with bad path (assuming /bad/path does not exist): [handler_defaultrotatingfile] class=handlers.RotatingFileHandler args=("/bad/path/logdir/my_log.log", 'w', 100000, 10) formatter=std ---------------------------------------------------------------------- >Comment By: tdir (tdir) Date: 2006-06-22 18:18 Message: Logged In: YES user_id=1541624 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 ABOVE IS THE PYTHON SIGNON I HAVE ALSO ATTACHED THE config.py FROM THE INSTALL. IT CONTAINS NO _install_handlers APPEARS TO BE A VERY DIFFERENT VERSION FROM YOURS ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 11:37 Message: Logged In: YES user_id=308438 Can you give some more details? I don't get the problem: see the transcript below. ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging.config >>> logging.config.fileConfig("junk.ini") Traceback (most recent call last): File "", line 1, in ? File "C:\Python\lib\logging\config.py", line 83, in fileConfig handlers = _install_handlers(cp, formatters) File "C:\Python\lib\logging\config.py", line 151, in _install_handlers h = apply(klass, args) File "C:\Python\lib\logging\handlers.py", line 109, in __init__ BaseRotatingHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\handlers.py", line 61, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\__init__.py", line 770, in __init__ stream = open(filename, mode) IOError: [Errno 2] No such file or directory: '/bad/path/junk.log' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470 From noreply at sourceforge.net Fri Jun 23 02:27:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 17:27:54 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-06 01:14 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-23 10:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-06-23 04:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-21 09:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-03 07:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-03 06:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-04-06 01:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Fri Jun 23 03:31:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 18:31:10 -0700 Subject: [ python-Bugs-1503789 ] Cannot write source code in UTF16 Message-ID: Bugs item #1503789, was opened at 2006-06-09 17:38 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: ---------------------------------------------- # -*- coding: UTF-16LE -*- print "Hello world" ---------------------------------------------- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. ---------------------------------------------------------------------- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-22 18:31 Message: Logged In: YES user_id=561546 Turns out the code is already written but disabled. Simply turning it on would work. tokenizer.c(321): #if 0 /* Disable support for UTF-16 BOMs until a decision is made whether this needs to be supported. */ } else if (ch == 0xFE) { ch = get_char(tok); if (ch != 0xFF) goto NON_ BOM; if (!set_readline(tok, "utf-16-be")) return 0; tok->decoding_state = -1; } else if (ch == 0xFF) { ch = get_char(tok); if (ch != 0xFE) goto NON_ BOM; if (!set_readline(tok, "utf-16-le")) return 0; tok->decoding_state = -1; #endif Executing an utf-16 text file with BOM file would work. However if I also include an encoding declaration plus BOM like this # -*- coding: UTF-16le -*- It would result in this error, for some logic in the code that I couldn't sort out {tokenizer.c(291)}: g:\bin\py_repos\python-svn\PCbuild>python_d.exe test16le. py File "test16le.py", line 1 SyntaxError: encoding problem: utf-8 If you need a justification for checking the UTF-16 BOM, it is Microsoft. As an early adopter of unicode before UTF-8 is popularized, there is some software that generates UTF- 16 by default. Not a fatal issue. But I see no reason not to support it either. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-13 10:06 Message: Logged In: YES user_id=21627 The parser code is in the Parser subdirectory. It would be good if you could follow the existing parsing strategy, i.e. convert the input to UTF-8, and then proceed with the normal parsing procedure. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-13 09:27 Message: Logged In: YES user_id=561546 That sounds good. It is probably a good time to try out the instructions to build Python on Windows. http://groups.google.com/group/comp.lang.python/browse_ thread/thread/f09c49f77bf0a578/3e076bfcafb064cd?hl=en#3e076 bfcafb064cd Can you point me to the relevant source code? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-10 05:27 Message: Logged In: YES user_id=21627 Would you like to work on a patch? There is, of course, a fairly obvious reason that this doesn't work: nobody has put effort into making it work. Personally, I suggest that you use some other encoding for source code, e.g. UTF-8. ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-09 17:39 Message: Logged In: YES user_id=561546 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 From noreply at sourceforge.net Fri Jun 23 05:13:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 20:13:21 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-05 11:14 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: Rejected Priority: 9 Submitted By: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2006-06-22 23:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 20:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-06-22 14:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 19:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-02 17:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-02 16:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-04-05 11:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Fri Jun 23 05:34:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 20:34:35 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-06 01:14 Message generated for change (Settings changed) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: Python 2.5 >Status: Open Resolution: Rejected >Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Skip Montanaro (montanaro) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-23 13:34 Message: Logged In: YES user_id=698599 Yep, your point about adding a comment to the documentation is fair. Skip, do you want to take my words and massage them into a form suitable for the docs? ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-06-23 13:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-23 10:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-06-23 04:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-21 09:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-03 07:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-03 06:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-04-06 01:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Fri Jun 23 08:10:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 23:10:29 -0700 Subject: [ python-Bugs-1508253 ] logging fileConfig swallows handler exception Message-ID: Bugs item #1508253, was opened at 2006-06-18 19:33 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Closed >Resolution: Fixed Priority: 5 Submitted By: tdir (tdir) Assigned to: Vinay Sajip (vsajip) Summary: logging fileConfig swallows handler exception Initial Comment: If you specify a handler such as a RotatingFileHandler and the path you provide in the args specification ('option') is bad, config.fileConfig() catches the exception and 'swallows' it. The result is later on, when that handler is specified for a logger, you get an exception saying there is no such handler. A much friendlier behavior would be for fileConfig() to raise an exception so the real cause of the problem can be easily identified. Also, if there is a bug in the code itself, it would also get swallowed in similar fashion. In general, silently swallowing exceptions is rarely the best choice IMHO. Example ini with bad path (assuming /bad/path does not exist): [handler_defaultrotatingfile] class=handlers.RotatingFileHandler args=("/bad/path/logdir/my_log.log", 'w', 100000, 10) formatter=std ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-06-23 06:10 Message: Logged In: YES user_id=308438 Ok, then the bug has already been fixed (or superseded by changes to the code). I'll close this report: if you want to use the latest code, just download it from the Python subversion repository. It should run without problems in 2.4.2. ---------------------------------------------------------------------- Comment By: tdir (tdir) Date: 2006-06-22 23:18 Message: Logged In: YES user_id=1541624 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 ABOVE IS THE PYTHON SIGNON I HAVE ALSO ATTACHED THE config.py FROM THE INSTALL. IT CONTAINS NO _install_handlers APPEARS TO BE A VERY DIFFERENT VERSION FROM YOURS ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:37 Message: Logged In: YES user_id=308438 Can you give some more details? I don't get the problem: see the transcript below. ActivePython 2.4 Build 243 (ActiveState Corp.) based on Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging.config >>> logging.config.fileConfig("junk.ini") Traceback (most recent call last): File "", line 1, in ? File "C:\Python\lib\logging\config.py", line 83, in fileConfig handlers = _install_handlers(cp, formatters) File "C:\Python\lib\logging\config.py", line 151, in _install_handlers h = apply(klass, args) File "C:\Python\lib\logging\handlers.py", line 109, in __init__ BaseRotatingHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\handlers.py", line 61, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding) File "C:\Python\lib\logging\__init__.py", line 770, in __init__ stream = open(filename, mode) IOError: [Errno 2] No such file or directory: '/bad/path/junk.log' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470 From noreply at sourceforge.net Fri Jun 23 08:13:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 23:13:15 -0700 Subject: [ python-Bugs-853506 ] IP6 address parsing i sgmllib Message-ID: Bugs item #853506, was opened at 2003-12-03 14:15 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853506&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: IP6 address parsing i sgmllib Initial Comment: The sgmllib.attrfind regex excludes [ and ]. http://www.ietf.org/rfc/rfc2732.txt uses these in the host portion to indicate that an address is IP6 rather than IP4. http://[1080::8:800:200C:417A]/foo RFC 2732 is referenced as normative by the xml:base module. I grouped the issue as 2.3, on the assumption that it isn't a bug until IP6 is used. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-23 02:13 Message: Logged In: YES user_id=3066 Fixed on the trunk (2.5b2) in revision 47080; on the release24-maint branch (2.4.4) in revision 47081. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-02-20 18:46 Message: Logged In: YES user_id=764593 Assigned to 2.3 when that was development. Moved to 2.4 now, still on the assumption that the bug won't hit with real data until IP6 is more common. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853506&group_id=5470 From noreply at sourceforge.net Fri Jun 23 08:16:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 23:16:10 -0700 Subject: [ python-Bugs-745002 ] <> in attrs in sgmllib not handled Message-ID: Bugs item #745002, was opened at 2003-05-28 12:30 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&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: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: <> in attrs in sgmllib not handled Initial Comment: Hi folks - This bug is noted in the source code for sgmllib.py, and it finally bit me. If you feed the SGMLParser class text such as <tag attr = "<attrtag> bar </attrtag>">foo</tag> the <attrtag> will be processed as a tag, as well as being recognized as part of the attribute. This is because of the way the end index for the opening tag is computed. As far as I can tell from the HTML 4.01 specification, this is legal. The case I encountered was in a value of an "onmouseover" attribute, which was a Javascript call which contained HTML text as one of its arguments. The problem is in SGMLParser.parse_starttag, which attempts to compute the end of the opening tag with a simple regexp [<>], and uses this index even when the attributes have passed it. There's no real need to check this regexp in advance, as far as I can tell. I've attached my proposed modification of SGMLParser.parse_starttag; I've tested this change in 2.2.1, but there are no relevant differences between 2.2.1 and the head of the CVS tree for this method. No guarantees of correctness, but it works on the examples I've tested it on. Cheers - Sam Bayer ================================ w_endbracket = re.compile("\s*[<>]") class SGMLParser: # Internal -- handle starttag, return length or -1 if not terminated def parse_starttag(self, i): self.__starttag_text = None start_pos = i rawdata = self.rawdata if shorttagopen.match(rawdata, i): # SGML shorthand: <tag/data/ == <tag>data</tag> # XXX Can data contain &... (entity or char refs)? # XXX Can data contain < or > (tag characters)? # XXX Can there be whitespace before the first /? match = shorttag.match(rawdata, i) if not match: return -1 tag, data = match.group(1, 2) self.__starttag_text = '<%s/' % tag tag = tag.lower() k = match.end(0) self.finish_shorttag(tag, data) self.__starttag_text = rawdata[start_pos:match.end(1) + 1] return k # Now parse the data between i+1 and the end of the tag into a tag and attrs attrs = [] if rawdata[i:i+2] == '<>': # SGML shorthand: <> == <last open tag seen> k = i + 1 tag = self.lasttag else: match = tagfind.match(rawdata, i+1) if not match: self.error('unexpected call to parse_starttag') k = match.end(0) tag = rawdata[i+1:k].lower() self.lasttag = tag while w_endbracket.match(rawdata, k) is None: match = attrfind.match(rawdata, k) if not match: break attrname, rest, attrvalue = match.group(1, 2, 3) if not rest: attrvalue = attrname elif attrvalue[:1] == '\'' == attrvalue[-1:] or \ attrvalue[:1] == '"' == attrvalue[-1:]: attrvalue = attrvalue[1:-1] attrs.append((attrname.lower(), attrvalue)) k = match.end(0) match = endbracket.search(rawdata, k) if not match: return -1 j = match.start(0) if rawdata[j] == '>': j = j+1 self.__starttag_text = rawdata[start_pos:j] self.finish_starttag(tag, attrs) return j ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-23 02:16 Message: Logged In: YES user_id=3066 See also: http://www.python.org/sf/803422 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-06-14 11:23 Message: Logged In: YES user_id=21627 I see. Can you please attach the fix as a context or unified diff to this report? I can't follow your changes above at all. ---------------------------------------------------------------------- Comment By: Samuel Bayer (sambayer) Date: 2003-06-14 09:35 Message: Logged In: YES user_id=40146 I'm reporting it because (a) it's not in the bug queue, and (b) it's broken The fact that it's noted as a bug in the source code doesn't strike me as relevant. Especially since I attached a fix. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-06-14 03:58 Message: Logged In: YES user_id=21627 If this is a known bug, why are you reporting it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&group_id=5470 From noreply at sourceforge.net Fri Jun 23 11:44:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 02:44:53 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 16:03 Message generated for change (Comment added) made by tobixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&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: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Martin v. L??wis (loewis) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- Comment By: Steffen Tobias Oschatz (tobixx) Date: 2006-06-23 11:44 Message: Logged In: YES user_id=694396 I can confirm this behavior for Red Hat Enterprise 3. I installed Python 2.4.3 . The tests failed for pyexpat (complaining that there is no expat.so) and minidom. I installed PyXML-0.8.4 - that solves expat error, minidom error was still there. Tests for PyXML all run fine. I have looked into the test and find the following reason: testAltNewline: --------------- str= '\n\n' dom.toprettyxml(newl="\r\n") >>> u'\n\r\n' str.replace("\n", "\r\n") >>> '\r\n\r\n' domstr == str.replace("\n", "\r\n") >>> False I assume the test should be: domstr == str.replace("\r\n"), "\n") to pass it. But by the way: why is there an '\n' in the pretty string? And i would suggest: unicode(str). testWriteXML: ------------ str= '' domstr=dom.toxml() >>> u'\n' str == domstr >>> False Whoops, where does the '\n' coming from ? : toxml toprettyxml writexml: if encoding is None: writer.write('\n') I'm not a xml guy, but i ask myself: should such formating really be in this place ? testEncodings: -------------- same as before testPyth1094164: ---------------- I can confirm this behavior for Red Hat Enterprise 3. I installed Python 2.4.3 . The tests failed for pyexpat (complaining that there is no expat.so) and minidom. I installed PyXML-0.8.4 - that solves expat error, minidom error was still there. Tests for PyXML all run fine. I have looked into the test and find the following reason: testAltNewline: --------------- str= '\n\n' dom.toprettyxml(newl="\r\n") >>> u'\n\r\n' str.replace("\n", "\r\n") >>> '\r\n\r\n' domstr == str.replace("\n", "\r\n") >>> False I assume the test should be: domstr == str.replace("\r\n"), "\n") to pass it. But by the way: why is there an '\n' in the pretty string? And i would suggest: unicode(str). testWriteXML: ------------ str= '' domstr=dom.toxml() >>> u'\n' str == domstr >>> False Whoops, where does the '\n' coming from ? : toxml toprettyxml writexml: if encoding is None: writer.write('\n') I'm not a xml guy, but i ask myself: should such formating really be in this place ? testEncodings: -------------- same as before testPyth1094164: ---------------- after elem.replaceChild(e, e) the dom is gone: --------> type(elem.firstChild) Out[129]: --------> type(e.parentNode) Out[130]: And why ? replaceChild: if newChild.parentNode is not None: newChild.parentNode.removeChild(newChild) if newChild is oldChild: return I assume the order of this if statement should be reversed. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 09:01 Message: Logged In: YES user_id=21627 It's no surprise that the error didn't occur in 2.5a1: the PyXML-0.8.4 installation on rptownsend's machine was for 2.4; the 2.5 sandbox won't see 2.4's xmlplus. Even if PyXML was installed on 2.5, the test suite would still refer to xmlcore, thus bypassing PyXML. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-07 12:07 Message: Logged In: YES user_id=200117 I added a few print statements to the tests - see attached file py_243.txt for the results while running on Python- 2.4.3 ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 14:31 Message: Logged In: YES user_id=200117 Interestingly, the error doesn't occur with Python-2.5a1 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 08:27 Message: Logged In: YES user_id=33168 Martin maintains PyXML AFAIK. Maybe he has some ideas. I suspect this might be even worse in 2.5. Element Tree was added and there was a name change. Some of those things still need to be addressed. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-03 15:37 Message: Logged In: YES user_id=200117 Hi Neal, I've just built 2.4.3 on a Red Hat Enterpeise Edition WS V4.2 machine and this gives the same error. I've had this vague feeling that I've seen something like this before, but couldn't find anything when I searched the tracker... I've now realised that the error is due to a conflict with PyXML-0.8.4 which was already installed on both machines. If I rename the ../site_packages/_xmlplus directory to a different name then the error goes away (on the Red Hat machine at least, the SUSE machine is at home). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 07:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 16:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Fri Jun 23 15:52:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 06:52:30 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-21 21:35 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-06-23 15:52 Message: Logged In: YES user_id=34209 See the discussion started at: http://mail.python.org/pipermail/python-dev/2006-June/066161.html It's not a bug in 328 or 338 (the PEP that adds the -m switch for packages), but in the interaction between the two. I don't think this will be fixed for 2.5, since there is no obvious fix. If it hurts when you press there, don't press there. Either don't use -m for packaged modules, or have the packaged module only use absolute imports. (But don't be surprised if the script-module is imported twice, once as __main__ and once as the module itself. That's a whole other bug/feature.) ---------------------------------------------------------------------- Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-22 01:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-22 00:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 23:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Fri Jun 23 16:01:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 07:01:34 -0700 Subject: [ python-Bugs-1501699 ] method format of logging.Formatter caches incorrectly Message-ID: Bugs item #1501699, was opened at 2006-06-06 17:14 Message generated for change (Comment added) made by blorbeer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&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: None >Status: Open Resolution: Invalid Priority: 5 Submitted By: Boris Lorbeer (blorbeer) Assigned to: Vinay Sajip (vsajip) Summary: method format of logging.Formatter caches incorrectly Initial Comment: The format method of logging.Formatter is buggy in that it doesn't call the method formatException if the cache record.exc_text is set. If you have two Formatters that should format the same log record differently (i.e. each has its own overriding formatException method), the formatException method of the second formatter will never be called because the cache has been set by the first formatter. The proper way of using the cache is IMHO to check the cache only in the method formatException of logging.Formatter. ---------------------------------------------------------------------- >Comment By: Boris Lorbeer (blorbeer) Date: 2006-06-23 16:01 Message: Logged In: YES user_id=1535177 Hi vsajip, yes, it is by design, but I don't know whether the design is ideal. But if this behaviour is really intended, it should be documented clearly, such as: formatException(exc_info): If you override this method, an exception in the log record will be formatted by using this method, but only if this log record wasn't given by the framework to another formatter (that uses the default format function) before your formatter got its turn (something you cannot ensure)... Now to the question of how to fix the design (provided one wants to): clearly one cannot change the signature of formatException without breaking existing code. But one could change formatter to have an additional field 'labeledCache': a pair of an exc_info tuple and a string (the cache). The formatException method would then use this cache only if id() of its argument is the id() of the first element in the pair, otherwise it would exchange 'labeledCache' by a new pair belonging to the current exc_info tuple. That's only one posibility to fix this problem. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 18:46 Message: Logged In: YES user_id=308438 It's not a bug, it's by design. The formatException method only takes the exception info as a parameter, and to change the method signature now could break some people's code, right? A solution would be for you to also override the format method in your custom formatter classes and set record.exc_text to None if you want to invalidate the cache before calling the base class implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 From noreply at sourceforge.net Fri Jun 23 16:56:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 07:56:15 -0700 Subject: [ python-Bugs-1501699 ] method format of logging.Formatter caches incorrectly Message-ID: Bugs item #1501699, was opened at 2006-06-06 15:14 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&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: None >Status: Pending Resolution: Invalid Priority: 5 Submitted By: Boris Lorbeer (blorbeer) Assigned to: Vinay Sajip (vsajip) Summary: method format of logging.Formatter caches incorrectly Initial Comment: The format method of logging.Formatter is buggy in that it doesn't call the method formatException if the cache record.exc_text is set. If you have two Formatters that should format the same log record differently (i.e. each has its own overriding formatException method), the formatException method of the second formatter will never be called because the cache has been set by the first formatter. The proper way of using the cache is IMHO to check the cache only in the method formatException of logging.Formatter. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-06-23 14:56 Message: Logged In: YES user_id=308438 Hi Boris, You didn't say in your comment what was wrong with my suggestion (setting record.exc_text to None in your formatter subclass). I take your point, and understand your labeledCache suggestion, and will look at implementing something equivalent when time permits. However, other scenarios need to be considered, such as sending LogRecords over the wire. In this scenario (not uncommon in multi-process environments), the present implementation could send the formatted stack trace, as it is pickled in the LogRecord; implementing a cache in the Formatter will not allow the stack trace to be sent to be logged elsewhwere. ---------------------------------------------------------------------- Comment By: Boris Lorbeer (blorbeer) Date: 2006-06-23 14:01 Message: Logged In: YES user_id=1535177 Hi vsajip, yes, it is by design, but I don't know whether the design is ideal. But if this behaviour is really intended, it should be documented clearly, such as: formatException(exc_info): If you override this method, an exception in the log record will be formatted by using this method, but only if this log record wasn't given by the framework to another formatter (that uses the default format function) before your formatter got its turn (something you cannot ensure)... Now to the question of how to fix the design (provided one wants to): clearly one cannot change the signature of formatException without breaking existing code. But one could change formatter to have an additional field 'labeledCache': a pair of an exc_info tuple and a string (the cache). The formatException method would then use this cache only if id() of its argument is the id() of the first element in the pair, otherwise it would exchange 'labeledCache' by a new pair belonging to the current exc_info tuple. That's only one posibility to fix this problem. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:46 Message: Logged In: YES user_id=308438 It's not a bug, it's by design. The formatException method only takes the exception info as a parameter, and to change the method signature now could break some people's code, right? A solution would be for you to also override the format method in your custom formatter classes and set record.exc_text to None if you want to invalidate the cache before calling the base class implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 From noreply at sourceforge.net Fri Jun 23 17:00:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 08:00:23 -0700 Subject: [ python-Bugs-1511381 ] codec_getstreamcodec passes extra None Message-ID: Bugs item #1511381, was opened at 2006-06-24 00:00 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=1511381&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Hye-Shik Chang (perky) Assigned to: Walter D?rwald (doerwalter) Summary: codec_getstreamcodec passes extra None Initial Comment: codec_getstreamcodec passes a None object (null pointer, originally) as a "error" argument when errors is given as a null pointer. Due to this behavior, parsers can't utilize cjkcodecs which doesn't allow None as a default argument: SyntaxError: encoding problem: with BOM Attached patch fixes it to omit the argument, "errors", and changed it to use PyObject_CallFunction instead of PyEval_CallFunction because PyEval_CallFunction doesn't work for simple "O" argument. (I don't know it was intended. But we can still use PyEval_CallFunction if we write it as "(O)") I wonder if there's a reason that you chose PyEval_CallFunction for the initialization order or something? How to reproduce the error: echo "# coding: cp949" > test.py ./python test.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&group_id=5470 From noreply at sourceforge.net Fri Jun 23 17:47:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 08:47:12 -0700 Subject: [ python-Bugs-1511381 ] codec_getstreamcodec passes extra None Message-ID: Bugs item #1511381, was opened at 2006-06-23 17:00 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Hye-Shik Chang (perky) Assigned to: Walter D?rwald (doerwalter) Summary: codec_getstreamcodec passes extra None Initial Comment: codec_getstreamcodec passes a None object (null pointer, originally) as a "error" argument when errors is given as a null pointer. Due to this behavior, parsers can't utilize cjkcodecs which doesn't allow None as a default argument: SyntaxError: encoding problem: with BOM Attached patch fixes it to omit the argument, "errors", and changed it to use PyObject_CallFunction instead of PyEval_CallFunction because PyEval_CallFunction doesn't work for simple "O" argument. (I don't know it was intended. But we can still use PyEval_CallFunction if we write it as "(O)") I wonder if there's a reason that you chose PyEval_CallFunction for the initialization order or something? How to reproduce the error: echo "# coding: cp949" > test.py ./python test.py ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-23 17:47 Message: Logged In: YES user_id=89016 The patch looks good to me. Switching from PyEval_CallFunction() to PyObject_CallFunction() should be OK. (There seems to be subtle differences between the two, but finding out what it is looks like a scavenger hunt to me :-/)). So go ahead and check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&group_id=5470 From noreply at sourceforge.net Fri Jun 23 17:47:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 08:47:34 -0700 Subject: [ python-Bugs-1511381 ] codec_getstreamcodec passes extra None Message-ID: Bugs item #1511381, was opened at 2006-06-23 17:00 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&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: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: codec_getstreamcodec passes extra None Initial Comment: codec_getstreamcodec passes a None object (null pointer, originally) as a "error" argument when errors is given as a null pointer. Due to this behavior, parsers can't utilize cjkcodecs which doesn't allow None as a default argument: SyntaxError: encoding problem: with BOM Attached patch fixes it to omit the argument, "errors", and changed it to use PyObject_CallFunction instead of PyEval_CallFunction because PyEval_CallFunction doesn't work for simple "O" argument. (I don't know it was intended. But we can still use PyEval_CallFunction if we write it as "(O)") I wonder if there's a reason that you chose PyEval_CallFunction for the initialization order or something? How to reproduce the error: echo "# coding: cp949" > test.py ./python test.py ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-23 17:47 Message: Logged In: YES user_id=89016 The patch looks good to me. Switching from PyEval_CallFunction() to PyObject_CallFunction() should be OK. (There seems to be subtle differences between the two, but finding out what it is looks like a scavenger hunt to me :-/)). So go ahead and check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&group_id=5470 From noreply at sourceforge.net Fri Jun 23 20:14:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 11:14:06 -0700 Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing Message-ID: Bugs item #1511497, was opened at 2006-06-23 20:14 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=1511497&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' >>> So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 From noreply at sourceforge.net Fri Jun 23 20:24:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 11:24:46 -0700 Subject: [ python-Feature Requests-1509060 ] Interrupt/kill threads w/exception Message-ID: Feature Requests item #1509060, was opened at 2006-06-19 21:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509060&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Bock (oliverbock) Assigned to: Nobody/Anonymous (nobody) Summary: Interrupt/kill threads w/exception Initial Comment: When unsophisticated (but not evil) users write Python macros, they occasionally write infinite loops. It would be nice if it was possible to interrupt threads to break these loops. The safety of rasing an exception in another thread was noted in http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452266&group_id=5470 Anton Wilson wrote a patch for this some time ago: http://mail.python.org/pipermail/python-list/2003-February/148999.html Note that this won't help if the thread is blocked on I/O. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-06-23 11:24 Message: Logged In: YES user_id=341410 It would be nice to be able to kill runaway threads, though I have no comment on the patch that Anton Wilson offers (which will no doubt need to be updated for more recent Pythons). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1509060&group_id=5470 From noreply at sourceforge.net Fri Jun 23 21:17:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 12:17:26 -0700 Subject: [ python-Bugs-1194222 ] parsedate and Y2K Message-ID: Bugs item #1194222, was opened at 2005-05-02 21:37 Message generated for change (Comment added) made by mnot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Nottingham (mnot) Assigned to: Nobody/Anonymous (nobody) Summary: parsedate and Y2K Initial Comment: rfc822.parsedate and email.Utils.parsedate don't take Y2K into account when parsing two-digit years, even though they're allowed by RFC822. Even though that spec has since been superseded, there are still systems generating dates in the old format, and RFC2616, which bases its dates on RFC822, still allows two-digit years. For example, >>> email.Utils.parsedate("Sun, 6 Nov 94 08:49:37 GMT") (94, 11, 6, 8, 49, 37, 0, 0, 0) Here's a trivial patch to behave as outlined in the time module (I don't test for time.accept2dyear because the input is outside the system's control, and RFC-specified); it's against 2.3, but should be easy to integrate into later versions. 125a126,130 > if yy < 100: > if yy > 68: > yy = yy + 1900 > else: > yy = yy + 2000 ---------------------------------------------------------------------- >Comment By: Mark Nottingham (mnot) Date: 2006-06-23 12:17 Message: Logged In: YES user_id=21868 This bug is still present in the 2.5 library. Will it be fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470 From noreply at sourceforge.net Fri Jun 23 21:18:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 12:18:46 -0700 Subject: [ python-Bugs-1194222 ] parsedate and Y2K Message-ID: Bugs item #1194222, was opened at 2005-05-02 21:37 Message generated for change (Settings changed) made by mnot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&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: Mark Nottingham (mnot) Assigned to: Nobody/Anonymous (nobody) Summary: parsedate and Y2K Initial Comment: rfc822.parsedate and email.Utils.parsedate don't take Y2K into account when parsing two-digit years, even though they're allowed by RFC822. Even though that spec has since been superseded, there are still systems generating dates in the old format, and RFC2616, which bases its dates on RFC822, still allows two-digit years. For example, >>> email.Utils.parsedate("Sun, 6 Nov 94 08:49:37 GMT") (94, 11, 6, 8, 49, 37, 0, 0, 0) Here's a trivial patch to behave as outlined in the time module (I don't test for time.accept2dyear because the input is outside the system's control, and RFC-specified); it's against 2.3, but should be easy to integrate into later versions. 125a126,130 > if yy < 100: > if yy > 68: > yy = yy + 1900 > else: > yy = yy + 2000 ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-23 12:17 Message: Logged In: YES user_id=21868 This bug is still present in the 2.5 library. Will it be fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194222&group_id=5470 From noreply at sourceforge.net Fri Jun 23 21:44:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 12:44:25 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri Jun 23 22:05:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 13:05:04 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-23 20:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 19:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 20:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 12:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 13:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 13:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 13:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 07:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri Jun 23 22:53:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 13:53:36 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri Jun 23 22:57:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 13:57:38 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri Jun 23 23:18:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 14:18:01 -0700 Subject: [ python-Bugs-1511381 ] codec_getstreamcodec passes extra None Message-ID: Bugs item #1511381, was opened at 2006-06-24 00:00 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&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: Unicode Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: codec_getstreamcodec passes extra None Initial Comment: codec_getstreamcodec passes a None object (null pointer, originally) as a "error" argument when errors is given as a null pointer. Due to this behavior, parsers can't utilize cjkcodecs which doesn't allow None as a default argument: SyntaxError: encoding problem: with BOM Attached patch fixes it to omit the argument, "errors", and changed it to use PyObject_CallFunction instead of PyEval_CallFunction because PyEval_CallFunction doesn't work for simple "O" argument. (I don't know it was intended. But we can still use PyEval_CallFunction if we write it as "(O)") I wonder if there's a reason that you chose PyEval_CallFunction for the initialization order or something? How to reproduce the error: echo "# coding: cp949" > test.py ./python test.py ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-06-24 06:18 Message: Logged In: YES user_id=55188 Committed as r47086. Thanks for the review! :) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-24 00:47 Message: Logged In: YES user_id=89016 The patch looks good to me. Switching from PyEval_CallFunction() to PyObject_CallFunction() should be OK. (There seems to be subtle differences between the two, but finding out what it is looks like a scavenger hunt to me :-/)). So go ahead and check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&group_id=5470 From noreply at sourceforge.net Fri Jun 23 23:54:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 14:54:17 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Sat Jun 24 11:59:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 02:59:24 -0700 Subject: [ python-Bugs-1511736 ] Python gettext doesn't support libglade (again) Message-ID: Bugs item #1511736, was opened at 2006-06-24 13:59 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=1511736&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: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade (again) Initial Comment: It looks like bug 516412 is returned back. I have glade interface untranslated in meld application from meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 Opening a new one according to comments of loewis http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:00:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:00:12 -0700 Subject: [ python-Bugs-516412 ] Python gettext doesn't support libglade Message-ID: Bugs item #516412, was opened at 2002-02-12 16:01 Message generated for change (Comment added) made by nshmyrev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&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.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Christian Reis (kiko_async) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade Initial Comment: Libglade is a library that parses XML and generates GTK-based UIs in runtime. It is written in C and supports a number of languages through bindings. James Henstridge has maintained a set of bindings for Python for some time now. These bindings work very well, _except for internationalization_. The reason seems now straightforward to me. Python's gettext.py is a pure python implementation, and because of it, bindtextdomain/textdomain are never called. This causes any C module that uses gettext to not activate the support, and not use translation because of it. Using Martin's intl.so module things work great, but it is a problem for us having to redistribute it with our application. Any other suggestions to fix? ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 14:00 Message: Logged In: YES user_id=598622 https://sourceforge.net/tracker/index.php?func=detail&aid=1511736&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-15 10:03 Message: Logged In: YES user_id=21627 Please don't add messages to a bug report that was closed four years ago. Add a new bug report, explaining your problem. Please be precise in stating what "this" is that you are seeing. ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-15 02:26 Message: Logged In: YES user_id=598622 I am still seeing this with meld application meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-03-27 21:53 Message: Logged In: YES user_id=21627 This is fixed with configure 1.291 configure.in 1.301 pyconfig.h.in 1.25 liblocale.tex 1.28 NEWS 1.369 _localemodule.c 2.29 Notice that applications that want to change the C library's domain bindings will have to invoke locale.bindtextdomain; I decided not to provide automatic forwarding from gettext.bindtextdomain to locale.bindtextdomain, since the C library and Python may have different message catalog formats (e.g. on Solaris); this might confuse the C library. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-02-13 05:15 Message: Logged In: YES user_id=146903 Some libraries (libglade in this case) translate some messages on behalf of the application (libglade translates messages in the input file using the default translation domain, or some other domain specified by the programmer). This is a case of wanting python's gettext module to cooperate with the C level gettext library. For libglade, this could be achieved by making the gettext.bindtextdomain() and gettext.textdomain() calls to call the equivalent C function in addition to what they do now. For most messages in gtk+ itself, it will use dgettext() for most messages already, so isn't a problem. The exception to this is places where it allows other libraries (or the app) to register new stock items, which get translated with a programmer specified domain. As of gettext 0.10.40, there should be no license problems, as the license for the libintl library was changed from GPL to LGPL. It should be a fairly simple to implement this; just needs a patch :) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-02-13 04:17 Message: Logged In: YES user_id=21627 How does gtk invoke gettext? It sounds buggy in the respect that it expects the textdomain to be set globally; a library should not do that. Instead, the right thing (IMO) would be if gtk called dgettext, using an application-supplied domain name. It would be then the matter of the Python gtk wrapper to expose the GTK APIs for setting the text domain. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-12 16:52 Message: Logged In: NO If what you want is a way to call bindtextdomain/textdomain from Python, feel free to supply a patch or ask martin to add intl.so to the distribution. --Guido (@#$% SF always logs me out :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:02:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:02:56 -0700 Subject: [ python-Bugs-1511736 ] Python gettext doesn't support libglade (again) Message-ID: Bugs item #1511736, was opened at 2006-06-24 13:59 Message generated for change (Comment added) made by nshmyrev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&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: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade (again) Initial Comment: It looks like bug 516412 is returned back. I have glade interface untranslated in meld application from meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 Opening a new one according to comments of loewis http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 ---------------------------------------------------------------------- >Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 14:02 Message: Logged In: YES user_id=598622 This code cures the problem, but of course it's just a workaround gtk.glade.bindtextdomain(APP, DIR) gtk.glade.textdomain(APP) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:27:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:27:14 -0700 Subject: [ python-Bugs-1511736 ] Python gettext doesn't support libglade (again) Message-ID: Bugs item #1511736, was opened at 2006-06-24 11:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&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: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade (again) Initial Comment: It looks like bug 516412 is returned back. I have glade interface untranslated in meld application from meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 Opening a new one according to comments of loewis http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:27 Message: Logged In: YES user_id=21627 Can you please provide precise instructions on how to reproduce the problem? It works fine for me. ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 12:02 Message: Logged In: YES user_id=598622 This code cures the problem, but of course it's just a workaround gtk.glade.bindtextdomain(APP, DIR) gtk.glade.textdomain(APP) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:28:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:28:27 -0700 Subject: [ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure Message-ID: Bugs item #1510984, was opened at 2006-06-23 00:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&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: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:28 Message: Logged In: YES user_id=21627 Can you please give a precise reference to what you've downloaded? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:30:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:30:41 -0700 Subject: [ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2 Message-ID: Bugs item #1508010, was opened at 2006-06-18 09:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Retzlaff (jretz) Assigned to: Nobody/Anonymous (nobody) Summary: msvccompiler.py using VC6 with Python 2.5a2 Initial Comment: The change in revision 42515 checks if MSSdk is defined, and if so it will "Assume that the SDK set up everything alright." The problem is that the SDK may be set up for a different version of cl.exe than is expected. In my case I have VC6 and VC7.1 installed and the SDK is set up for VC6. When building extensions for Python 2.5a2, distutils tries to use VC6 in my case. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:30 Message: Logged In: YES user_id=21627 I don't understand the problem. MSSdk gets defined by opening a specific SDK build environment. Just don't open that build environment, but open a regular cmd.exe window, and it should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:35:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:35:01 -0700 Subject: [ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon Message-ID: Bugs item #1507224, was opened at 2006-06-16 13:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&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: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 21:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 From noreply at sourceforge.net Sat Jun 24 12:39:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 03:39:48 -0700 Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing Message-ID: Bugs item #1511497, was opened at 2006-06-23 20:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' >>> So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 From noreply at sourceforge.net Sat Jun 24 14:24:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 05:24:23 -0700 Subject: [ python-Bugs-1511736 ] Python gettext doesn't support libglade (again) Message-ID: Bugs item #1511736, was opened at 2006-06-24 13:59 Message generated for change (Comment added) made by nshmyrev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&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: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade (again) Initial Comment: It looks like bug 516412 is returned back. I have glade interface untranslated in meld application from meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 Opening a new one according to comments of loewis http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 ---------------------------------------------------------------------- >Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 16:24 Message: Logged In: YES user_id=598622 You have to download meld from meld.sourceforge.net. Then build it and run under some locale, say ru_RU.utf8. You'll see untranslated UI under Fedora Core 5. If you'll add a call to gtk.glade.bindtextdomain to meld, you'll see interface translated. Thus I suppose that gettext isn't initialized properly as in original bug. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 14:27 Message: Logged In: YES user_id=21627 Can you please provide precise instructions on how to reproduce the problem? It works fine for me. ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 14:02 Message: Logged In: YES user_id=598622 This code cures the problem, but of course it's just a workaround gtk.glade.bindtextdomain(APP, DIR) gtk.glade.textdomain(APP) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&group_id=5470 From noreply at sourceforge.net Sat Jun 24 15:09:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 06:09:47 -0700 Subject: [ python-Bugs-1511736 ] Python gettext doesn't support libglade (again) Message-ID: Bugs item #1511736, was opened at 2006-06-24 11:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Python gettext doesn't support libglade (again) Initial Comment: It looks like bug 516412 is returned back. I have glade interface untranslated in meld application from meld.sourceforge.net Python 2.4.2 (#1, Feb 12 2006, 03:59:46) [GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2 pygtk2-devel-2.8.4-1.1 Opening a new one according to comments of loewis http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470 ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 15:09 Message: Logged In: YES user_id=21627 Ah, that's a bug in meld. It shouldn't do gettext.bindtextdomain, but locale.bindtextdomain (although gtk.glade.bindtextdomain has the same effect). It is intentional that the Python gettext implementation and the C library's gettext implementation are separate. If you want to use the C library's gettext, you should use the locale.* functions; if you want the pure-Python implementation, use gettext.*. Closing as a third-party bug. ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 14:24 Message: Logged In: YES user_id=598622 You have to download meld from meld.sourceforge.net. Then build it and run under some locale, say ru_RU.utf8. You'll see untranslated UI under Fedora Core 5. If you'll add a call to gtk.glade.bindtextdomain to meld, you'll see interface translated. Thus I suppose that gettext isn't initialized properly as in original bug. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:27 Message: Logged In: YES user_id=21627 Can you please provide precise instructions on how to reproduce the problem? It works fine for me. ---------------------------------------------------------------------- Comment By: Shmyrev Nick (nshmyrev) Date: 2006-06-24 12:02 Message: Logged In: YES user_id=598622 This code cures the problem, but of course it's just a workaround gtk.glade.bindtextdomain(APP, DIR) gtk.glade.textdomain(APP) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511736&group_id=5470 From noreply at sourceforge.net Sat Jun 24 22:12:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 13:12:19 -0700 Subject: [ python-Bugs-1511911 ] vague xref in description of sorted() builtin Message-ID: Bugs item #1511911, was opened at 2006-06-24 20:12 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=1511911&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: rurpy (rurpy) Assigned to: Nobody/Anonymous (nobody) Summary: vague xref in description of sorted() builtin Initial Comment: In section 2.1, "Builtin Functions", in the description of function sorted(), it says: The optional arguments cmp, key, and reverse have the same meaning as those for the list.sort() method. For someone not already very familiar with the organiztion of the Library Reference, a reference to list.sort() is not very useful. If one looks in the index one sees "List Object" and "List, operations on". Although the latter link does bring one to the right page (2.3.6.4 "Mutable Sequence Types") it is not obvious to those not yet used to the loose use of terms in the Puython docs, that "operation" and "method" are synonymous. And God help the poor newbie who forgets the index and tries to find the relevent page using the ToC. I suggest: 1) In sec. 2.1, explicity describe sorted()'s arguments rather than referencing list.sort(). Cut and paste from list.sort. Mention (as a helpful "see also") the existence of the list.sort() method with a link. If that is not acceptable than, 2a) In sec 2.1, change word "method" to "operation", or 2b) In the index under "List", add a link "methods" pointing to section 2.1, (i.e. same target as the currently existing "operations" entry under List. And, 3) In sec 2.1 make the text "List.sorted()" a link to to the List.sorted() page (2.3.6.4 "Mutable Sequence Types") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511911&group_id=5470 From noreply at sourceforge.net Sun Jun 25 01:01:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 16:01:10 -0700 Subject: [ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2 Message-ID: Bugs item #1508010, was opened at 2006-06-18 00:11 Message generated for change (Comment added) made by jretz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Retzlaff (jretz) Assigned to: Nobody/Anonymous (nobody) Summary: msvccompiler.py using VC6 with Python 2.5a2 Initial Comment: The change in revision 42515 checks if MSSdk is defined, and if so it will "Assume that the SDK set up everything alright." The problem is that the SDK may be set up for a different version of cl.exe than is expected. In my case I have VC6 and VC7.1 installed and the SDK is set up for VC6. When building extensions for Python 2.5a2, distutils tries to use VC6 in my case. ---------------------------------------------------------------------- >Comment By: Jimmy Retzlaff (jretz) Date: 2006-06-24 16:01 Message: Logged In: YES user_id=101588 There is an option when installing VC (or at least there used to be, I haven't checked lately) to set the environment variables to take effect system wide. This is useful in that the build environment is always available at any command line (and they are also set when I build from my editor which is not VS). I've left mine pointed at VC6 as I typically do standalone DLLs using VC6 so they are easier to redistribute. Distutils has always selected the right version so it hasn't been an issue for me when working on Python things before. The issue wouldn't be as difficult if the resulting behavior were more obvious. Unfortunately the initial errors in my case were syntax errors arising from macro definitions that changed between VC6 and VC7.1. Most of the time I spent updating py2exe to work with 2.5 was spent on diagnosing this. It wasn???t helped by the fact that I had a blind spot regarding the compiler version. I use a batch file to build py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4 were building fine I didn???t even consider the idea of the wrong compiler version being used for quite a while. For now I just do "set MSSDK=" before building and then everything works just fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 03:30 Message: Logged In: YES user_id=21627 I don't understand the problem. MSSdk gets defined by opening a specific SDK build environment. Just don't open that build environment, but open a regular cmd.exe window, and it should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470 From noreply at sourceforge.net Sun Jun 25 01:28:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 16:28:20 -0700 Subject: [ python-Bugs-1511964 ] Can't use sockets in 2.5b1 Message-ID: Bugs item #1511964, was opened at 2006-06-24 16:28 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=1511964&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: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: Can't use sockets in 2.5b1 Initial Comment: I'm testing Mercurial with Python 2.5b1, and I am getting severe badness in the socket module, complaining that _socket.socket doesn't have a recv_into method. + File "/tmp/hgtests.u_b_G-/install/lib/python/mercurial/httprangereader.py", line 24, in read + f = urllib2.urlopen(req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 121, in urlopen + return _opener.open(url, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 374, in open + response = self._open(req, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 392, in _open+ '_open', req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 353, in _call_chain + result = func(*args) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1099, in http_open + return self.do_open(httplib.HTTPConnection, req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1071, in do_open + h.request(req.get_method(), req.get_selector(), req.data, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 862, in request + self._send_request(method, url, body, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 885, in _send_request + self.endheaders() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 856, in endheaders + self._send_output() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 728, in _send_output + self.send(msg) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 695, in send + self.connect() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 666, in connect + self.sock = socket.socket(af, socktype, proto) + File "/export/home/bos/src/py25/lib/python2.5/socket.py", line 154, in __init__ + self.recv_into = self._sock.recv_into +AttributeError: '_socket.socket' object has no attribute 'recv_into' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470 From noreply at sourceforge.net Sun Jun 25 06:09:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 21:09:14 -0700 Subject: [ python-Bugs-1511998 ] Glitches in What's New for beta 1 Message-ID: Bugs item #1511998, was opened at 2006-06-25 14:09 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=1511998&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: A.M. Kuchling (akuchling) Summary: Glitches in What's New for beta 1 Initial Comment: PEP 343 writeup 2.5a2 changed the generator decorator back to 'contextmanager' when the __context__ method was dropped (without context objects involved, the name contextfactory didn't make sense any more). xmlcore vs xml The notes about the introduction of xmlcore seem a little misleading (implying that 'import xml' will fail on a base 2.5 installation). Isn't the xml namespace a combination of both xmlcore and PyXML? wsgiref The example should either import make_server from wsgiref.simple_server, or else call simple_server.make_server AST compiler documentation People interested in the AST compiler should be directed towards Brett's writeup in PEP 339. http://www.python.org/dev/peps/pep-0339/ Remove of PyRange_New It may be worth noting that you can use PyObject_Call(PyRange_Type, etc...) instead (as per recent python-dev discussion). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511998&group_id=5470 From noreply at sourceforge.net Sun Jun 25 11:33:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 02:33:24 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-25 09:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 21:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 20:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 20:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 20:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 19:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 20:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 12:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 13:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 13:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 13:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 07:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Sun Jun 25 11:38:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 02:38:55 -0700 Subject: [ python-Bugs-1511964 ] Can't use sockets in 2.5b1 Message-ID: Bugs item #1511964, was opened at 2006-06-24 23:28 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&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: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: Can't use sockets in 2.5b1 Initial Comment: I'm testing Mercurial with Python 2.5b1, and I am getting severe badness in the socket module, complaining that _socket.socket doesn't have a recv_into method. + File "/tmp/hgtests.u_b_G-/install/lib/python/mercurial/httprangereader.py", line 24, in read + f = urllib2.urlopen(req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 121, in urlopen + return _opener.open(url, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 374, in open + response = self._open(req, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 392, in _open+ '_open', req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 353, in _call_chain + result = func(*args) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1099, in http_open + return self.do_open(httplib.HTTPConnection, req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1071, in do_open + h.request(req.get_method(), req.get_selector(), req.data, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 862, in request + self._send_request(method, url, body, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 885, in _send_request + self.endheaders() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 856, in endheaders + self._send_output() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 728, in _send_output + self.send(msg) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 695, in send + self.connect() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 666, in connect + self.sock = socket.socket(af, socktype, proto) + File "/export/home/bos/src/py25/lib/python2.5/socket.py", line 154, in __init__ + self.recv_into = self._sock.recv_into +AttributeError: '_socket.socket' object has no attribute 'recv_into' ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-25 09:38 Message: Logged In: YES user_id=4771 This looks like a broken install. The socket objects do have a recv_into() method in socketmodule.c. Try "make clean; make". If it does not help, check where the _socket module comes from with: python2.5 >>> import _socket >>> print _socket.__file__ and make sure that this file is among the ones you just recompiled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470 From noreply at sourceforge.net Sun Jun 25 12:04:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 03:04:56 -0700 Subject: [ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon Message-ID: Bugs item #1507224, was opened at 2006-06-16 11:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&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: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-25 10:04 Message: Logged In: YES user_id=4771 Internally, CPython sets up its path using a single ':'-separated string. I have no clue how, on Posix, you are supposed to use paths containing ':' in environment variables like $PATH - escape the colons somehow? If there is some escape mechanism, we could support it, both as an internal way to fix the present issue, and directly in parsing PYTHONPATH. If there is no such mechanism, then I can only conclude that having colons in paths will make many other things unhappy, not just Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 10:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 19:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 From noreply at sourceforge.net Sun Jun 25 12:16:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 03:16:06 -0700 Subject: [ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon Message-ID: Bugs item #1507224, was opened at 2006-06-16 13:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&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: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-25 12:16 Message: Logged In: YES user_id=21627 The issue is not with environment variables at all; they play no role in this bug report. There is no convention for an escape mechanism in environment variables, and we should not introduce one, but again, this report is not about environment variables. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 12:04 Message: Logged In: YES user_id=4771 Internally, CPython sets up its path using a single ':'-separated string. I have no clue how, on Posix, you are supposed to use paths containing ':' in environment variables like $PATH - escape the colons somehow? If there is some escape mechanism, we could support it, both as an internal way to fix the present issue, and directly in parsing PYTHONPATH. If there is no such mechanism, then I can only conclude that having colons in paths will make many other things unhappy, not just Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 21:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 From noreply at sourceforge.net Sun Jun 25 15:45:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 06:45:10 -0700 Subject: [ python-Bugs-1512124 ] OSX: debugger hangs IDLE Message-ID: Bugs item #1512124, was opened at 2006-06-25 06:45 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=1512124&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Aahz (aahz) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: OSX: debugger hangs IDLE Initial Comment: This has been previously found on 2.3/2.4 and verified again with 2.5b1 (was hoping that the 1.2 IDLE update would fix): When you bring up the debugger window in IDLE on OSX, you'll notice that it's vibrating, as if it's stuck in a resize loop. Unless you immediately resize the window manually, IDLE will hang the next time you try to do something that updates the debugger window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 From noreply at sourceforge.net Sun Jun 25 17:38:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 08:38:46 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 16:38 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=1512163&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: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Sun Jun 25 20:54:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 11:54:26 -0700 Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string Message-ID: Bugs item #1472251, was opened at 2006-04-18 05:16 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: 3 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'run' crashes when the it's first argument is non-string Initial Comment: Pdb 'run/runeval' commands fails to check the type of given argument.When argument to 'run/runeval' is non-string the functions crashes with further impilications on (correctly)invoking this functions: Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31) >>> def x(): pass >>> import pdb >>> pdb.run(x()) Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 363, in run cmd = cmd+'\n' TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run('x()') > /home/jkk/python/python-svn/Lib/pdb.py(1113)run() -> Pdb().run(statement, globals, locals) (Pdb) # CTRL-D pressed Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/home/jkk/python/python-svn/Lib/bdb.py", line 67, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit The solution is to simply ensure that the first argument passed to the 'run/runeval' functions is string. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-25 11:54 Message: Logged In: YES user_id=971153 I have looked at what's happening in a bit more detail and now I agree that the current behaviour seems wrong. Apparently, when one passes a nonstring to bdb's run(), bdb sets tracing first and only then throws an exception... Leaving tracing on seems like a bad thing to do Would calling settrace() a couple lines later be the simplest solution then? so relevant fragment of bdb.py's run() becomes: if not isinstance(cmd, types.CodeType): cmd = cmd+'\n' sys.settrace(self.trace_dispatch) This should prevent bdb from turning tracing too early. What do you think? ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-06-19 06:48 Message: Logged In: YES user_id=1491175 You're right,but don't you think that this kind of switching between namespaces could confuse users? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-22 20:36 Message: Logged In: YES user_id=971153 Well, I don't see anything in bdb's run which could overwrite your namespace.. What seems to be happenning in your example is that bdb's first line event happens while bdb is still in run(), so you when you see pdb's prompt, are in bdb's namespace not in yours.. If you do "next" you will get where you should be.. bagira:~> python2.4 Python 2.4.1 (#2, May 5 2005, 11:32:06) >>> def x(): print "in x" >>> import pdb >>> pdb.run( x()) in x TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run( 'x()' ) > /usr/lib/python2.4/pdb.py(987)run() -> Pdb().run(statement, globals, locals) (Pdb) n #now you are back in your namespace > (1)?() (Pdb) p x #and you get your symbols back (Pdb) p pdb (Pdb) n in x --Return-- > (1)?()->None What do you think? ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-05-22 02:20 Message: Logged In: YES user_id=1491175 The point is that when you want to invoke pdb.run correctly (with string argument) after getting TypeError as in above example, your namespace is probably overwritten or deleted so that you don't have access to previously defined symbols. >>> def x():pass >>> import pdb >>> pdb.run(x()) TypeError >>> pdb.run('x()') > /home/jkk/python-svn/Lib/pdb.py(1122)run() -> Pdb().run(statement, globals, locals) (Pdb) pdb *** NameError: name 'pdb' is not defined (Pdb) x *** NameError: name 'x' is not defined ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-21 16:25 Message: Logged In: YES user_id=971153 I would not classify your example as a crash. You passed a wrong value (None in your case) into pdb.run() and got back a TypeError...Isn't it an expected response? E.g if you do: >>>max(13) You'll also get: "TypeError" Am I missing something? Could you clarify? ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-04-18 05:36 Message: Logged In: YES user_id=1491175 Patch is in #1472257 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 From noreply at sourceforge.net Sun Jun 25 21:52:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 12:52:31 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 08:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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: David Watson (baikie) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 12:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Sun Jun 25 22:49:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 13:49:30 -0700 Subject: [ python-Bugs-1512124 ] OSX: debugger hangs IDLE Message-ID: Bugs item #1512124, was opened at 2006-06-25 15:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&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: IDLE Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Aahz (aahz) >Assigned to: Nobody/Anonymous (nobody) Summary: OSX: debugger hangs IDLE Initial Comment: This has been previously found on 2.3/2.4 and verified again with 2.5b1 (was hoping that the 1.2 IDLE update would fix): When you bring up the debugger window in IDLE on OSX, you'll notice that it's vibrating, as if it's stuck in a resize loop. Unless you immediately resize the window manually, IDLE will hang the next time you try to do something that updates the debugger window. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 22:49 Message: Logged In: YES user_id=580910 And when you do resize the window layout sucks, automatic layout seems to be buggy here (although I must admit that I haven't seen IDLE on other platforms). I have no idea what is causing this bug. Upgrading the Tk version to the very latest instead of using the system version doesn't help. I've checked in a workaround in revision 47091. That patch avoids explicitly sizing the stackviewer widget on OSX, which seems to fix this problem. The debugger window now is rather less wide than it was before, which means users will likely have to resize the window if they want to use the debugger. I'm leaving this bug open and unassign it in the hope that someone who actually knows Tkinter proposed a better fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:07:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:07:18 -0700 Subject: [ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon Message-ID: Bugs item #1507224, was opened at 2006-06-16 13:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&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: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:07 Message: Logged In: YES user_id=580910 One way to fix this to redefine Py_GetPath to return some kind of array instead string that is formatted like PYTHONPATH. Another option is returning a string where path elements are seperated by NUL bytes (with two NUL bytes at the end to make it possible to find the end of the path). A problem with this is that this would make it impossible to have empty strings in your PYTHONPATH (such as 'somedir::otherdir'). Both options have the disadvantage that they change a public interface (embedders can reimplement Py_GetPath to get full control over the construction of sys.path). BTW. This bug was found by a user of py2app, a py2exe-like tool for macosx. A user of his application complained that the application didn't run when it was stored in a directory with colons in its name. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-25 12:16 Message: Logged In: YES user_id=21627 The issue is not with environment variables at all; they play no role in this bug report. There is no convention for an escape mechanism in environment variables, and we should not introduce one, but again, this report is not about environment variables. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 12:04 Message: Logged In: YES user_id=4771 Internally, CPython sets up its path using a single ':'-separated string. I have no clue how, on Posix, you are supposed to use paths containing ':' in environment variables like $PATH - escape the colons somehow? If there is some escape mechanism, we could support it, both as an internal way to fix the present issue, and directly in parsing PYTHONPATH. If there is no such mechanism, then I can only conclude that having colons in paths will make many other things unhappy, not just Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:35 Message: Logged In: YES user_id=21627 I think this can be fixed. sys.prefix should be treated as unspittable when constructing sys.path, i.e. sys.prefix should be inserted only after the colon-splitting has been done. Not sure what the best way to implement that would be, though, so unassigning. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 21:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:16:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:16:59 -0700 Subject: [ python-Bugs-1508369 ] logging module formatter problem with %(filename)s Message-ID: Bugs item #1508369, was opened at 2006-06-19 04:08 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&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: Macintosh Group: Python 2.4 Status: Open >Resolution: Fixed Priority: 5 Submitted By: David Hess (david_k_hess) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:16 Message: Logged In: YES user_id=580910 Fixed in revision #47093 for python2.5. I'm not closing the bug yet because I haven't backported this to 2.4 yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:23:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:23:37 -0700 Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X Message-ID: Bugs item #995019, was opened at 2004-07-21 08:19 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&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: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Bumgarner (bbum) Assigned to: Jack Jansen (jackjansen) Summary: Ensure -single_module on Mac OS X Initial Comment: When building Python (and disutils based extensions) on Mac OS X, Python should ensure that the -single_module flag is being passed to the linker. This will ensure that any given .so, .dylib, or framework is linked as a single module. This will vastly reduce the startup times of python, reduce the load times of modules, and shave a bit of a performance hit off the top at runtime. This should also be applicable to the modules built by distutils. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:23 Message: Logged In: YES user_id=580910 Is this still relevant? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-07-22 23:09 Message: Logged In: YES user_id=45365 Am I doing something wrong? I see absolutely no difference in runtime with this option: I get 0.15 seconds realtime (0.08 user time, system time variable) both with the new OTHER_LIBTOOL_OPT and without it. (This is on a 933Mhz G4 iBook running 10.3.4). I've been trying this with 2.4a1+. What sort of speedups are you guys seeing? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 11:50 Message: Logged In: YES user_id=139309 time python -c pass is probably sufficient.. I guess the patch is to line 114 of Makefile.pre.in.. should change from: OTHER_LIBTOOL_OPT = -prebind -seg1addr 0x10000000 to OTHER_LIBTOOL_OPT = -prebind -seg1addr 0xCFC00000 -single_module Note I picked an arbitrary, probably unused, seg1addr. 0x10000000 is *NOT* correct! It's in the Application Address Range!!!! See: http://developer.apple.com/documentation/Performance/Conceptual/ LaunchTime/index.html ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-07-21 11:21 Message: Logged In: YES user_id=45365 Could either of you come up with a patch? Also, how would I measure any improvement, "time python -c pass" or are there other things that are influenced as well? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 10:25 Message: Logged In: YES user_id=139309 Not in the least. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-07-21 08:57 Message: Logged In: YES user_id=43607 Is this related to bug 799088? ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2004-07-21 08:35 Message: Logged In: YES user_id=103811 This is not applicable to the distutils modules as they are built now; only applicable to Python.framework (and like builds). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 08:29 Message: Logged In: YES user_id=139309 [I'm closing 995023, because bbum filed first] distutils extensions can not use -single_module because they are bundles, not dylibs. Frameworks and dylibs are synonymous, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:24:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:24:52 -0700 Subject: [ python-Bugs-922690 ] package manager page outdated link Message-ID: Bugs item #922690, was opened at 2004-03-24 21:07 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: package manager page outdated link Initial Comment: The page http://www.python.org/packman/ has outdated links to Bob Ippolito's page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:24 Message: Logged In: YES user_id=580910 Closing this bug, Package Manager is no longer maintained and was removed from the python repository before 2.5b1. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-27 00:52 Message: Logged In: YES user_id=1188172 This is still a problem. The packman page needs update, as it seems. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-03-30 18:57 Message: Logged In: YES user_id=593130 To supplement the summary: the two links (xml and html) on the bottom of the packman page work but they are specific to (an older? verseion) the pimp package. The higher link suggested as a substitue lists other packages, including some that appear to have been extracted from pimp. Since the current page references aeve 0.0.3 while the suggested link references aeve 0.0.4, the suggest change seems proper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:27:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:27:14 -0700 Subject: [ python-Bugs-1087737 ] Mac: make frameworkinstall skips docs, scripts Message-ID: Bugs item #1087737, was opened at 2004-12-19 01:09 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&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: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mac: make frameworkinstall skips docs, scripts Initial Comment: "make frameworkinstall" for a framework build of Python installs a symlink to the interpreter in /usr/local, but it doesn't do the same for the man page, scripts and maybe other auxiliary files. Either it needs to install these, or it needs to be documented that they aren't installed, preferably with an option to install them with an extra make. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:27 Message: Logged In: YES user_id=580910 Current wisdom seems to be that it's better to add the directories inside the framework to relevant paths (PATH and MANPATH) instead of adding symlinks in /usr/local. The binary installer will install a symlink to the embedded documentation in / Developer/Documentation. IMHO this can be closed. BTW. 'make frameworkinstall' is deprecated as well, just use 'make install'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:28:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:28:16 -0700 Subject: [ python-Bugs-887242 ] "-framework Python" for building modules is bad Message-ID: Bugs item #887242, was opened at 2004-01-29 21:40 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&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: Macintosh Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: "-framework Python" for building modules is bad Initial Comment: We should use the -bundle_loader method for linking modules for both the framework and non-framework verisons of Python. All of these "version mismatch" errors would pretty much be avoided if this were the case, since a 10.2 and 10.3 MacPython 2.3 should be binary compatible. There are other reasons to use -bundle_loader, such as using the same suite of modules for both Stackless and regular Python. Besides, -bundle_loader is for building -bundles :) It's a simple change to the configure script, and it would be great if this could happen before OS X 10.4. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:28 Message: Logged In: YES user_id=580910 This was fixed a long time ago, the fix is present in 2.4. Hence closing this as fixed. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 14:42 Message: Logged In: YES user_id=45365 I checked in the mods I mentioned in my previous followup: configure.in rev. 1.455 configure rev. 1.444 Makefile.pre.in rev. 1.143 Lib/distutils/sysconfig.py rev.1.58 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-02 23:37 Message: Logged In: YES user_id=45365 I'm finally getting around to revisiting this bug, and I ran into another problem (that we've already discussed offline, but I'm adding it here for posterity): -undefined dynamic_lookup only works if you have MACOSX_DEPLOYMENT_TARGET set, and set to >= "10.2". I'm now experimenting with the following: if you have that variable set during configure time it will use dynamic_lookup. Moreover, it will record the value of MACOSX_DEPLOYMENT_TARGET in the Makefile. Distutils will check that the current value of MACOSX_DEPLOYMENT_TARGET is the same as that during configure time, and complain if not. I've resisted the temptation to force MACOSX_DEPLOYMENT_TARGET to the configure-time value in distutils, because I think we may break things that way. Feel free to convince me otherwise:-) I'm only doing this for 2.4 right now, as a straight backport to 2.3 is useless: the Makefile is already supplied by Apple. So, any fix for 2.3.X will need to be a band-aid in distutils (possibly triggered by an environment variable?). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-04-02 10:34 Message: Logged In: YES user_id=139309 minimal patch for Python 2.4 CVS configure.in (and configure) attached. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-01-30 00:21 Message: Logged In: YES user_id=139309 -undefined dynamic_lookup has a localized effect, it still uses two level namespaces and doesn't force the whole process to go flat. Apple uses this flag for Perl in 10.3 (maybe other things, like Apache), so presumably they designed it with situations like ours in mind. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-01-30 00:11 Message: Logged In: YES user_id=45365 Ok, I only tried -bundle_loader Python.framework, and when that didn't work I stopped trying. But I have some misgivings about the -undefined dynamic_lookup: doesn't this open up the whole flat namespace/undefined suppress can of worms that we had under 10.1? What we *really* want is to a way to tell the linker "at runtime, the host program must already have loaded a Python.framework, any Python.framework, and that is what we want to link against". ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-01-30 00:05 Message: Logged In: YES user_id=139309 That's not true. -bundle_loader does not generate a mach header load command, it is merely so that ld can make sure that all of your symbols are defined at link time (it will work for an embedded Python, try it). You do need -undefined dynamic_lookup though, because -bundle_loader doesn't respect indirect symbols. I'm not sure it's possible to make Python.framework get "imported" into the executable so that it's possible to -bundle_loader without -undefined dynamic_lookup (-prebind maybe, but I doubt it). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-01-29 23:53 Message: Logged In: YES user_id=45365 There's a reason why I use -framework in stead of -bundle_loader: you can only specify an application as bundle_loader, not Python.framework itself. This means you have to specify the Python executable, which makes it impossible to load extension modules (including all the standard extension modules) into an application embedding Python. I don't think this is acceptable. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-01-29 23:24 Message: Logged In: YES user_id=139309 err, this is a 10.3+ only request, and requires use of -undefined dynamic_lookup as well ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:29:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:29:24 -0700 Subject: [ python-Bugs-838144 ] PackageManager does not clean up after itself Message-ID: Bugs item #838144, was opened at 2003-11-07 21:47 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838144&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: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager does not clean up after itself Initial Comment: This was discussed on-list, but PackageManager downloads files to /tmp, but never removes them. Documentation should at least mention this, perhaps also on the MacPython page. I will add this information to the pythonmac.org wiki as well. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:29 Message: Logged In: YES user_id=580910 Closed as 'won't fix' because PackageManager is no longer maintained and was dropped from the 2.5 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838144&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:30:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:30:33 -0700 Subject: [ python-Bugs-779154 ] PackageManager maintainer missing documentation Message-ID: Bugs item #779154, was opened at 2003-07-28 22:48 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779154&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: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager maintainer missing documentation Initial Comment: I was unable to locate maintainer documentation on the schema of the PackageManager database ( http:// python.org/packman/version-0.3/darwin-6.6- Power_Macintosh.plist ). I was also unable to locate documentation for how a maintainer would build one of these databases (particularly for binary packages). However, I was able to reverse engineer it by looking at the Package Manager/PIMP sourcecode, and I've prototyped an example script for building a binary package and spitting out a template for its entry in the plist. It's attached. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:30 Message: Logged In: YES user_id=580910 Closed as "Won't Fix" because PackageManager was dropped in 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779154&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:32:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:32:54 -0700 Subject: [ python-Bugs-758566 ] IDE preferences cleanup Message-ID: Bugs item #758566, was opened at 2003-06-22 00:17 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758566&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: Macintosh Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IDE preferences cleanup Initial Comment: The IDE preferences need to go under the Application- >Preferences menu. I think the only reasonable way to do this without changing too much code is that that menu entry opens a window that shows the current settings, with buttons that open the windows that are used in the current implementation. The funny font selector for the GUI elements also needs to be named better. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:32 Message: Logged In: YES user_id=580910 Closed as "Won't Fix" because the Python IDE was dropped before 2.5b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758566&group_id=5470 From noreply at sourceforge.net Sun Jun 25 23:36:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 14:36:40 -0700 Subject: [ python-Bugs-778799 ] scripts destination directory not on default path Message-ID: Bugs item #778799, was opened at 2003-07-28 10:36 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778799&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: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: scripts destination directory not on default path Initial Comment: A distutils script that uses the 'scripts' directive will install the scripts in /Library/Frameworks/Versions/2.3/bin This directory is not on the path, and no documentation explains how to *put* it on the path. The end result is that 3rd party python libraries that install command line utilities don't work out of the box. If we need to have scripts and stuff dual homed in /Library/Frameworks/Versions/2.3/bin and /usr/local/bin, distutils will need to be patched to maintain the symlinks (although I personally feel putting anything in /usr/local/bin is a bad idea...). This of course will not be possible for the 2.3.0 release. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:36 Message: Logged In: YES user_id=580910 Current wisdom is that its better to add the directories inside the framework to your PATH. The binary installers for 2.4.3 and 2.5b1 do this for you (even if the solution used isn't ideal). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778799&group_id=5470 From noreply at sourceforge.net Mon Jun 26 10:50:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 01:50:13 -0700 Subject: [ python-Bugs-1512504 ] builtin enumerate overflows Message-ID: Bugs item #1512504, was opened at 2006-06-26 08:50 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=1512504&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: James Harlow (hythloday) Assigned to: Nobody/Anonymous (nobody) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&group_id=5470 From noreply at sourceforge.net Mon Jun 26 11:29:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 02:29:46 -0700 Subject: [ python-Bugs-1511381 ] codec_getstreamcodec passes extra None Message-ID: Bugs item #1511381, was opened at 2006-06-23 17:00 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&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: Unicode Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: codec_getstreamcodec passes extra None Initial Comment: codec_getstreamcodec passes a None object (null pointer, originally) as a "error" argument when errors is given as a null pointer. Due to this behavior, parsers can't utilize cjkcodecs which doesn't allow None as a default argument: SyntaxError: encoding problem: with BOM Attached patch fixes it to omit the argument, "errors", and changed it to use PyObject_CallFunction instead of PyEval_CallFunction because PyEval_CallFunction doesn't work for simple "O" argument. (I don't know it was intended. But we can still use PyEval_CallFunction if we write it as "(O)") I wonder if there's a reason that you chose PyEval_CallFunction for the initialization order or something? How to reproduce the error: echo "# coding: cp949" > test.py ./python test.py ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-26 11:29 Message: Logged In: YES user_id=89016 Closing the patch ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-06-23 23:18 Message: Logged In: YES user_id=55188 Committed as r47086. Thanks for the review! :) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-23 17:47 Message: Logged In: YES user_id=89016 The patch looks good to me. Switching from PyEval_CallFunction() to PyObject_CallFunction() should be OK. (There seems to be subtle differences between the two, but finding out what it is looks like a scavenger hunt to me :-/)). So go ahead and check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511381&group_id=5470 From noreply at sourceforge.net Mon Jun 26 13:15:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 04:15:55 -0700 Subject: [ python-Bugs-1512604 ] Install on Windows Vista locks up Message-ID: Bugs item #1512604, was opened at 2006-06-26 06:15 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=1512604&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: 5 Submitted By: Michael Lucas (michael_lucas) Assigned to: Nobody/Anonymous (nobody) Summary: Install on Windows Vista locks up Initial Comment: I have had problems trying to install this version on Vista. When the install gets to the verifying disk space requirements the system locks up. It does not go any further. I have to cancel the instalation of python. The only way I have got around this is to install an older version of python (version 2.3.5) this version does work, but there are newer versions that I want to work with on my system. If anyone has a work around for this please contact me at michael.lucas at us.army.mil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470 From noreply at sourceforge.net Mon Jun 26 14:45:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 05:45:25 -0700 Subject: [ python-Bugs-1511998 ] Glitches in What's New for beta 1 Message-ID: Bugs item #1511998, was opened at 2006-06-25 00:09 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511998&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: A.M. Kuchling (akuchling) Summary: Glitches in What's New for beta 1 Initial Comment: PEP 343 writeup 2.5a2 changed the generator decorator back to 'contextmanager' when the __context__ method was dropped (without context objects involved, the name contextfactory didn't make sense any more). xmlcore vs xml The notes about the introduction of xmlcore seem a little misleading (implying that 'import xml' will fail on a base 2.5 installation). Isn't the xml namespace a combination of both xmlcore and PyXML? wsgiref The example should either import make_server from wsgiref.simple_server, or else call simple_server.make_server AST compiler documentation People interested in the AST compiler should be directed towards Brett's writeup in PEP 339. http://www.python.org/dev/peps/pep-0339/ Remove of PyRange_New It may be worth noting that you can use PyObject_Call(PyRange_Type, etc...) instead (as per recent python-dev discussion). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:45 Message: Logged In: YES user_id=11375 Suggested changes applied; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511998&group_id=5470 From noreply at sourceforge.net Mon Jun 26 14:56:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 05:56:34 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 11:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: "This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock." Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 15:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Mon Jun 26 15:05:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 06:05:04 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 16:05 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=1512695&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: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Mon Jun 26 15:06:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 06:06:04 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 16:05 Message generated for change (Settings changed) made by faik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Mon Jun 26 15:27:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 06:27:05 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 11:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 09:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: "This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock." Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 15:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Mon Jun 26 15:47:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 06:47:43 -0700 Subject: [ python-Bugs-1504333 ] sgmlib should allow angle brackets in quoted values Message-ID: Bugs item #1504333, was opened at 2006-06-11 08:58 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&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: Sam Ruby (rubys) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sgmlib should allow angle brackets in quoted values Initial Comment: Real live example (search for "other
corrections") http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html This addresses the following (included in the file): # XXX The following should skip matching quotes (' or ") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470 From noreply at sourceforge.net Mon Jun 26 16:08:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 07:08:45 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 16:05 Message generated for change (Comment added) made by faik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- >Comment By: Faik Uygur (faik) Date: 2006-06-26 17:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Mon Jun 26 17:16:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 08:16:36 -0700 Subject: [ python-Bugs-1512791 ] module wave does no rounding Message-ID: Bugs item #1512791, was opened at 2006-06-26 15:16 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=1512791&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: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: module wave does no rounding Initial Comment: In wave.py, a floating point frame rate is truncated (rather than rounded) in function _write_header(). Fractional frame rates are perfectly reasonable, even if not normally seen in audio practice, and the software ought to represent them as accurately as possible. Moreover, it's sometimes reasonable to store the inverse of the frame rate, which is the time interval between frames. That's important when you're doing signal processing, and some data formats store 1.0/framerate rather than framerate. Anyhow, if you give setframerate() a float, it truncates rather than rounding, so dt = 1.0/44100 setframerate(1.0/dt) can end up setting the frame rate to 44099 Hz in the resulting data file. The fix is to change the last line of setframerate() to self._framerate = int(round(framerate)) . That also has the beneficial side-effect of giving an earlier error report in case someone gives the wrong type of object to setframerate() (such as None, or "44100", or some class). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512791&group_id=5470 From noreply at sourceforge.net Mon Jun 26 18:01:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 09:01:55 -0700 Subject: [ python-Bugs-1512814 ] Incorrect lineno's in code objects Message-ID: Bugs item #1512814, was opened at 2006-06-26 18:01 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=1512814&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Jeremy Hylton (jhylton) Summary: Incorrect lineno's in code objects Initial Comment: The 2.5 compiler forgets how to count linenumbers in certain situations: >>> s255 = "".join(["\n"] * 255 + ["spam"]) >>> s256 = "".join(["\n"] * 256 + ["spam"]) >>> exec s255 Traceback (most recent call last): File "", line 1, in File "", line 256, in NameError: name 'spam' is not defined >>> exec s256 Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: name 'spam' is not defined Notice the 'line 1' linenumber in the case of 256 blank lines. The same happens for 'pass' statements or 'if 0' blocks instead of blank lines. The problem is in the actual code objects created: >>> dis.disco(compile(s255, "", "exec")) 256 0 LOAD_NAME 0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE >>> dis.disco(compile(s256, "", "exec")) 1 0 LOAD_NAME 0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470 From noreply at sourceforge.net Mon Jun 26 19:01:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 10:01:49 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Brett Cannon (bcannon) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon Jun 26 20:15:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 11:15:29 -0700 Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing Message-ID: Bugs item #1511497, was opened at 2006-06-23 20:14 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' >>> So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2006-06-26 20:15 Message: Logged In: YES user_id=9205 I built Python directly from the SVN trunk repository with $ ./configure && make altinstall I attached the pyconfig.h that was generated. If you need more info, feel free to ask. After building and installing, I started up python2.5 and executed "import xml.sax.expatreader" and then "print xml.sax.expatreader", and nothing else. Another thing I tried is "import from", which works. But importing xml.sax.expatreader directly, as noted above, does not work. Here is the log with the "import from" test: Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from xml.sax import expatreader >>> print expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 From noreply at sourceforge.net Mon Jun 26 21:31:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 12:31:50 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Brett Cannon (bcannon) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Tue Jun 27 00:03:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 15:03:05 -0700 Subject: [ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time Message-ID: Bugs item #1508864, was opened at 2006-06-19 14:53 Message generated for change (Settings changed) made by qopit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) >Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-26 16:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 From noreply at sourceforge.net Tue Jun 27 00:52:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 15:52:27 -0700 Subject: [ python-Bugs-1511497 ] xml.sax.expatreader is missing Message-ID: Bugs item #1511497, was opened at 2006-06-23 20:14 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' >>> So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-27 00:52 Message: Logged In: YES user_id=1326842 I see the same behaviour with the official Python 2.5 beta 1 Windows installer. The interesting thing is that the expatreader module is present in sys.modules: Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 ... >>> import xml.sax.expatreader >>> xml.sax.expatreader Traceback (most recent call last): ... AttributeError: 'module' object has no attribute 'expatreader' >>> import sys >>> sys.modules['xml.sax.expatreader'] All of the other modules in xml package can be imported without any trouble. I don't understand what is the real problem here, but it goes away if you import xmlcore.sax package before expatreader: [restart python] >>> import xmlcore.sax >>> import xml.sax.expatreader >>> xml.sax.expatreader The simplest fix would be to use at least one absolute import in ...\lib\xmlcore\sax\__init__.py, for example you could change line 22: from xmlreader import InputSource to: from xmlcore.sax.xmlreader import InputSource but that might just hide the real bug. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2006-06-26 20:15 Message: Logged In: YES user_id=9205 I built Python directly from the SVN trunk repository with $ ./configure && make altinstall I attached the pyconfig.h that was generated. If you need more info, feel free to ask. After building and installing, I started up python2.5 and executed "import xml.sax.expatreader" and then "print xml.sax.expatreader", and nothing else. Another thing I tried is "import from", which works. But importing xml.sax.expatreader directly, as noted above, does not work. Here is the log with the "import from" test: Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from xml.sax import expatreader >>> print expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 From noreply at sourceforge.net Tue Jun 27 00:54:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 15:54:14 -0700 Subject: [ python-Bugs-1513032 ] 'make install' failure on FreeBSD 5.3 Message-ID: Bugs item #1513032, was opened at 2006-06-26 23:54 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=1513032&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.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: 'make install' failure on FreeBSD 5.3 Initial Comment: Version: 2.5b1 See attached log. 'install' seems to be being passed an unexpanded glob due to Lib/lib-old being empty. Creating a file in lib-old allows installation to continue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513032&group_id=5470 From noreply at sourceforge.net Tue Jun 27 00:56:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 15:56:10 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 16:38 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: David Watson (baikie) Date: 2006-06-26 23:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 14:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 13:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: "This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock." Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 20:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Tue Jun 27 01:24:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 16:24:31 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 11:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 19:24 Message: Logged In: YES user_id=11375 Hm, this looks messy; I doubt the module can know if you want lockf() or fcntl() locking. Maybe Mailbox.lock() should grow an optional parameter that lets you specify the locking mechanism to use -- lockf, fcntl, or both. (But defaulting to what?) On the other hand, maybe it's too late to go making API changes for beta2 (but I suspect it would be OK in this case). ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-06-26 18:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 09:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: "This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock." Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 15:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Tue Jun 27 05:21:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 20:21:51 -0700 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 08:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&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: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 20:21 Message: Logged In: YES user_id=33168 Is the optional parameter necessary if you use inheritance (assuming there's a class/object in there)? Maybe it would be better to have a subclass? Would that be better for us to provide or just to add something to the docs that a user could make a subclass to work around locking issues? I haven't looked at the issues, but if we really need an API change, I'm probably ok with it since it would seem to be quite small. If an API change is really required (doc isn't sufficient), I'd like it to go in ASAP. We could doc for 2.5 and if there's a problem fix for 2.6. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 16:24 Message: Logged In: YES user_id=11375 Hm, this looks messy; I doubt the module can know if you want lockf() or fcntl() locking. Maybe Mailbox.lock() should grow an optional parameter that lets you specify the locking mechanism to use -- lockf, fcntl, or both. (But defaulting to what?) On the other hand, maybe it's too late to go making API changes for beta2 (but I suspect it would be OK in this case). ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-06-26 15:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 06:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 05:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: "This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock." Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 12:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Tue Jun 27 05:22:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 20:22:59 -0700 Subject: [ python-Bugs-1512504 ] builtin enumerate overflows Message-ID: Bugs item #1512504, was opened at 2006-06-26 01:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&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: James Harlow (hythloday) >Assigned to: Raymond Hettinger (rhettinger) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 20:22 Message: Logged In: YES user_id=33168 Raymond, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&group_id=5470 From noreply at sourceforge.net Tue Jun 27 06:13:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 21:13:20 -0700 Subject: [ python-Bugs-1513032 ] 'make install' failure on FreeBSD 5.3 Message-ID: Bugs item #1513032, was opened at 2006-06-26 15:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513032&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Watson (baikie) >Assigned to: Neal Norwitz (nnorwitz) Summary: 'make install' failure on FreeBSD 5.3 Initial Comment: Version: 2.5b1 See attached log. 'install' seems to be being passed an unexpanded glob due to Lib/lib-old being empty. Creating a file in lib-old allows installation to continue. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 21:13 Message: Logged In: YES user_id=33168 Thanks! Committed revision 47115. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513032&group_id=5470 From noreply at sourceforge.net Tue Jun 27 06:41:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 21:41:11 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-21 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) >Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 21:41 Message: Logged In: YES user_id=33168 http://mail.python.org/pipermail/python-dev/2006-June/066197.html Nick you made mention of changing the docs, but I'm not sure if you did or not. Could you address this bug? Thanks. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-06-23 06:52 Message: Logged In: YES user_id=34209 See the discussion started at: http://mail.python.org/pipermail/python-dev/2006-June/066161.html It's not a bug in 328 or 338 (the PEP that adds the -m switch for packages), but in the interaction between the two. I don't think this will be fixed for 2.5, since there is no obvious fix. If it hurts when you press there, don't press there. Either don't use -m for packaged modules, or have the packaged module only use absolute imports. (But don't be surprised if the script-module is imported twice, once as __main__ and once as the module itself. That's a whole other bug/feature.) ---------------------------------------------------------------------- Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-21 16:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-21 15:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 14:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Tue Jun 27 07:13:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 22:13:02 -0700 Subject: [ python-Bugs-1512504 ] builtin enumerate overflows Message-ID: Bugs item #1512504, was opened at 2006-06-26 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&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: James Harlow (hythloday) Assigned to: Raymond Hettinger (rhettinger) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-27 00:13 Message: Logged In: YES user_id=80475 You're correct. The behavior was by design, emphasizing speed and simplicity over a toy limiting case. If some app actually requires enumeration of over 2**31 objects, it is trivial to write a generator that gives the desired flexibility. Of course, on 64 bit machines, the limit is a bit higher ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 22:22 Message: Logged In: YES user_id=33168 Raymond, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&group_id=5470 From noreply at sourceforge.net Tue Jun 27 09:25:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 00:25:49 -0700 Subject: [ python-Bugs-1512504 ] builtin enumerate overflows Message-ID: Bugs item #1512504, was opened at 2006-06-26 08:50 Message generated for change (Comment added) made by hythloday You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&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: James Harlow (hythloday) Assigned to: Raymond Hettinger (rhettinger) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! ---------------------------------------------------------------------- >Comment By: James Harlow (hythloday) Date: 2006-06-27 07:25 Message: Logged In: YES user_id=458963 Fair enough, I take your points both about the ease of making a new generator. Is it possible to make the existing one a bit less surprising, though, by having it raise an exception when it wraps? I'm at a loss to think of any algorithm that would work correctly when it wraps, so a new exception wouldn't be a change in interface reeeeeeeeally. ;) Failing that, is it possible to document it? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-27 05:13 Message: Logged In: YES user_id=80475 You're correct. The behavior was by design, emphasizing speed and simplicity over a toy limiting case. If some app actually requires enumeration of over 2**31 objects, it is trivial to write a generator that gives the desired flexibility. Of course, on 64 bit machines, the limit is a bit higher ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 03:22 Message: Logged In: YES user_id=33168 Raymond, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512504&group_id=5470 From noreply at sourceforge.net Tue Jun 27 10:12:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 01:12:18 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 16:05 Message generated for change (Comment added) made by faik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- >Comment By: Faik Uygur (faik) Date: 2006-06-27 11:12 Message: Logged In: YES user_id=1541018 Back trace: #0 PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149 #1 0xa7b92024 in Instance_New (cls=0xa7bba064, args=0xa7c1a43c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637 #2 0xa7b93798 in load (self=0xa7c0a80c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389 #3 0xa7b953c8 in cpm_loads (self=0x0, args=0x0) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481 #4 0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108 #5 0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at Python/ceval.c:3563 #6 0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, closure=0x0) at Python/ceval.c:2736 #7 0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at Python/ceval.c:484 #8 0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, globals=0x0, locals=0x0, flags=0x0) at Python/pythonrun.c:1265 #9 0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:860 #10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:664 #11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at Modules/main.c:493 #12 0x0804867a in main (argc=0x0, argv=0x0) at Modules/python.c:23 ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-26 17:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Tue Jun 27 11:54:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 02:54:15 -0700 Subject: [ python-Bugs-1513223 ] socket close() hangs client if used without prior shutdown() Message-ID: Bugs item #1513223, was opened at 2006-06-27 11:54 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=1513223&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: socket close() hangs client if used without prior shutdown() Initial Comment: In Python 2.5b1, when closing a client socket using socket.close(), the connecting client hangs. I.e. the socket is not properly taken down. If you add an explicit call to socket.shutdown(), prior to the close(), it works again. But I think this shutdown() should not be mandatory? At least, it wasn't in older Python versions. Sample code attached. Run the script and connect to socket 9000. If you remove the call to shutdown, your client connection will hang (use telnet or netcat). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 From noreply at sourceforge.net Tue Jun 27 13:34:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 04:34:46 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-22 05:35 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:34 Message: Logged In: YES user_id=1038590 The issue isn't actually unique to the -m switch - the problem is that relative imports are based on __name__, and in the main module, __name__ always has the value '__main__'. Hence, relative imports currently can't work properly from the main module of an application, because the main module doesn't know where it really fits in the Python module namespace (this is at least fixable in theory for the main modules executed through the -m switch, but directly executed files and the interactive interpreter are completely out of luck). With the old implicit relative imports this behaviour is masked by the fact that executing a module puts that module's directory on sys.path. When you execute a module in a package directly, it actually imports its sibling modules as top-level modules. The fact that the -m switch doesn't allow this to occur is a deliberate design decision (putting package directories on the system level path is a bad idea because you can get multiple copies of the same module under different names). You should be able get something similar to the old implicit relative import behaviour by sticking the following at the top of your module (before doing any relative imports): if __name__ = '__main__': from os.path import dirname __path__ = [dirname(__file__)] del dirname This makes the relative import machinery treat your main module as a package. The problem with this workaround is that, just like the old situation with implicit relative imports from the main module, you may end up with two different copies of the sibling modules in sys.modules. One copy will be '__main__.foo' while the other will be 'package.foo' (with implicit relative imports, the first copy would have been a top level module called 'foo'). When I went to document this, I got stuck on the fact that section 6 of the tutorial hasn't been updated for PEP 328 at *all*. And the language ref palms the details off on to Guido's packages essay. So describing the limitation in the real documentation entails documenting PEP 328 properly in the first place (which I'm *not* volunteering to do :). However, I'll add a section to PEP 328 about '__main__' and relative imports (including the workaround to get something similar to the old behaviour back). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 14:41 Message: Logged In: YES user_id=33168 http://mail.python.org/pipermail/python-dev/2006-June/066197.html Nick you made mention of changing the docs, but I'm not sure if you did or not. Could you address this bug? Thanks. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-06-23 23:52 Message: Logged In: YES user_id=34209 See the discussion started at: http://mail.python.org/pipermail/python-dev/2006-June/066161.html It's not a bug in 328 or 338 (the PEP that adds the -m switch for packages), but in the interaction between the two. I don't think this will be fixed for 2.5, since there is no obvious fix. If it hurts when you press there, don't press there. Either don't use -m for packaged modules, or have the packaged module only use absolute imports. (But don't be surprised if the script-module is imported twice, once as __main__ and once as the module itself. That's a whole other bug/feature.) ---------------------------------------------------------------------- Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-22 09:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-22 08:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-22 07:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Tue Jun 27 13:46:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 04:46:17 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-22 05:35 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:46 Message: Logged In: YES user_id=1038590 All that said, PEP 328 currently says that "from ...sys import path" should be legal from moduleX in the example. I tried it, and it currently fails - the ValueError gets raised as soon as the number of dots in the relative path exceeds the number of dots in __name__, instead of treating a single excess dot as requesting an absolute import instead. (All of the other examples in the PEP work as specified when moduleX and subpackage1 are imported rather than executed directly) I believe fixing this would also fix Mitch's problem - an explicit relative import from __main__ would be treated as a top level import. I also have an idea regarding the -m switch that I will raise on python-dev. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:34 Message: Logged In: YES user_id=1038590 The issue isn't actually unique to the -m switch - the problem is that relative imports are based on __name__, and in the main module, __name__ always has the value '__main__'. Hence, relative imports currently can't work properly from the main module of an application, because the main module doesn't know where it really fits in the Python module namespace (this is at least fixable in theory for the main modules executed through the -m switch, but directly executed files and the interactive interpreter are completely out of luck). With the old implicit relative imports this behaviour is masked by the fact that executing a module puts that module's directory on sys.path. When you execute a module in a package directly, it actually imports its sibling modules as top-level modules. The fact that the -m switch doesn't allow this to occur is a deliberate design decision (putting package directories on the system level path is a bad idea because you can get multiple copies of the same module under different names). You should be able get something similar to the old implicit relative import behaviour by sticking the following at the top of your module (before doing any relative imports): if __name__ = '__main__': from os.path import dirname __path__ = [dirname(__file__)] del dirname This makes the relative import machinery treat your main module as a package. The problem with this workaround is that, just like the old situation with implicit relative imports from the main module, you may end up with two different copies of the sibling modules in sys.modules. One copy will be '__main__.foo' while the other will be 'package.foo' (with implicit relative imports, the first copy would have been a top level module called 'foo'). When I went to document this, I got stuck on the fact that section 6 of the tutorial hasn't been updated for PEP 328 at *all*. And the language ref palms the details off on to Guido's packages essay. So describing the limitation in the real documentation entails documenting PEP 328 properly in the first place (which I'm *not* volunteering to do :). However, I'll add a section to PEP 328 about '__main__' and relative imports (including the workaround to get something similar to the old behaviour back). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 14:41 Message: Logged In: YES user_id=33168 http://mail.python.org/pipermail/python-dev/2006-June/066197.html Nick you made mention of changing the docs, but I'm not sure if you did or not. Could you address this bug? Thanks. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-06-23 23:52 Message: Logged In: YES user_id=34209 See the discussion started at: http://mail.python.org/pipermail/python-dev/2006-June/066161.html It's not a bug in 328 or 338 (the PEP that adds the -m switch for packages), but in the interaction between the two. I don't think this will be fixed for 2.5, since there is no obvious fix. If it hurts when you press there, don't press there. Either don't use -m for packaged modules, or have the packaged module only use absolute imports. (But don't be surprised if the script-module is imported twice, once as __main__ and once as the module itself. That's a whole other bug/feature.) ---------------------------------------------------------------------- Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-22 09:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-22 08:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-22 07:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:04:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:04:26 -0700 Subject: [ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time Message-ID: Bugs item #1508864, was opened at 2006-06-19 15:53 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:04 Message: Logged In: YES user_id=764593 Logically, these calls should always use clock, since they don't care about the actual time; they only want a baseline for computing elapsed time. Are you saying that they should still use clock-time on linux anyway, because of resolution issues? ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-26 17:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:39:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:39:24 -0700 Subject: [ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure Message-ID: Bugs item #1510984, was opened at 2006-06-22 18:53 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&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: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:39 Message: Logged In: YES user_id=764593 All versions are binary downloads for windows, from python.org I have a 2.4, which seems not to be relevant. I don't remember whether I had installed 2.5a1, though I think so. If I had, it was successfully overwritten by 2.5a2. I had definately installed 2.5a2. The problem came when I attempted to install 2.5b1 on top of 2.5a2. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 06:28 Message: Logged In: YES user_id=21627 Can you please give a precise reference to what you've downloaded? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 From noreply at sourceforge.net Tue Jun 27 22:01:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 13:01:01 -0700 Subject: [ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time Message-ID: Bugs item #1508864, was opened at 2006-06-19 14:53 Message generated for change (Comment added) made by qopit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- >Comment By: Russell Warren (qopit) Date: 2006-06-27 15:01 Message: Logged In: YES user_id=1542586 No - just stating that clock() is definitely a better solution for win32. As you say, any system should just use a time-indpendent uptime counter that is as high resolution as possible. I don't know how to get this on linux, but I do seem to recall that, on linux, time() is higher resolution than clock() for some reason. If linux has no performance counter equivalent (isn't it a hardware thing anyway?) I have no clue which is worse... low resolution, or local time change issues. The first is limiting all the time, the second results in wacky and sporadic errors that people might not expect. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 10:04 Message: Logged In: YES user_id=764593 Logically, these calls should always use clock, since they don't care about the actual time; they only want a baseline for computing elapsed time. Are you saying that they should still use clock-time on linux anyway, because of resolution issues? ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-26 16:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 From noreply at sourceforge.net Tue Jun 27 23:06:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 14:06:50 -0700 Subject: [ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python 2.5b1 Message-ID: Bugs item #1513611, was opened at 2006-06-27 23:06 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=1513611&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.ParseException weirdness in python 2.5b1 Initial Comment: There is something weird going on with xml.sax exceptions, probably related to the xml/xmlcore shuffle: from xml.sax import make_parser, SAXParseException from StringIO import StringIO parser = make_parser() try: parser.parse(StringIO('invalid')) except SAXParseException: print 'caught it!' On python 2.4.3 this prints "caught it!". On python 2.5b1 the exception is not caught, because it is a different exception: an xmlcore.sax._exceptions.SAXParseException. Printing the SAXParseException imported from xml.sax gives "". Stumbled on this running the logilab-common (see logilab.org) tests with python 2.5b1, but it seems likely other code will be affected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470 From noreply at sourceforge.net Wed Jun 28 00:01:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 15:01:03 -0700 Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows Message-ID: Bugs item #1513646, was opened at 2006-06-27 15:01 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=1513646&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Yi S. Ding (yi_ding) Assigned to: Nobody/Anonymous (nobody) Summary: os.access reports incorrect write permissions in Windows Initial Comment: Platform: Python 2.5b1 Windows XP Bug: os.access will report that a user doesn't have write permissions to a file or directory when the user actually does. Reproducibility: always This is being run on an administrator account. >>> import os >>> os.access("C:\\", os.W_OK) False >>> os.access("C:\\test.txt", os.W_OK) False I have also checked that Python can indeed write to the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470 From noreply at sourceforge.net Wed Jun 28 07:28:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 22:28:43 -0700 Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows Message-ID: Bugs item #1513646, was opened at 2006-06-27 15:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Yi S. Ding (yi_ding) Assigned to: Nobody/Anonymous (nobody) Summary: os.access reports incorrect write permissions in Windows Initial Comment: Platform: Python 2.5b1 Windows XP Bug: os.access will report that a user doesn't have write permissions to a file or directory when the user actually does. Reproducibility: always This is being run on an administrator account. >>> import os >>> os.access("C:\\", os.W_OK) False >>> os.access("C:\\test.txt", os.W_OK) False I have also checked that Python can indeed write to the file. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 22:28 Message: Logged In: YES user_id=33168 Does this problem only occur with 2.5 or is it also present in 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470 From noreply at sourceforge.net Wed Jun 28 08:09:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 23:09:22 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 06:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Faik Uygur (faik) >Assigned to: Neal Norwitz (nnorwitz) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 23:09 Message: Logged In: YES user_id=33168 Faik, can you see if the attached patch fixes this problem. I believe it should. I can't reproduce the problem with the patch. ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-27 01:12 Message: Logged In: YES user_id=1541018 Back trace: #0 PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149 #1 0xa7b92024 in Instance_New (cls=0xa7bba064, args=0xa7c1a43c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637 #2 0xa7b93798 in load (self=0xa7c0a80c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389 #3 0xa7b953c8 in cpm_loads (self=0x0, args=0x0) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481 #4 0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108 #5 0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at Python/ceval.c:3563 #6 0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, closure=0x0) at Python/ceval.c:2736 #7 0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at Python/ceval.c:484 #8 0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, globals=0x0, locals=0x0, flags=0x0) at Python/pythonrun.c:1265 #9 0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:860 #10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:664 #11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at Modules/main.c:493 #12 0x0804867a in main (argc=0x0, argv=0x0) at Modules/python.c:23 ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-26 07:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Wed Jun 28 08:39:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 23:39:21 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 06:05 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Faik Uygur (faik) Assigned to: Neal Norwitz (nnorwitz) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 23:39 Message: Logged In: YES user_id=33168 I'm impatient and think this fixes the problem. So I'm closing this report. Please re-open if the patch didn't fix your problem. (I checked in something slightly different that the patch attached.) Committed revision 47139. Committed revision 47140. (2.4) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 23:09 Message: Logged In: YES user_id=33168 Faik, can you see if the attached patch fixes this problem. I believe it should. I can't reproduce the problem with the patch. ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-27 01:12 Message: Logged In: YES user_id=1541018 Back trace: #0 PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149 #1 0xa7b92024 in Instance_New (cls=0xa7bba064, args=0xa7c1a43c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637 #2 0xa7b93798 in load (self=0xa7c0a80c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389 #3 0xa7b953c8 in cpm_loads (self=0x0, args=0x0) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481 #4 0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108 #5 0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at Python/ceval.c:3563 #6 0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, closure=0x0) at Python/ceval.c:2736 #7 0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at Python/ceval.c:484 #8 0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, globals=0x0, locals=0x0, flags=0x0) at Python/pythonrun.c:1265 #9 0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:860 #10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:664 #11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at Modules/main.c:493 #12 0x0804867a in main (argc=0x0, argv=0x0) at Modules/python.c:23 ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-26 07:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Wed Jun 28 09:41:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 00:41:12 -0700 Subject: [ python-Bugs-1513802 ] Change the name of a variable causes an exception Message-ID: Bugs item #1513802, was opened at 2006-06-28 13:11 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=1513802&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: Arun (arunarunarun) Assigned to: Nobody/Anonymous (nobody) Summary: Change the name of a variable causes an exception Initial Comment: [Python n00b alert] I'm trying this little script, and I see an exception like: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'refcount'" in ignored If I change the variable name 's1' to something like 's4', I don't see this exception. Also, if I manually delete the object before the script ends, the exception does not occur. Seems that class Shape is destroyed before all it's objects are destroyed. Is this acceptable? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&group_id=5470 From noreply at sourceforge.net Wed Jun 28 09:42:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 00:42:14 -0700 Subject: [ python-Bugs-1513802 ] Changing the name of a variable causes an exception Message-ID: Bugs item #1513802, was opened at 2006-06-28 13:11 Message generated for change (Settings changed) made by arunarunarun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&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: Arun (arunarunarun) Assigned to: Nobody/Anonymous (nobody) >Summary: Changing the name of a variable causes an exception Initial Comment: [Python n00b alert] I'm trying this little script, and I see an exception like: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'refcount'" in ignored If I change the variable name 's1' to something like 's4', I don't see this exception. Also, if I manually delete the object before the script ends, the exception does not occur. Seems that class Shape is destroyed before all it's objects are destroyed. Is this acceptable? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&group_id=5470 From noreply at sourceforge.net Wed Jun 28 10:54:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 01:54:09 -0700 Subject: [ python-Bugs-1513802 ] __del__: Type is cleared before instances Message-ID: Bugs item #1513802, was opened at 2006-06-28 07:41 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&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: Arun (arunarunarun) Assigned to: Nobody/Anonymous (nobody) >Summary: __del__: Type is cleared before instances Initial Comment: [Python n00b alert] I'm trying this little script, and I see an exception like: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'refcount'" in ignored If I change the variable name 's1' to something like 's4', I don't see this exception. Also, if I manually delete the object before the script ends, the exception does not occur. Seems that class Shape is destroyed before all it's objects are destroyed. Is this acceptable? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&group_id=5470 From noreply at sourceforge.net Wed Jun 28 12:51:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 03:51:57 -0700 Subject: [ python-Bugs-1513913 ] mimetools message's To field can't be changed Message-ID: Bugs item #1513913, was opened at 2006-06-28 12:51 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=1513913&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: Albert Strasheim (fullung2) Assigned to: Nobody/Anonymous (nobody) Summary: mimetools message's To field can't be changed Initial Comment: Steps to reproduce: >>> from email.MIMEText import MIMEText >>> msg = MIMEText('') >>> msg['To'] = 'foo at bar.com' >>> msg['To'] 'foo at bar.com' >>> msg['To'] = 'foo at baz.com' >>> msg['To'] 'foo at bar.com' (should be @baz.com?) Same problem exists in Python 2.4.3 and Python 2.5b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513913&group_id=5470 From noreply at sourceforge.net Wed Jun 28 13:39:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 04:39:07 -0700 Subject: [ python-Bugs-1513893 ] BOM UTF8 not written Message-ID: Bugs item #1513893, was opened at 2006-06-28 12:25 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513893&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: Unicode Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: EricL (taziup) Assigned to: M.-A. Lemburg (lemburg) Summary: BOM UTF8 not written Initial Comment: The utf8 BOM (defined in codecs) is not written to a file open with codecs.open or with codecs.EncodedFile Perhaps, the utf16 BOM is correctly written to the file. I've tested this problem on Python 2.4.3 on XP and python 2.3.5 on debian sarge I corrected this by adding the write of the BOM in the encoding.utf8.StreamWritter class but i think it's not the correct place. Enjoy. Eric ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-28 13:39 Message: Logged In: YES user_id=38388 No, that won't work since the codec relies on new features we added in 2.5. ---------------------------------------------------------------------- Comment By: EricL (taziup) Date: 2006-06-28 13:31 Message: Logged In: YES user_id=1539001 Ok, so just put the codec in the 'encoding' directory in python 2.4 ? ---------------------------------------------------------------------- Comment By: EricL (taziup) Date: 2006-06-28 13:31 Message: Logged In: YES user_id=1539001 Ok, so just put the codec in the 'encoding' directory in python 2.4 ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-28 12:39 Message: Logged In: YES user_id=38388 We have a utf-8-sig codec in Python 2.5 that supports just this. You might want to take a look at the current Python 2.5 beta. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513893&group_id=5470 From noreply at sourceforge.net Wed Jun 28 14:11:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 05:11:37 -0700 Subject: [ python-Bugs-1488906 ] endless loop in PyCFunction_Fini() Message-ID: Bugs item #1488906, was opened at 2006-05-15 11:05 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488906&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: Matejcik (spektrum) Assigned to: Nobody/Anonymous (nobody) Summary: endless loop in PyCFunction_Fini() Initial Comment: see https://bugzilla.novell.com/show_bug.cgi?id=171066 Basically, under some circumstances not yet determined, PyCFunction_Fini() goes into an endless loop over a cyclic linked list. void PyCFunction_Fini(void) { while (free_list) { PyCFunctionObject *v = free_list; free_list = (PyCFunctionObject *)(v->m_self); PyObject_GC_Del(v); } } it looks like it's sufficient to do v->m_self = NULL; or something. However, for one, i'm not sure if this wouldn't break something, and for two, free_list should never be cyclic, right? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-28 08:11 Message: Logged In: YES user_id=1344176 I've been unable to reproduce this with any combination of the following: libxml2 (v2.6.23, v2.6.26), Python (v2.4.1, v2.4.2, v2.4.3, SVN r47141). Testing was done on Linux 2.6.13 x86 with gcc 3.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488906&group_id=5470 From noreply at sourceforge.net Thu Jun 29 04:25:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 19:25:02 -0700 Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build Message-ID: <200606290225.k5T2P2m0008129@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1451717, was opened at 03/16/06 14:22 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&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: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: OS/X on i386 framework build Initial Comment: in Makefile.pre (374) it hard codes the architecture to 'ppc' which isn't correct for the new x86 boxes. this needs to be i386 for the framework install to actually build on the new macs. regards Ian ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 06/28/06 19:24 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 05/23/06 05:51 Message: Logged In: YES user_id=580910 This has been fixed on the trunk. I'll backport this to 2.4.x in the near future. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 04/17/06 07:07 Message: Logged In: YES user_id=580910 BTW. The 'also' bit has been fixed in the trunk. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 04/02/06 12:21 Message: Logged In: YES user_id=580910 This is a duplicate of bug 1447587 ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 03/16/06 14:34 Message: Logged In: YES user_id=5209 also.. in plat-mac/applesingle.py the fields AS_HEADER_FORMAT and AS_ENTRY_FORMAT need a '>' infront of the definitions AS_HEADER_FORMAT=">LL16sh" AS_ENTRY_FORMAT=">lll" (this is what the system-packaged python has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 From noreply at sourceforge.net Thu Jun 29 18:01:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 09:01:58 -0700 Subject: [ python-Bugs-1514404 ] Typo in signal.alarm() description Message-ID: Bugs item #1514404, was opened at 2006-06-29 17:01 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=1514404&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: Stephen Shirley (kormat) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in signal.alarm() description Initial Comment: In the alarm() description paragraph on http://docs.python.org/lib/module-signal.html , the phrase 'no alarm id scheduled' should be 'no alarm is scheduled' (i.e. the 'id' changed to 'is'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&group_id=5470 From noreply at sourceforge.net Thu Jun 29 18:13:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 09:13:21 -0700 Subject: [ python-Bugs-1514420 ] Missing module code does spurious file search Message-ID: Bugs item #1514420, was opened at 2006-06-29 16:13 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=1514420&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: 5 Submitted By: Nick Maclaren (nmm) Assigned to: Nobody/Anonymous (nobody) Summary: Missing module code does spurious file search Initial Comment: Now, exactly WHY is it looking for a file called ? :-) This bug has been present since at least 2.3.3 - I can't be bothered to check back further. Not surprisingly, it causes misbehaviour if there is a file called in any of the places searched, but it doesn't strike me as the world's most catastrophic bug. strace -e open python Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46) [GCC 4.1.0 (SUSE Linux)] on linux2 >>> import dismal open("dismal.so", O_RDONLY) = -1 ENOENT (No such file or directory)open("dismalmodule.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("dismal.py", O_RDONLY) = -1 ENOENT (No such file or directory) open("dismal.pyc", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/dismal.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/site-packages/", O_RDONLY) = -1 ENOENT (No such file or directory) File "", line 1, in ImportError: No module named dismal >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&group_id=5470 From noreply at sourceforge.net Thu Jun 29 18:19:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 09:19:47 -0700 Subject: [ python-Bugs-1514428 ] NaN comparison in Decimal broken Message-ID: Bugs item #1514428, was opened at 2006-06-29 16:19 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=1514428&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: Nick Maclaren (nmm) Assigned to: Nobody/Anonymous (nobody) Summary: NaN comparison in Decimal broken Initial Comment: Methinks this is a bit off :-) True should be False. Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46) [GCC 4.1.0 (SUSE Linux)] on linux2 >>> import decimal >>> d = decimal.Decimal >>> inf = d("inf") >>> nan = d("nan") >>> nan > inf True >>> nan < inf False >>> inf > nan True >>> inf < nan False b ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470 From noreply at sourceforge.net Thu Jun 29 18:42:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 09:42:47 -0700 Subject: [ python-Bugs-1514451 ] zipfile "append" mode should create a file if not present Message-ID: Bugs item #1514451, was opened at 2006-06-29 22:12 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=1514451&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: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile "append" mode should create a file if not present Initial Comment: The line filename = zipfile.ZipFile(zip_file_name, "a") throws an exception if the given filename is not present already. Shouldn't it create a file (in case one is not there) since it is "append" mode ?? It's throwing an OSError Exception stating "No such file/directory". Normal convention has been that when opening a file in append mode, if the file is not present a new file is created. Why is this non-standard? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514451&group_id=5470 From noreply at sourceforge.net Thu Jun 29 19:01:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 10:01:01 -0700 Subject: [ python-Bugs-1514404 ] Typo in signal.alarm() description Message-ID: Bugs item #1514404, was opened at 2006-06-30 01:01 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&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: Closed >Resolution: Out of Date Priority: 5 Submitted By: Stephen Shirley (kormat) >Assigned to: George Yoshida (quiver) Summary: Typo in signal.alarm() description Initial Comment: In the alarm() description paragraph on http://docs.python.org/lib/module-signal.html , the phrase 'no alarm id scheduled' should be 'no alarm is scheduled' (i.e. the 'id' changed to 'is'). ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-06-30 02:01 Message: Logged In: YES user_id=671362 Thanks for the report, but this is already fixed in the repository. See bug #1462496 http://www.python.org/sf/1462496 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514404&group_id=5470 From noreply at sourceforge.net Thu Jun 29 19:17:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 10:17:24 -0700 Subject: [ python-Bugs-1504333 ] sgmllib should allow angle brackets in quoted values Message-ID: Bugs item #1504333, was opened at 2006-06-11 08:58 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Sam Ruby (rubys) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: sgmllib should allow angle brackets in quoted values Initial Comment: Real live example (search for "other
corrections") http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html This addresses the following (included in the file): # XXX The following should skip matching quotes (' or ") ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-29 13:17 Message: Logged In: YES user_id=3066 I checked in a modified version of this patch: changed to use separate REs for start and end tags to reduce matching cost for end tags; extended tests; updated to avoid breaking previous changes to support IPv6 addresses in unquoted attribute values. Committed as revisions 47154 (trunk) and 47155 (release24-maint). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470 From noreply at sourceforge.net Thu Jun 29 19:38:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 10:38:59 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Thu Jun 29 19:45:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 10:45:05 -0700 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 16:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:45 Message: Logged In: YES user_id=357491 For the deldict.py crasher, if you look at the traceback there is no good place to do a check that tp_dict is sane except in type_module() or PyDict_GetItem(). Now adding the NULL check in type_module() will fix this specific problem, but that seems like an ad-hoc patch. Why don't we check for NULL in PyDict_GetItem() and return NULL just like the PyDict_Check() test? I am sure the answer is "performance", but this is not PyDict_GETITEM()and thus already is not the performance-critical version anyway. So why shouldn't we check for NULL there and possibly catch other errors? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:41 Message: Logged In: YES user_id=357491 Simple patch for the loosing_dict_ref.py crasher is attached. Just checked for possible NULL values in what is needed by _Py_ForgetReference(). Let me know what you think, Armin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-14 07:36 Message: Logged In: YES user_id=6656 Yikes! ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 07:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 06:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 01:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:22:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:22:30 -0700 Subject: [ python-Bugs-1514540 ] String Methods 2.3.6.1 not in TOC Message-ID: Bugs item #1514540, was opened at 2006-06-29 14:22 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=1514540&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: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: String Methods 2.3.6.1 not in TOC Initial Comment: Quoting from c.l.p thread Python Docs Bug: "One long-standing irritation I have with the table of contents for the Python Library Reference , is that there is one very important section, "String Methods" , which does not appear there. That's because it is section 2.3.6.1, and the table of contents only goes to 3 levels." I am third to agree. To not change rule, perhaps this section could be lifted to third level. It really is one that people need to refer back to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514540&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:44:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:44:34 -0700 Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows Message-ID: Bugs item #1513646, was opened at 2006-06-28 00:01 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&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: Windows Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Yi S. Ding (yi_ding) >Assigned to: Martin v. L??wis (loewis) Summary: os.access reports incorrect write permissions in Windows Initial Comment: Platform: Python 2.5b1 Windows XP Bug: os.access will report that a user doesn't have write permissions to a file or directory when the user actually does. Reproducibility: always This is being run on an administrator account. >>> import os >>> os.access("C:\\", os.W_OK) False >>> os.access("C:\\test.txt", os.W_OK) False I have also checked that Python can indeed write to the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-28 07:28 Message: Logged In: YES user_id=33168 Does this problem only occur with 2.5 or is it also present in 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:46:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:46:26 -0700 Subject: [ python-Bugs-1511964 ] Can't use sockets in 2.5b1 Message-ID: Bugs item #1511964, was opened at 2006-06-25 01:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&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: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: Can't use sockets in 2.5b1 Initial Comment: I'm testing Mercurial with Python 2.5b1, and I am getting severe badness in the socket module, complaining that _socket.socket doesn't have a recv_into method. + File "/tmp/hgtests.u_b_G-/install/lib/python/mercurial/httprangereader.py", line 24, in read + f = urllib2.urlopen(req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 121, in urlopen + return _opener.open(url, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 374, in open + response = self._open(req, data) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 392, in _open+ '_open', req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 353, in _call_chain + result = func(*args) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1099, in http_open + return self.do_open(httplib.HTTPConnection, req) + File "/export/home/bos/src/py25/lib/python2.5/urllib2.py", line 1071, in do_open + h.request(req.get_method(), req.get_selector(), req.data, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 862, in request + self._send_request(method, url, body, headers) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 885, in _send_request + self.endheaders() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 856, in endheaders + self._send_output() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 728, in _send_output + self.send(msg) + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 695, in send + self.connect() + File "/export/home/bos/src/py25/lib/python2.5/httplib.py", line 666, in connect + self.sock = socket.socket(af, socktype, proto) + File "/export/home/bos/src/py25/lib/python2.5/socket.py", line 154, in __init__ + self.recv_into = self._sock.recv_into +AttributeError: '_socket.socket' object has no attribute 'recv_into' ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-29 20:46 Message: Logged In: YES user_id=21627 Also, please report what operating system this is on. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 11:38 Message: Logged In: YES user_id=4771 This looks like a broken install. The socket objects do have a recv_into() method in socketmodule.c. Try "make clean; make". If it does not help, check where the _socket module comes from with: python2.5 >>> import _socket >>> print _socket.__file__ and make sure that this file is among the ones you just recompiled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511964&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:48:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:48:32 -0700 Subject: [ python-Bugs-1512604 ] Install on Windows Vista locks up Message-ID: Bugs item #1512604, was opened at 2006-06-26 13:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&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: 5 Submitted By: Michael Lucas (michael_lucas) Assigned to: Nobody/Anonymous (nobody) Summary: Install on Windows Vista locks up Initial Comment: I have had problems trying to install this version on Vista. When the install gets to the verifying disk space requirements the system locks up. It does not go any further. I have to cancel the instalation of python. The only way I have got around this is to install an older version of python (version 2.3.5) this version does work, but there are newer versions that I want to work with on my system. If anyone has a work around for this please contact me at michael.lucas at us.army.mil ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-29 20:48 Message: Logged In: YES user_id=21627 I can confirm the problem, but I doubt I can do much about it. In fact, I believe this is a bug in Vista/Windows Installer 4.0. The installer GUI waits for the CostingComplete property to be set, but this never happens. If you are a beta tester, please make a bug report to Microsoft. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:59:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:59:59 -0700 Subject: [ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2 Message-ID: Bugs item #1508010, was opened at 2006-06-18 09:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&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: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Jimmy Retzlaff (jretz) >Assigned to: Martin v. L??wis (loewis) Summary: msvccompiler.py using VC6 with Python 2.5a2 Initial Comment: The change in revision 42515 checks if MSSdk is defined, and if so it will "Assume that the SDK set up everything alright." The problem is that the SDK may be set up for a different version of cl.exe than is expected. In my case I have VC6 and VC7.1 installed and the SDK is set up for VC6. When building extensions for Python 2.5a2, distutils tries to use VC6 in my case. ---------------------------------------------------------------------- Comment By: Jimmy Retzlaff (jretz) Date: 2006-06-25 01:01 Message: Logged In: YES user_id=101588 There is an option when installing VC (or at least there used to be, I haven't checked lately) to set the environment variables to take effect system wide. This is useful in that the build environment is always available at any command line (and they are also set when I build from my editor which is not VS). I've left mine pointed at VC6 as I typically do standalone DLLs using VC6 so they are easier to redistribute. Distutils has always selected the right version so it hasn't been an issue for me when working on Python things before. The issue wouldn't be as difficult if the resulting behavior were more obvious. Unfortunately the initial errors in my case were syntax errors arising from macro definitions that changed between VC6 and VC7.1. Most of the time I spent updating py2exe to work with 2.5 was spent on diagnosing this. It wasn???t helped by the fact that I had a blind spot regarding the compiler version. I use a batch file to build py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4 were building fine I didn???t even consider the idea of the wrong compiler version being used for quite a while. For now I just do "set MSSDK=" before building and then everything works just fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:30 Message: Logged In: YES user_id=21627 I don't understand the problem. MSSdk gets defined by opening a specific SDK build environment. Just don't open that build environment, but open a regular cmd.exe window, and it should work fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470 From noreply at sourceforge.net Thu Jun 29 21:56:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 12:56:57 -0700 Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows Message-ID: Bugs item #1513646, was opened at 2006-06-27 15:01 Message generated for change (Comment added) made by yi_ding You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Yi S. Ding (yi_ding) Assigned to: Martin v. L??wis (loewis) Summary: os.access reports incorrect write permissions in Windows Initial Comment: Platform: Python 2.5b1 Windows XP Bug: os.access will report that a user doesn't have write permissions to a file or directory when the user actually does. Reproducibility: always This is being run on an administrator account. >>> import os >>> os.access("C:\\", os.W_OK) False >>> os.access("C:\\test.txt", os.W_OK) False I have also checked that Python can indeed write to the file. ---------------------------------------------------------------------- >Comment By: Yi S. Ding (yi_ding) Date: 2006-06-29 12:56 Message: Logged In: YES user_id=1081617 Yeah, it's only 2.5, and only 2.5b1. Basically, there's a double ampersand used instead of a single ampersand in posixmodule.c. I've attached the patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 22:28 Message: Logged In: YES user_id=33168 Does this problem only occur with 2.5 or is it also present in 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470 From noreply at sourceforge.net Thu Jun 29 22:21:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 13:21:10 -0700 Subject: [ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure Message-ID: Bugs item #1510984, was opened at 2006-06-22 18:53 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&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: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-06-29 16:21 Message: Logged In: YES user_id=764593 I can no longer locate the alpha installers, but I'll see if I can reproduce it with the beta installer plus a 2.4 version. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-29 14:59 Message: Logged In: YES user_id=21627 I could not reproduce the problem. Can you please try to reproduce it, installing things in the order you did? Please provide all details, such as sequence of MSI invocations, options selected, reboots/logouts performed, etc. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:39 Message: Logged In: YES user_id=764593 All versions are binary downloads for windows, from python.org I have a 2.4, which seems not to be relevant. I don't remember whether I had installed 2.5a1, though I think so. If I had, it was successfully overwritten by 2.5a2. I had definately installed 2.5a2. The problem came when I attempted to install 2.5b1 on top of 2.5a2. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 06:28 Message: Logged In: YES user_id=21627 Can you please give a precise reference to what you've downloaded? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 From noreply at sourceforge.net Thu Jun 29 23:19:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 14:19:57 -0700 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-29 21:19 Message: Logged In: YES user_id=4771 Brett: I think you're approaching the problem from the wrong angle. The problem is being allowed to freely tamper with the dict stored in objects. Getting NULL errors here and there is only a symptom. As I explain, the '__dict__' descriptor object needs to do some more checks, and to be fully safe some Py_INCREF/Py_DECREF are needed in some critical places. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:45 Message: Logged In: YES user_id=357491 For the deldict.py crasher, if you look at the traceback there is no good place to do a check that tp_dict is sane except in type_module() or PyDict_GetItem(). Now adding the NULL check in type_module() will fix this specific problem, but that seems like an ad-hoc patch. Why don't we check for NULL in PyDict_GetItem() and return NULL just like the PyDict_Check() test? I am sure the answer is "performance", but this is not PyDict_GETITEM()and thus already is not the performance-critical version anyway. So why shouldn't we check for NULL there and possibly catch other errors? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:41 Message: Logged In: YES user_id=357491 Simple patch for the loosing_dict_ref.py crasher is attached. Just checked for possible NULL values in what is needed by _Py_ForgetReference(). Let me know what you think, Armin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-14 15:36 Message: Logged In: YES user_id=6656 Yikes! ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 15:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Thu Jun 29 23:27:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 14:27:11 -0700 Subject: [ python-Bugs-1514685 ] radians() doesn't work correctly Message-ID: Bugs item #1514685, was opened at 2006-06-29 21:27 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=1514685&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: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: radians() doesn't work correctly Initial Comment: >>> from turtle import * >>> left(90) >>> heading() 90.0 >>> radians() >>> heading() 90.0 # should give pi/2, i.e. 1.5707... >>> forward(50) # turtle goes in direction 90 rad # i.e. approx. 116.62 degrees ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&group_id=5470 From noreply at sourceforge.net Thu Jun 29 23:28:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 14:28:45 -0700 Subject: [ python-Bugs-1514685 ] radians() doesn't work correctly Message-ID: Bugs item #1514685, was opened at 2006-06-29 21:27 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&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: 7 Submitted By: Lingl (gregorlingl) >Assigned to: Martin v. L??wis (loewis) Summary: radians() doesn't work correctly Initial Comment: >>> from turtle import * >>> left(90) >>> heading() 90.0 >>> radians() >>> heading() 90.0 # should give pi/2, i.e. 1.5707... >>> forward(50) # turtle goes in direction 90 rad # i.e. approx. 116.62 degrees ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514685&group_id=5470 From noreply at sourceforge.net Thu Jun 29 23:29:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 14:29:01 -0700 Subject: [ python-Bugs-1513802 ] __del__: Type is cleared before instances Message-ID: Bugs item #1513802, was opened at 2006-06-28 07:41 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&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: Arun (arunarunarun) Assigned to: Nobody/Anonymous (nobody) Summary: __del__: Type is cleared before instances Initial Comment: [Python n00b alert] I'm trying this little script, and I see an exception like: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'refcount'" in ignored If I change the variable name 's1' to something like 's4', I don't see this exception. Also, if I manually delete the object before the script ends, the exception does not occur. Seems that class Shape is destroyed before all it's objects are destroyed. Is this acceptable? ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-29 21:29 Message: Logged In: YES user_id=4771 It is not the type object that is cleared, it is the global names of the module. They are replaced with None when the interpreter shuts down, which is why the expression 'Shape.refcount' find None under the name 'Shape'. It's an obscure leftover for historical reasons. I'm not sure why the problem somes bites and sometimes not. A workaround is to avoid reading globals from __del__() methods; e.g. use self.__class__.refcount instead of Shape.refcount... (This of course doesn't excuse the fact that this is a long-standing bug.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513802&group_id=5470 From noreply at sourceforge.net Thu Jun 29 23:39:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 14:39:27 -0700 Subject: [ python-Bugs-1514693 ] circle doesn't work correctly after radians() Message-ID: Bugs item #1514693, was opened at 2006-06-29 21:38 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514693&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: 7 Submitted By: Lingl (gregorlingl) >Assigned to: Martin v. L??wis (loewis) Summary: circle doesn't work correctly after radians() Initial Comment: >>> from turtle import * >>> radians() >>> circle(100,pi/2) # turtle doesn't draw >>> degrees() >>> circle(100,90) # turtle draws again, but goes # in the wrong direction You must see it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514693&group_id=5470 From noreply at sourceforge.net Thu Jun 29 23:46:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 14:46:40 -0700 Subject: [ python-Bugs-1514703 ] setup in Pen.__init__() Message-ID: Bugs item #1514703, was opened at 2006-06-29 21:46 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=1514703&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: 5 Submitted By: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: setup in Pen.__init__() Initial Comment: Each time a Pen is constructed, the graphics window is resized and recenter (if position or size was changed before by the user). I think a call of a window-oriented function doesn't belong in the Pen-cunstructor. Must somehow be called separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514703&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:14:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:14:35 -0700 Subject: [ python-Bugs-1514725 ] turtle.py: setup() call in Pen.__init__() Message-ID: Bugs item #1514725, was opened at 2006-06-29 22:14 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=1514725&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: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: turtle.py: setup() call in Pen.__init__() Initial Comment: Each time a Pen is constructed, the graphcis window gets resized and recenter (restored to ist's initial state) if the user had changed that state. I think a window-oriented function call doesn't belong into the Pen-constructor Must be called somewhere else ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:17:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:17:26 -0700 Subject: [ python-Bugs-1514725 ] turtle.py: setup() call in Pen.__init__() Message-ID: Bugs item #1514725, was opened at 2006-06-29 22:14 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&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: Duplicate >Priority: 1 Submitted By: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: turtle.py: setup() call in Pen.__init__() Initial Comment: Each time a Pen is constructed, the graphcis window gets resized and recenter (restored to ist's initial state) if the user had changed that state. I think a window-oriented function call doesn't belong into the Pen-constructor Must be called somewhere else ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514725&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:24:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:24:06 -0700 Subject: [ python-Bugs-1514730 ] turtle.py docs out of date Message-ID: Bugs item #1514730, was opened at 2006-06-29 22:24 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=1514730&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: 5 Submitted By: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: turtle.py docs out of date Initial Comment: Python Docs / Global Module Index / turtle(Tk) has simply not been updated to Vern Ceders revision and is way out of date many functions like position(), heading(), setheading(), begin_fill(), end_fill() and more are not mentioned. Also class Turte is not mentioned ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:24:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:24:59 -0700 Subject: [ python-Bugs-1514730 ] turtle.py docs out of date Message-ID: Bugs item #1514730, was opened at 2006-06-29 22:24 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&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: Lingl (gregorlingl) >Assigned to: Martin v. L??wis (loewis) Summary: turtle.py docs out of date Initial Comment: Python Docs / Global Module Index / turtle(Tk) has simply not been updated to Vern Ceders revision and is way out of date many functions like position(), heading(), setheading(), begin_fill(), end_fill() and more are not mentioned. Also class Turte is not mentioned ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514730&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:32:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:32:42 -0700 Subject: [ python-Bugs-1514734 ] site.py can break the location of the python library Message-ID: Bugs item #1514734, was opened at 2006-06-29 17:32 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=1514734&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: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: site.py can break the location of the python library Initial Comment: Given a sufficiently bizarre(*) set of symlinks on a posix system, site.py will change the directories in sys.path in such a way that they will no longer refer to valid directories. In the following. os.path refers to the posixpath file. The root of the problem is that site.makepath invokes os.path.abspath on it's paths, which calls os.path.normpath. os.path.normpath assumes that changing "foo/bar/../baz" to "foo/baz". This isn't true if bar is a symlink to somewhere where ../baz exists, but foo/baz doesn't. The simple fix is to make site.py call os.path.realpath on the path before calling os.path.abspath. This may not be the best fix. Possibly os.path.abspath should call realpath instead of normpath. Maybe normpath should check for symlinks and deal with them, effectively making it an alias for realpath. However, those both change the behavior of library functions, which may not be desirable. Here's a patch for site.py that fixes the problem: --- site.py Thu Jun 29 18:14:08 2006 +++ site-fixed.py Thu Jun 29 18:13:57 2006 @@ -63,7 +63,7 @@ def makepath(*paths): - dir = os.path.abspath(os.path.join(*paths)) + dir = os.path.abspath(os.path.realpath(os.path.join(*paths))) return dir, os.path.normcase(dir) def abs__file__(): *) Python is invoked as /cm/tools/bin/python. That's a symlink to ../../paks/Python-2.4.3/bin/python, and the library is in ../../paks/Python-2.4.3/lib. /cm/tools/bin is a symlink to /cm/tools/apps/bin. /cm/tools is a symlink to /opt/local/cmtools. Changing that relative symlink to an absolute one fixes the problem, but violates installation guidelines. Trying to recreate this without all three symlnks in place inevitably fails to reproduce the problem. And no, I didn't create this. I just diagnosed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514734&group_id=5470 From noreply at sourceforge.net Fri Jun 30 02:59:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 17:59:51 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 13:05 Message generated for change (Comment added) made by illume You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Faik Uygur (faik) Assigned to: Neal Norwitz (nnorwitz) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 00:59 Message: Logged In: YES user_id=2042 Py_INCREF should check for NULL with an assert. All uses of va_arg should be checked to see if they return NULL... and handle error codes! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-28 06:39 Message: Logged In: YES user_id=33168 I'm impatient and think this fixes the problem. So I'm closing this report. Please re-open if the patch didn't fix your problem. (I checked in something slightly different that the patch attached.) Committed revision 47139. Committed revision 47140. (2.4) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-28 06:09 Message: Logged In: YES user_id=33168 Faik, can you see if the attached patch fixes this problem. I believe it should. I can't reproduce the problem with the patch. ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-27 08:12 Message: Logged In: YES user_id=1541018 Back trace: #0 PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149 #1 0xa7b92024 in Instance_New (cls=0xa7bba064, args=0xa7c1a43c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637 #2 0xa7b93798 in load (self=0xa7c0a80c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389 #3 0xa7b953c8 in cpm_loads (self=0x0, args=0x0) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481 #4 0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108 #5 0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at Python/ceval.c:3563 #6 0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, closure=0x0) at Python/ceval.c:2736 #7 0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at Python/ceval.c:484 #8 0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, globals=0x0, locals=0x0, flags=0x0) at Python/pythonrun.c:1265 #9 0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:860 #10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:664 #11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at Modules/main.c:493 #12 0x0804867a in main (argc=0x0, argv=0x0) at Modules/python.c:23 ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-26 14:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Fri Jun 30 03:14:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 18:14:23 -0700 Subject: [ python-Bugs-1303614 ] Bypassing __dict__ readonlyness Message-ID: Bugs item #1303614, was opened at 2005-09-24 16:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-29 18:14 Message: Logged In: YES user_id=357491 OK, then I am going to need a little guidance to dive into this more since this is going into some murky waters for me. =) For the normal, non-evil case of an empty Python class (``class Foo(object): pass``), I would think that accessing __dict__ would fall through to the tp_getset for object, and then fall to the same slot for type. Now that is obviously not happening since you get a straight dict back for that attribute access and not a dict proxy as would be suggested based on my logic listed above. So, my question is, where is the code that handles fetching Foo().__dict__? And if you have an inkling of where I should be looking in terms of possible refcounting additions that would be great as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-29 14:19 Message: Logged In: YES user_id=4771 Brett: I think you're approaching the problem from the wrong angle. The problem is being allowed to freely tamper with the dict stored in objects. Getting NULL errors here and there is only a symptom. As I explain, the '__dict__' descriptor object needs to do some more checks, and to be fully safe some Py_INCREF/Py_DECREF are needed in some critical places. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:45 Message: Logged In: YES user_id=357491 For the deldict.py crasher, if you look at the traceback there is no good place to do a check that tp_dict is sane except in type_module() or PyDict_GetItem(). Now adding the NULL check in type_module() will fix this specific problem, but that seems like an ad-hoc patch. Why don't we check for NULL in PyDict_GetItem() and return NULL just like the PyDict_Check() test? I am sure the answer is "performance", but this is not PyDict_GETITEM()and thus already is not the performance-critical version anyway. So why shouldn't we check for NULL there and possibly catch other errors? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:41 Message: Logged In: YES user_id=357491 Simple patch for the loosing_dict_ref.py crasher is attached. Just checked for possible NULL values in what is needed by _Py_ForgetReference(). Let me know what you think, Armin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-14 07:36 Message: Logged In: YES user_id=6656 Yikes! ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 07:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 06:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-25 01:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 From noreply at sourceforge.net Fri Jun 30 03:19:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 18:19:38 -0700 Subject: [ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard Message-ID: Bugs item #1512695, was opened at 2006-06-26 06:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&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: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Faik Uygur (faik) Assigned to: Neal Norwitz (nnorwitz) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-29 18:19 Message: Logged In: YES user_id=33168 Rene can you produce a patch to address any places you believe there are problems? If you can't produce a patch, at least a bug report with specific areas that are problems would be helpful. Thanks. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-29 17:59 Message: Logged In: YES user_id=2042 Py_INCREF should check for NULL with an assert. All uses of va_arg should be checked to see if they return NULL... and handle error codes! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 23:39 Message: Logged In: YES user_id=33168 I'm impatient and think this fixes the problem. So I'm closing this report. Please re-open if the patch didn't fix your problem. (I checked in something slightly different that the patch attached.) Committed revision 47139. Committed revision 47140. (2.4) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 23:09 Message: Logged In: YES user_id=33168 Faik, can you see if the attached patch fixes this problem. I believe it should. I can't reproduce the problem with the patch. ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-27 01:12 Message: Logged In: YES user_id=1541018 Back trace: #0 PyTuple_Pack (n=0x3) at Objects/tupleobject.c:149 #1 0xa7b92024 in Instance_New (cls=0xa7bba064, args=0xa7c1a43c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:3637 #2 0xa7b93798 in load (self=0xa7c0a80c) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:4389 #3 0xa7b953c8 in cpm_loads (self=0x0, args=0x0) at /var/tmp/pisi/python-2.4.3-14/work/Python-2.4.3/Modules/cPickle.c:5481 #4 0xa7ec4d97 in PyCFunction_Call (func=0xa7bc9b0c, arg=0xa7bc9cec, kw=0x0) at Objects/methodobject.c:108 #5 0xa7efe3d8 in PyEval_EvalFrame (f=0x807e4bc) at Python/ceval.c:3563 #6 0xa7f00bb3 in PyEval_EvalCodeEx (co=0xa7bbda60, globals=0x0, locals=0x0, args=0xa7bbda60, argcount=0x0, kws=0x0, kwcount=0x0, defs=0x0, defcount=0x0, closure=0x0) at Python/ceval.c:2736 #7 0xa7f00e35 in PyEval_EvalCode (co=0x0, globals=0x0, locals=0x0) at Python/ceval.c:484 #8 0xa7f1ba98 in run_node (n=0xa7bfbe18, filename=0x0, globals=0x0, locals=0x0, flags=0x0) at Python/pythonrun.c:1265 #9 0xa7f1ce28 in PyRun_SimpleFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:860 #10 0xa7f1d9aa in PyRun_AnyFileExFlags (fp=0x804a008, filename=0xaf9ab3b9 "picklefault.py", closeit=0x1, flags=0xaf9aafe8) at Python/pythonrun.c:664 #11 0xa7f238d0 in Py_Main (argc=0x1, argv=0xaf9aafe8) at Modules/main.c:493 #12 0x0804867a in main (argc=0x0, argv=0x0) at Modules/python.c:23 ---------------------------------------------------------------------- Comment By: Faik Uygur (faik) Date: 2006-06-26 07:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512695&group_id=5470 From noreply at sourceforge.net Fri Jun 30 03:33:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 18:33:12 -0700 Subject: [ python-Bugs-1296433 ] expat crash python Message-ID: Bugs item #1296433, was opened at 2005-09-20 07:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Mike Rozhnov (rozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: expat crash python Initial Comment: This simple script crash python. Parsing of commented xml string work good. (i.e. raised exception not crash python) Buffer overflow during convertion to unicode? Tested on Win XP and linux with kernel 2.4 with same results. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-29 18:33 Message: Logged In: YES user_id=357491 Still seems to be failing even with the Expat 2.0 upgrade in HEAD. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-12 12:53 Message: Logged In: YES user_id=33168 I had recently upgraded to expat 1.95.8, so I was hopeful. But it still crashed for me on linux. I did get a better stack trace which allowed me to come up with a patch that solves the problem and passes all the tests. The patch seems a bit odd and I think there might be another problem going on here. It would be great if someone more familiar with xmlparse could take a look at the patch and figure out if it's right or not. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 03:05 Message: Logged In: YES user_id=38376 Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with expat 1.95.8). Try upgrading your expat and see if the problem goes away. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 14:54 Message: Logged In: YES user_id=33168 I can reproduce on Linux with current CVS and expat 1.95.5-2. Note the size of the data only needs to be greater than 1024. xml = "%s" % ('a' * 1025) I am not certain this problem is specific to Python. It might be down in expat only. Need to investigate further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 From noreply at sourceforge.net Fri Jun 30 06:40:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 21:40:57 -0700 Subject: [ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure Message-ID: Bugs item #1510984, was opened at 2006-06-23 00:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&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: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 06:40 Message: Logged In: YES user_id=21627 The alpha installers are at http://www.python.org/ftp/python/2.5/prev/ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-29 22:21 Message: Logged In: YES user_id=764593 I can no longer locate the alpha installers, but I'll see if I can reproduce it with the beta installer plus a 2.4 version. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-29 20:59 Message: Logged In: YES user_id=21627 I could not reproduce the problem. Can you please try to reproduce it, installing things in the order you did? Please provide all details, such as sequence of MSI invocations, options selected, reboots/logouts performed, etc. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 17:39 Message: Logged In: YES user_id=764593 All versions are binary downloads for windows, from python.org I have a 2.4, which seems not to be relevant. I don't remember whether I had installed 2.5a1, though I think so. If I had, it was successfully overwritten by 2.5a2. I had definately installed 2.5a2. The problem came when I attempted to install 2.5b1 on top of 2.5a2. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-24 12:28 Message: Logged In: YES user_id=21627 Can you please give a precise reference to what you've downloaded? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 From noreply at sourceforge.net Fri Jun 30 09:12:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 00:12:25 -0700 Subject: [ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows Message-ID: Bugs item #1513646, was opened at 2006-06-27 15:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Yi S. Ding (yi_ding) Assigned to: Martin v. L??wis (loewis) Summary: os.access reports incorrect write permissions in Windows Initial Comment: Platform: Python 2.5b1 Windows XP Bug: os.access will report that a user doesn't have write permissions to a file or directory when the user actually does. Reproducibility: always This is being run on an administrator account. >>> import os >>> os.access("C:\\", os.W_OK) False >>> os.access("C:\\test.txt", os.W_OK) False I have also checked that Python can indeed write to the file. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 00:12 Message: Logged In: YES user_id=33168 Your change looks correct, but I would really like a test case to fix this problem. I don't have access to a Windows box, so I can't verify the test fails before this patch and succeeds with it. Can you create a test case too? The best place to add the test would be Lib/test/test_posix.py. Thanks! ---------------------------------------------------------------------- Comment By: Yi S. Ding (yi_ding) Date: 2006-06-29 12:56 Message: Logged In: YES user_id=1081617 Yeah, it's only 2.5, and only 2.5b1. Basically, there's a double ampersand used instead of a single ampersand in posixmodule.c. I've attached the patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 22:28 Message: Logged In: YES user_id=33168 Does this problem only occur with 2.5 or is it also present in 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470 From noreply at sourceforge.net Fri Jun 30 09:14:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 00:14:43 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-30 07:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 19:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 09:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 21:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 20:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 20:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 20:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 19:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 20:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 12:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 13:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 13:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 13:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 07:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri Jun 30 09:14:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 00:14:46 -0700 Subject: [ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed Message-ID: Bugs item #1483133, was opened at 2006-05-06 14:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&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: 8 Submitted By: svensoho (svensoho) Assigned to: Phillip J. Eby (pje) Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=33168 Does this affect 2.5 or only 2.4? There were a fair amount of generator changes in 2.5. ---------------------------------------------------------------------- Comment By: svensoho (svensoho) Date: 2006-05-26 07:42 Message: Logged In: YES user_id=1518209 This bug is blocking development of PostgreSQL Python based stored procedure language -- PL/Python. See http://archives.postgresql.org/pgsql-patches/2006-04/msg 00265.php ---------------------------------------------------------------------- Comment By: svensoho (svensoho) Date: 2006-05-15 01:26 Message: Logged In: YES user_id=1518209 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 From noreply at sourceforge.net Fri Jun 30 09:35:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 00:35:35 -0700 Subject: [ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed Message-ID: Bugs item #1483133, was opened at 2006-05-07 00:09 Message generated for change (Comment added) made by svensoho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&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: 8 Submitted By: svensoho (svensoho) Assigned to: Phillip J. Eby (pje) Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) ---------------------------------------------------------------------- >Comment By: svensoho (svensoho) Date: 2006-06-30 10:35 Message: Logged In: YES user_id=1518209 2.5 is already fixed: http://sourceforge.net/tracker/ index.php?func=detail&aid=1257960&group_id=5470&atid=105470 2.4 has exactly same problematic assertion, even same modification helps. Fedora has fixed it in their distribution: https://bugzilla.redhat.com/bugzilla/ show_bug.cgi?id=192592 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 10:14 Message: Logged In: YES user_id=33168 Does this affect 2.5 or only 2.4? There were a fair amount of generator changes in 2.5. ---------------------------------------------------------------------- Comment By: svensoho (svensoho) Date: 2006-05-26 17:42 Message: Logged In: YES user_id=1518209 This bug is blocking development of PostgreSQL Python based stored procedure language -- PL/Python. See http://archives.postgresql.org/pgsql-patches/2006-04/msg 00265.php ---------------------------------------------------------------------- Comment By: svensoho (svensoho) Date: 2006-05-15 11:26 Message: Logged In: YES user_id=1518209 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 From noreply at sourceforge.net Fri Jun 30 15:55:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 06:55:27 -0700 Subject: [ python-Bugs-1515142 ] sgmllib should recover from unmatched quotes Message-ID: Bugs item #1515142, was opened at 2006-06-30 09:55 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=1515142&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: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib should recover from unmatched quotes Initial Comment: The good news is that previous fixes enable some of the previously disabled tests to be The one regression I have noticed is that sgmllib no longer recovers gracefully from broken start tags. This patch restores the prior behavior when faced with such constructs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515142&group_id=5470 From noreply at sourceforge.net Fri Jun 30 16:34:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 07:34:27 -0700 Subject: [ python-Bugs-1515163 ] traceback now masks some string exceptions Message-ID: Bugs item #1515163, was opened at 2006-06-30 10:34 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=1515163&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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: traceback now masks some string exceptions Initial Comment: With 2.5, exceptions became new-style. Unfortunately, the traceback module wasn't fully updated to still properly handle all (admittedly deprecated) string exceptions. I noticed this because of its affect on unittest, where the original exception was masked. Under 2.4.3: >>> import traceback >>> traceback.format_exception_only("strtype", "strvalue") ['strtype: strvalue\n'] Under 2.5b1: >>> import traceback >>> traceback.format_exception_only("strtype", "strvalue") Traceback (most recent call last): File "", line 1, in traceback.format_exception_only("strtype", "strvalue") File "C:\Python25\lib\traceback.py", line 168, in format_exception_only if issubclass(etype, SyntaxError): TypeError: issubclass() arg 1 must be a class I will also be entering a patch, but know that we need a bug number at this stage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515163&group_id=5470 From noreply at sourceforge.net Fri Jun 30 16:36:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 07:36:26 -0700 Subject: [ python-Bugs-1515164 ] version says beta Message-ID: Bugs item #1515164, was opened at 2006-06-30 10:36 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=1515164&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: version says beta Initial Comment: The IDLE version in 2.5b1 has been updated to IDLE 1.2b1 It should be a non-beta number by the time of release, to avoid problems like we recently had with the logging module, where is seems less stable than it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515164&group_id=5470 From noreply at sourceforge.net Fri Jun 30 16:42:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 07:42:56 -0700 Subject: [ python-Bugs-1515169 ] ImportWarning should be removed Message-ID: Bugs item #1515169, was opened at 2006-06-30 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=1515169&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: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: ImportWarning should be removed Initial Comment: As discussed in email thread: http://www.gossamer-threads.com/lists/python/dev/497487 In particular, there are three specific reasons for not having it. I expect these reasons to translate to a larger number of specific reasons as more people use python 2.5. 1) Ralf's software gets a flood of ImportWarnings 2) Twisted's plugin system uses a directory named "twisted" without an __init__.py in it on the python path to store plugins in. Therefore, anybody running (importing) twisted will produce annoying warnings. 3) I have a directory in my homedir called "readline". Quoted from my email: I just found another reason to dislike the warnings: my homedir on one machine has a lot of random directories in it. One of them is named "readline". Every time I run python 2.5, it now helpfully notes: sys:1: ImportWarning: Not importing directory 'readline': missing __init__.py It used to be the case that it was very unlikely that running python in your homedir would cause issues. Even though the current directory is on the default pythonpath, you needed to have either a file ending in .py or a directory with an __init__.py with the same name as a python module to cause problems. And that is generally unlikely to happen. Now, however, you get warnings just by having _any_ directory in your CWD with the same name as a python module. That's much more likely to happen; I can't be the only one who will have this issue. Suggested solution: Remove ImportWarning, and make the ImportError message say: >> ImportError: No module named mypackage.foo >> Note that subdirectories are searched for imports only if they contain an >> __init__.py file: http://www.python.org/doc/essays/packages.html I really think this should be addressed before 2.5 is released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515169&group_id=5470 From noreply at sourceforge.net Fri Jun 30 18:22:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 09:22:13 -0700 Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation Message-ID: Bugs item #1501934, was opened at 2006-06-06 23:57 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Wouters (twouters) Assigned to: Jeremy Hylton (jhylton) Summary: incorrect LOAD/STORE_GLOBAL generation Initial Comment: Python 2.5 compiles the following piece of code differently than Python 2.4: g = 1 def f(): g += 1 In Python 2.4, this raises an UnboundLocalError. In current svn trunk, it will increment the global g by 1. (dis.dis shows that it actually compiles into LOAD/STORE_GLOBAL opcodes.) It seems the compiler doesn't treat augmented assignment as assignment for the purpose of determining locals, as this still fails correctly: g = 1 def f(): g += 1 g = 5 I can't find where this optimization happens nowadays, but it feels like a short fix. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2006-06-30 16:22 Message: Logged In: YES user_id=35752 Here are some notes in case I wear out before finding a fix. analyze_name() gets to the SET_SCOPE(dict, name, GLOBAL_IMPLICIT) line because the name does not have the DEF_LOCAL flag set as it should. It does not have DEF_LOCAL because Name.ctx for 'g' is Load. I believe there should be a set_context() call in ast_for_expr_stmt, as flagged as TODO by Jeremy. Maybe set_context(..., Store, ...) would work or maybe things need to be changed to allow ctx to have AugAssign as a value. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-06-19 17:44 Message: Logged In: YES user_id=34209 Possibly related is the discovery of free variables (used when forming closures) and optimized-out codeblocks: >>> def foo(x): ... def bar(): ... if 0: ... print x ... return bar In 2.4, there is no closure: >>> foo.func_code.co_cellvars () >>> foo(5).func_closure >>> In 2.5, there is: >>> foo.func_code.co_cellvars ('x',) >>> foo(5).func_closure (,) (I don't think it's unreasonable to declare the old behaviour bugged, though :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470 From noreply at sourceforge.net Fri Jun 30 18:48:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 09:48:18 -0700 Subject: [ python-Bugs-1515164 ] version says beta Message-ID: Bugs item #1515164, was opened at 2006-06-30 16:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515164&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: version says beta Initial Comment: The IDLE version in 2.5b1 has been updated to IDLE 1.2b1 It should be a non-beta number by the time of release, to avoid problems like we recently had with the logging module, where is seems less stable than it is. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 18:48 Message: Logged In: YES user_id=21627 What is the bug you are reporting? idlever.py is always changed in lockstep with the Python release version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515164&group_id=5470 From noreply at sourceforge.net Fri Jun 30 18:51:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 09:51:54 -0700 Subject: [ python-Bugs-1510172 ] Absolute/relative import not working? Message-ID: Bugs item #1510172, was opened at 2006-06-22 05:35 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&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: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-01 02:51 Message: Logged In: YES user_id=1038590 Patch attached that allows relative imports from a main module to work so long as: a. the top level package is either in the current directory or somewhere else on sys.path; and b. the module is executed using -m so Python knows where it fits in the package hierarchy So to get the PEP 328 example to work, you'd have to run it as: $python2.5 -m package.subpackage1.moduleX The patch relies on a feature added to runpy in rev 47142 (post beta 1). I've added a question to PEP 356 as to how this should be handled, since we're technically in feature freeze. Patch attached directly to the bug report because it's stupidly early in the morning and I don't feel like dealing with SF and then copying the patch tracker number here :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:46 Message: Logged In: YES user_id=1038590 All that said, PEP 328 currently says that "from ...sys import path" should be legal from moduleX in the example. I tried it, and it currently fails - the ValueError gets raised as soon as the number of dots in the relative path exceeds the number of dots in __name__, instead of treating a single excess dot as requesting an absolute import instead. (All of the other examples in the PEP work as specified when moduleX and subpackage1 are imported rather than executed directly) I believe fixing this would also fix Mitch's problem - an explicit relative import from __main__ would be treated as a top level import. I also have an idea regarding the -m switch that I will raise on python-dev. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:34 Message: Logged In: YES user_id=1038590 The issue isn't actually unique to the -m switch - the problem is that relative imports are based on __name__, and in the main module, __name__ always has the value '__main__'. Hence, relative imports currently can't work properly from the main module of an application, because the main module doesn't know where it really fits in the Python module namespace (this is at least fixable in theory for the main modules executed through the -m switch, but directly executed files and the interactive interpreter are completely out of luck). With the old implicit relative imports this behaviour is masked by the fact that executing a module puts that module's directory on sys.path. When you execute a module in a package directly, it actually imports its sibling modules as top-level modules. The fact that the -m switch doesn't allow this to occur is a deliberate design decision (putting package directories on the system level path is a bad idea because you can get multiple copies of the same module under different names). You should be able get something similar to the old implicit relative import behaviour by sticking the following at the top of your module (before doing any relative imports): if __name__ = '__main__': from os.path import dirname __path__ = [dirname(__file__)] del dirname This makes the relative import machinery treat your main module as a package. The problem with this workaround is that, just like the old situation with implicit relative imports from the main module, you may end up with two different copies of the sibling modules in sys.modules. One copy will be '__main__.foo' while the other will be 'package.foo' (with implicit relative imports, the first copy would have been a top level module called 'foo'). When I went to document this, I got stuck on the fact that section 6 of the tutorial hasn't been updated for PEP 328 at *all*. And the language ref palms the details off on to Guido's packages essay. So describing the limitation in the real documentation entails documenting PEP 328 properly in the first place (which I'm *not* volunteering to do :). However, I'll add a section to PEP 328 about '__main__' and relative imports (including the workaround to get something similar to the old behaviour back). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 14:41 Message: Logged In: YES user_id=33168 http://mail.python.org/pipermail/python-dev/2006-June/066197.html Nick you made mention of changing the docs, but I'm not sure if you did or not. Could you address this bug? Thanks. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-06-23 23:52 Message: Logged In: YES user_id=34209 See the discussion started at: http://mail.python.org/pipermail/python-dev/2006-June/066161.html It's not a bug in 328 or 338 (the PEP that adds the -m switch for packages), but in the interaction between the two. I don't think this will be fixed for 2.5, since there is no obvious fix. If it hurts when you press there, don't press there. Either don't use -m for packaged modules, or have the packaged module only use absolute imports. (But don't be surprised if the script-module is imported twice, once as __main__ and once as the module itself. That's a whole other bug/feature.) ---------------------------------------------------------------------- Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-22 09:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-22 08:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: >>> from package.subpackage1 import moduleX >>> moduleX.spam 'spam' ---------------------------------------------------------------------- Comment By: Mark Nottingham (mnot) Date: 2006-06-22 07:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 From noreply at sourceforge.net Fri Jun 30 19:06:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 10:06:58 -0700 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Brett Cannon (bcannon) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Fri Jun 30 19:51:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 10:51:29 -0700 Subject: [ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation Message-ID: Bugs item #1501934, was opened at 2006-06-06 23:57 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Wouters (twouters) Assigned to: Jeremy Hylton (jhylton) Summary: incorrect LOAD/STORE_GLOBAL generation Initial Comment: Python 2.5 compiles the following piece of code differently than Python 2.4: g = 1 def f(): g += 1 In Python 2.4, this raises an UnboundLocalError. In current svn trunk, it will increment the global g by 1. (dis.dis shows that it actually compiles into LOAD/STORE_GLOBAL opcodes.) It seems the compiler doesn't treat augmented assignment as assignment for the purpose of determining locals, as this still fails correctly: g = 1 def f(): g += 1 g = 5 I can't find where this optimization happens nowadays, but it feels like a short fix. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2006-06-30 17:51 Message: Logged In: YES user_id=35752 I've got a simple fix that seems to work. I feel this part of the compiler could use some more serious cleanups but probably not for 2.5. Note that test_ast fails after applying my patch. I haven't had time to look into that yet but I think it's shallow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-06-30 16:22 Message: Logged In: YES user_id=35752 Here are some notes in case I wear out before finding a fix. analyze_name() gets to the SET_SCOPE(dict, name, GLOBAL_IMPLICIT) line because the name does not have the DEF_LOCAL flag set as it should. It does not have DEF_LOCAL because Name.ctx for 'g' is Load. I believe there should be a set_context() call in ast_for_expr_stmt, as flagged as TODO by Jeremy. Maybe set_context(..., Store, ...) would work or maybe things need to be changed to allow ctx to have AugAssign as a value. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-06-19 17:44 Message: Logged In: YES user_id=34209 Possibly related is the discovery of free variables (used when forming closures) and optimized-out codeblocks: >>> def foo(x): ... def bar(): ... if 0: ... print x ... return bar In 2.4, there is no closure: >>> foo.func_code.co_cellvars () >>> foo(5).func_closure >>> In 2.5, there is: >>> foo.func_code.co_cellvars ('x',) >>> foo(5).func_closure (,) (I don't think it's unreasonable to declare the old behaviour bugged, though :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470 From noreply at sourceforge.net Fri Jun 30 20:06:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 11:06:09 -0700 Subject: [ python-Bugs-1296433 ] expat crash python Message-ID: Bugs item #1296433, was opened at 2005-09-20 07:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Mike Rozhnov (rozhnov) >Assigned to: Brett Cannon (bcannon) Summary: expat crash python Initial Comment: This simple script crash python. Parsing of commented xml string work good. (i.e. raised exception not crash python) Buffer overflow during convertion to unicode? Tested on Win XP and linux with kernel 2.4 with same results. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-30 11:06 Message: Logged In: YES user_id=357491 The fault is with Expat and not us. I have submitted a bug report with a possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=1515266&group_id=10127&atid=110127 . I don't know what their turn-around time will be with this so I will email python-dev to see how long people want to wait on the Expat developers before we just push our own patch for this. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 18:33 Message: Logged In: YES user_id=357491 Still seems to be failing even with the Expat 2.0 upgrade in HEAD. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-12 12:53 Message: Logged In: YES user_id=33168 I had recently upgraded to expat 1.95.8, so I was hopeful. But it still crashed for me on linux. I did get a better stack trace which allowed me to come up with a patch that solves the problem and passes all the tests. The patch seems a bit odd and I think there might be another problem going on here. It would be great if someone more familiar with xmlparse could take a look at the patch and figure out if it's right or not. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 03:05 Message: Logged In: YES user_id=38376 Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with expat 1.95.8). Try upgrading your expat and see if the problem goes away. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 14:54 Message: Logged In: YES user_id=33168 I can reproduce on Linux with current CVS and expat 1.95.5-2. Note the size of the data only needs to be greater than 1024. xml = "%s" % ('a' * 1025) I am not certain this problem is specific to Python. It might be down in expat only. Need to investigate further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470