From noreply at sourceforge.net Tue Feb 1 03:01:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 03:01:42 2005 Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh Message-ID: Bugs item #1108992, was opened at 2005-01-25 05:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 21:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 01:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 15:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 14:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 12:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 04:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 From noreply at sourceforge.net Tue Feb 1 03:53:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 03:53:21 2005 Subject: [ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc. Message-ID: Bugs item #1113244, was opened at 2005-01-31 11:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) >Assigned to: Tim Peters (tim_one) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 21:53 Message: Logged In: YES user_id=80475 Tim, what you think about doing this with a conditional compile to only redefine for GCC? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 From noreply at sourceforge.net Tue Feb 1 03:57:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 03:57:04 2005 Subject: [ python-Bugs-1100368 ] Wrong "type()" syntax in docs Message-ID: Bugs item #1100368, was opened at 2005-01-11 14:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) >Assigned to: Raymond Hettinger (rhettinger) Summary: Wrong "type()" syntax in docs Initial Comment: >From the current docs: type(object): Return the type of an object. The return value is a type object. >From the interpreter: >>> help(type) Help on class type in module __builtin__: class type(object) | type(object) -> the object's type | type(name, bases, dict) -> a new type In the documentation is missing the second syntax form. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-01-25 16:31 Message: Logged In: YES user_id=99874 cjwhrh's comment doesn't seem relevent. It is generally true of ALL builtins that they can be shadowed by local variables. Facundo is probably right that the newer use of type() should be documented. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-18 17:03 Message: Logged In: YES user_id=285587 The accuracy of the above depends partly on the context. Within a function or method which has "type" as a parameter the type function described above is no longer accessible. Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 From noreply at sourceforge.net Tue Feb 1 04:03:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 04:03:43 2005 Subject: [ python-Bugs-1109523 ] Time module missing from latest module index Message-ID: Bugs item #1109523, was opened at 2005-01-25 20:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Time module missing from latest module index Initial Comment: There is no time module listed here: http://www.python.org/dev/doc/devel/modindex.html and fabricating a likely URL 404s. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 22:03 Message: Logged In: YES user_id=80475 Hmm, I see a time module (just after threading) and it successfully points to http://www.python.org/dev/doc/devel/lib/module-time.html . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 From noreply at sourceforge.net Tue Feb 1 04:36:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 04:36:11 2005 Subject: [ python-Bugs-1109523 ] Time module missing from latest module index Message-ID: Bugs item #1109523, was opened at 2005-01-25 19:20 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Time module missing from latest module index Initial Comment: There is no time module listed here: http://www.python.org/dev/doc/devel/modindex.html and fabricating a likely URL 404s. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-01-31 21:36 Message: Logged In: YES user_id=44345 I sent a message to the doc sig about it a couple weeks ago. After not getting a response for awhile I submitted this report. Fred fixed the problem but probably never noticed the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 21:03 Message: Logged In: YES user_id=80475 Hmm, I see a time module (just after threading) and it successfully points to http://www.python.org/dev/doc/devel/lib/module-time.html . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 From noreply at sourceforge.net Tue Feb 1 08:53:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 08:54:00 2005 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 05:13 Message generated for change (Comment added) made by bos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-01-31 23:53 Message: Logged In: YES user_id=28380 I've been bitten by the same bug. In my case, the problem was with Qt, not GTK. It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything. Here's the patch I use for this problem: --- python/Modules/pyexpat.c 2005-01-06 16:26:13 -08:00 +++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00 @@ -1936,9 +1936,12 @@ } #endif -#define MYCONST(name) - PyModule_AddStringConstant(errors_module, #name, - (char*)XML_ErrorString(name)) +#define MYCONST(name) + { + char *_v = (char*)XML_ErrorString(name); + if (_v) + PyModule_AddStringConstant(errors_module, #name, _v); + } MYCONST(XML_ERROR_NO_MEMORY); MYCONST(XML_ERROR_SYNTAX); ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 05:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 05:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 01:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 09:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 08:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 08:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Tue Feb 1 10:51:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 10:51:11 2005 Subject: [ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc. Message-ID: Bugs item #1113244, was opened at 2005-01-31 16:01 Message generated for change (Comment added) made by rjk1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) Assigned to: Tim Peters (tim_one) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. ---------------------------------------------------------------------- >Comment By: Richard Kettlewell (rjk1002) Date: 2005-02-01 09:51 Message: Logged In: YES user_id=217390 Making it compiler-specific seems silly. It's not like the do-while idiom for macros is some strange gcc-specific thing; most people just use it unconditionally on complicated macros. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 02:53 Message: Logged In: YES user_id=80475 Tim, what you think about doing this with a conditional compile to only redefine for GCC? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 From noreply at sourceforge.net Tue Feb 1 14:35:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 14:35:49 2005 Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh Message-ID: Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark ---------------------------------------------------------------------- >Comment By: Mark Poolman (mgpoolman) Date: 2005-02-01 13:35 Message: Logged In: YES user_id=993923 > So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. That is correct. The problem appears exactly the same when run over ssh though, which, I guess rules out any gnome/metacity/X wierdness. > I suspect a hardware problem I' sceptical about that. There's nothing in dmesg or /var/log to suggest it, and absolutely no other problems with the machine in question. >Are you starting IDLE from the command line Yes, but no messages are shown. > How much memory 255MB, IDLE uses about 3.5% of that on startup, grew to 5.7% at time of last crash ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-01 02:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 06:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 20:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 19:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 09:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 From noreply at sourceforge.net Tue Feb 1 14:47:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 14:47:29 2005 Subject: [ python-Bugs-1113984 ] keywords in keyword_arguments not possible Message-ID: Bugs item #1113984, was opened at 2005-02-01 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: keywords in keyword_arguments not possible Initial Comment: Currently it is not possible to use keywords in expressions of the type "keyword_arguments". Example: d = {'fi': 1, 'if': 1} d.update(fi = 2) # ok d.update(if = 2) # error If possible, this restriction should be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 From noreply at sourceforge.net Tue Feb 1 17:13:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 17:13:21 2005 Subject: [ python-Bugs-1114093 ] inicode.decode Message-ID: Bugs item #1114093, was opened at 2005-02-01 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=1114093&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: M.-A. Lemburg (lemburg) Summary: inicode.decode Initial Comment: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 >>> print sys.getdefaultencoding() ascii Regards. The problem is this code: # -*- coding: cp1252 -*- >>> u'\xe0\xe8\xec\xf2\xf9'.decode('latin1') Traceback (most recent call last): File "", line 1, in ? u'\xe0\xe8\xec\xf2\xf9'.decode('latin1') UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128) I think this is a bug. Indeed this is the behaviour of str.encode: >>> '\xe0\xe8\xec\xf2\xf9'.encode('latin1') Traceback (most recent call last): File "", line 1, in ? '\xe0\xe8\xec\xf2\xf9'.encode('latin1') UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128) But this makes no sense for Unicode strings! I think unicode.decode should be a no-op. Manlio Perillo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114093&group_id=5470 From noreply at sourceforge.net Tue Feb 1 18:23:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 18:23:39 2005 Subject: [ python-Bugs-1114093 ] unicode.decode Message-ID: Bugs item #1114093, was opened at 2005-02-01 17:13 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114093&group_id=5470 Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: M.-A. Lemburg (lemburg) >Summary: unicode.decode Initial Comment: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 >>> print sys.getdefaultencoding() ascii Regards. The problem is this code: # -*- coding: cp1252 -*- >>> u'\xe0\xe8\xec\xf2\xf9'.decode('latin1') Traceback (most recent call last): File "", line 1, in ? u'\xe0\xe8\xec\xf2\xf9'.decode('latin1') UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128) I think this is a bug. Indeed this is the behaviour of str.encode: >>> '\xe0\xe8\xec\xf2\xf9'.encode('latin1') Traceback (most recent call last): File "", line 1, in ? '\xe0\xe8\xec\xf2\xf9'.encode('latin1') UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128) But this makes no sense for Unicode strings! I think unicode.decode should be a no-op. Manlio Perillo ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-01 18:23 Message: Logged In: YES user_id=38388 What the .encode() and .decode() methods do depends on the codec being used. In your example, the Latin-1 codec is used which is a codec that encodes from Unicode to 8-bit character strings and decodes the other way around. As a result the Unicode string in your first example is first converted to an 8-bit string using the default encoding (which is ASCII) and this fails. Same in the second case: Python tries to convert the 8-bit string to Unicode but this fails since the string contains non-ASCII characters. If you switch the types of the strings in both examples, you'll have no problem at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114093&group_id=5470 From noreply at sourceforge.net Tue Feb 1 18:46:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 18:46:58 2005 Subject: [ python-Bugs-1113984 ] keywords in keyword_arguments not possible Message-ID: Bugs item #1113984, was opened at 2005-02-01 08:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: keywords in keyword_arguments not possible Initial Comment: Currently it is not possible to use keywords in expressions of the type "keyword_arguments". Example: d = {'fi': 1, 'if': 1} d.update(fi = 2) # ok d.update(if = 2) # error If possible, this restriction should be removed. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 12:46 Message: Logged In: YES user_id=80475 It's possible, but hard to implement and unwise in any case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 From noreply at sourceforge.net Tue Feb 1 19:49:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 19:49:15 2005 Subject: [ python-Bugs-1113984 ] keywords in keyword_arguments not possible Message-ID: Bugs item #1113984, was opened at 2005-02-01 14:47 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: keywords in keyword_arguments not possible Initial Comment: Currently it is not possible to use keywords in expressions of the type "keyword_arguments". Example: d = {'fi': 1, 'if': 1} d.update(fi = 2) # ok d.update(if = 2) # error If possible, this restriction should be removed. ---------------------------------------------------------------------- >Comment By: Christoph Zwerschke (cito) Date: 2005-02-01 19:49 Message: Logged In: YES user_id=193957 Maybe I should explain my motivation for making this request. In Kid [http://kid-template.sf.net], a xml templating language, it is possible to set xml attributes with a Pythonic syntax, like this:

This expression is dynamically evaluated. If myclass="aclass" and bgcolor="blue", then this would produce the following:

Internally, this is of course realized by creating a dictionary that contains the attributes of the tag, and then creating an update statement with the string in py:attrs as argument. The problem arises when one of the attributes is a Python keyword, "class" being a particularly embarassing example. My current solution is to parse the py:attrs expression manually and mangle the names. If Python could handle Python keywords here, it would be a whole lot easier and faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 18:46 Message: Logged In: YES user_id=80475 It's possible, but hard to implement and unwise in any case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 From noreply at sourceforge.net Tue Feb 1 21:13:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 21:13:58 2005 Subject: [ python-Bugs-1113984 ] keywords in keyword_arguments not possible Message-ID: Bugs item #1113984, was opened at 2005-02-01 08:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: keywords in keyword_arguments not possible Initial Comment: Currently it is not possible to use keywords in expressions of the type "keyword_arguments". Example: d = {'fi': 1, 'if': 1} d.update(fi = 2) # ok d.update(if = 2) # error If possible, this restriction should be removed. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 15:13 Message: Logged In: YES user_id=80475 I have no doubt that there are good use cases, your included. The two issues are that it would complicate the snot out of parsing (not a good thing) and that allowing keywords in non-keyword roles would throw-off many existing tools (esp. syntax highlighters). In addition, human eye parsing also suffers when keywords can be used in non-keyword roles. IOW, readability suffers. For your app, it is a reasonable solution to wrap your code with in preprocessing that converts keywords to non-keywords: s = s.replace('class=', '_class=') ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2005-02-01 13:49 Message: Logged In: YES user_id=193957 Maybe I should explain my motivation for making this request. In Kid [http://kid-template.sf.net], a xml templating language, it is possible to set xml attributes with a Pythonic syntax, like this:

This expression is dynamically evaluated. If myclass="aclass" and bgcolor="blue", then this would produce the following:

Internally, this is of course realized by creating a dictionary that contains the attributes of the tag, and then creating an update statement with the string in py:attrs as argument. The problem arises when one of the attributes is a Python keyword, "class" being a particularly embarassing example. My current solution is to parse the py:attrs expression manually and mangle the names. If Python could handle Python keywords here, it would be a whole lot easier and faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 12:46 Message: Logged In: YES user_id=80475 It's possible, but hard to implement and unwise in any case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 From noreply at sourceforge.net Tue Feb 1 22:18:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 1 22:18:16 2005 Subject: [ python-Bugs-1113984 ] keywords in keyword_arguments not possible Message-ID: Bugs item #1113984, was opened at 2005-02-01 14:47 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: keywords in keyword_arguments not possible Initial Comment: Currently it is not possible to use keywords in expressions of the type "keyword_arguments". Example: d = {'fi': 1, 'if': 1} d.update(fi = 2) # ok d.update(if = 2) # error If possible, this restriction should be removed. ---------------------------------------------------------------------- >Comment By: Christoph Zwerschke (cito) Date: 2005-02-01 22:18 Message: Logged In: YES user_id=193957 Your argument about syntax highlighters is valid. s.replace('class=', '_class=') will not suffice, since 'class="aclass"' would be translated to 'class_=aclass_' which would fail because aclass_ is not defined. The only solution for me is to carefully parse the keyword_argument string using the tokenize module. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 21:13 Message: Logged In: YES user_id=80475 I have no doubt that there are good use cases, your included. The two issues are that it would complicate the snot out of parsing (not a good thing) and that allowing keywords in non-keyword roles would throw-off many existing tools (esp. syntax highlighters). In addition, human eye parsing also suffers when keywords can be used in non-keyword roles. IOW, readability suffers. For your app, it is a reasonable solution to wrap your code with in preprocessing that converts keywords to non-keywords: s = s.replace('class=', '_class=') ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2005-02-01 19:49 Message: Logged In: YES user_id=193957 Maybe I should explain my motivation for making this request. In Kid [http://kid-template.sf.net], a xml templating language, it is possible to set xml attributes with a Pythonic syntax, like this:

This expression is dynamically evaluated. If myclass="aclass" and bgcolor="blue", then this would produce the following:

Internally, this is of course realized by creating a dictionary that contains the attributes of the tag, and then creating an update statement with the string in py:attrs as argument. The problem arises when one of the attributes is a Python keyword, "class" being a particularly embarassing example. My current solution is to parse the py:attrs expression manually and mangle the names. If Python could handle Python keywords here, it would be a whole lot easier and faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 18:46 Message: Logged In: YES user_id=80475 It's possible, but hard to implement and unwise in any case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113984&group_id=5470 From noreply at sourceforge.net Wed Feb 2 02:27:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 02:27:30 2005 Subject: [ python-Feature Requests-1114404 ] All Statements Should Have Return Values (Syntax Proposal) Message-ID: Feature Requests item #1114404, was opened at 2005-02-01 20:27 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=1114404&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: All Statements Should Have Return Values (Syntax Proposal) Initial Comment: Python should allow a return value for some statements or blocks such as `print` or `def`. This should not always happen, but could certainly be useful. This can be used instead of lambdas when something more complex is required (the `def` example.) What seems to me to be the most natural syntax is to simply wrap the statement in parentheses. For example: >>> foo = (print 'bar') bar >>> foo 'bar' >>> f = (def f(x): if x < 0: return -5 return x ** 2 ) >>> f >>> # A useful example: >>> do_some_sort_of_logging( ( raise SomeSortOfError ) ) It will generally be obvious what should be returned, but why not be more explicit? Here are some loose specs: `def` would return the defined function. `class` would return the defined class. `print` would return the string representation of the printed object. `raise` will return the exception. `import` returns the module or a tuple of modules. This is not mean to be complete or a definitive syntax, but I'd certainly like this discussed and something along the lines of this proposal implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1114404&group_id=5470 From noreply at sourceforge.net Wed Feb 2 03:03:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 03:03:33 2005 Subject: [ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc. Message-ID: Bugs item #1113244, was opened at 2005-01-31 11:01 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) >Assigned to: Nobody/Anonymous (nobody) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-01 21:03 Message: Logged In: YES user_id=31435 rjk1002: it's idiotic complaints about unambigous (in reality) if/else structures that are unique to gcc. Not all compilers optimize away the "do {...} while(0)" cruft in debug builds; the most important examples for Python are the Microsoft compilers. Because the incref and decref macros are used a *lot*, it's unattractive to burden all platforms with this just to shut up one compiler. I don't care about Py_CLEAR() (etc), because they're so lightly used. The incref/decref macros are ubiquitous. I would much rather see SWIG change to insert curlies. That is, generating "if (newref) {Py_DECREF(obj);}" should be just as effective at shutting up this gcc nag. Has anyone asked the SWIG project to do this? ---------------------------------------------------------------------- Comment By: Richard Kettlewell (rjk1002) Date: 2005-02-01 04:51 Message: Logged In: YES user_id=217390 Making it compiler-specific seems silly. It's not like the do-while idiom for macros is some strange gcc-specific thing; most people just use it unconditionally on complicated macros. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 21:53 Message: Logged In: YES user_id=80475 Tim, what you think about doing this with a conditional compile to only redefine for GCC? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 From noreply at sourceforge.net Wed Feb 2 07:09:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 07:09:23 2005 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 05:13 Message generated for change (Comment added) made by bos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-01 22:09 Message: Logged In: YES user_id=28380 By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-01-31 23:53 Message: Logged In: YES user_id=28380 I've been bitten by the same bug. In my case, the problem was with Qt, not GTK. It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything. Here's the patch I use for this problem: --- python/Modules/pyexpat.c 2005-01-06 16:26:13 -08:00 +++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00 @@ -1936,9 +1936,12 @@ } #endif -#define MYCONST(name) - PyModule_AddStringConstant(errors_module, #name, - (char*)XML_ErrorString(name)) +#define MYCONST(name) + { + char *_v = (char*)XML_ErrorString(name); + if (_v) + PyModule_AddStringConstant(errors_module, #name, _v); + } MYCONST(XML_ERROR_NO_MEMORY); MYCONST(XML_ERROR_SYNTAX); ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 05:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 05:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 01:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 09:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 08:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 08:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Wed Feb 2 11:35:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 11:35:47 2005 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-02 10:35 Message: Logged In: YES user_id=6656 It's a nasty one, I'll give you that. Fred, what do you think of bos's patch? It solves the immediate issue, but I'm not sure it's a complete fix. It seems to me that it would be better to resolve the expat symbols at builf time, but I don't know how to arrange for that. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-02 06:09 Message: Logged In: YES user_id=28380 By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-01 07:53 Message: Logged In: YES user_id=28380 I've been bitten by the same bug. In my case, the problem was with Qt, not GTK. It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything. Here's the patch I use for this problem: --- python/Modules/pyexpat.c 2005-01-06 16:26:13 -08:00 +++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00 @@ -1936,9 +1936,12 @@ } #endif -#define MYCONST(name) - PyModule_AddStringConstant(errors_module, #name, - (char*)XML_ErrorString(name)) +#define MYCONST(name) + { + char *_v = (char*)XML_ErrorString(name); + if (_v) + PyModule_AddStringConstant(errors_module, #name, _v); + } MYCONST(XML_ERROR_NO_MEMORY); MYCONST(XML_ERROR_SYNTAX); ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 13:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 13:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 09:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 17:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 16:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Wed Feb 2 12:19:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 12:19:42 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-19 01:48 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-02-02 11:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 15:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Wed Feb 2 13:28:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 13:29:01 2005 Subject: [ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc. Message-ID: Bugs item #1113244, was opened at 2005-01-31 16:01 Message generated for change (Comment added) made by rjk1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) Assigned to: Nobody/Anonymous (nobody) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. ---------------------------------------------------------------------- >Comment By: Richard Kettlewell (rjk1002) Date: 2005-02-02 12:28 Message: Logged In: YES user_id=217390 It's unambiguous to the compiler. The warning is there because humans sometimes get it wrong. Marginally reduced optimization in a debug build is hardly a real problem. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-02 02:03 Message: Logged In: YES user_id=31435 rjk1002: it's idiotic complaints about unambigous (in reality) if/else structures that are unique to gcc. Not all compilers optimize away the "do {...} while(0)" cruft in debug builds; the most important examples for Python are the Microsoft compilers. Because the incref and decref macros are used a *lot*, it's unattractive to burden all platforms with this just to shut up one compiler. I don't care about Py_CLEAR() (etc), because they're so lightly used. The incref/decref macros are ubiquitous. I would much rather see SWIG change to insert curlies. That is, generating "if (newref) {Py_DECREF(obj);}" should be just as effective at shutting up this gcc nag. Has anyone asked the SWIG project to do this? ---------------------------------------------------------------------- Comment By: Richard Kettlewell (rjk1002) Date: 2005-02-01 09:51 Message: Logged In: YES user_id=217390 Making it compiler-specific seems silly. It's not like the do-while idiom for macros is some strange gcc-specific thing; most people just use it unconditionally on complicated macros. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-01 02:53 Message: Logged In: YES user_id=80475 Tim, what you think about doing this with a conditional compile to only redefine for GCC? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 From noreply at sourceforge.net Wed Feb 2 15:43:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 15:43:27 2005 Subject: [ python-Bugs-1114776 ] copy.py bug Message-ID: Bugs item #1114776, was opened at 2005-02-02 15:43 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=1114776&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vincenzo Di Somma (disommav) Assigned to: Nobody/Anonymous (nobody) Summary: copy.py bug Initial Comment: upgrading from python 2.3.4 to 2.3.5rc1 I got this error on a module that was working correctly File "../Field.py", line 203, in copy properties = deepcopy(cdict) File "/usr/lib/python2.3/copy.py", line 191, in deepcopy y = copier(x, memo) File "/usr/lib/python2.3/copy.py", line 285, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.3/copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "/usr/lib/python2.3/copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 From noreply at sourceforge.net Wed Feb 2 17:43:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 17:43:37 2005 Subject: [ python-Bugs-993766 ] bdist_dumb and --relative on Windows fails Message-ID: Bugs item #993766, was opened at 2004-07-19 15:03 Message generated for change (Comment added) made by lacouture You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993766&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_dumb and --relative on Windows fails Initial Comment: The following setup.py file: """ from distutils.core import setup, Extension setup(name="foo", scripts= ["foo.py"]) """ (plus any 'foo.py') fails when creating a .zip binary on windows: >setup.py bdist_dumb --relative running bdist_dumb ... error: build\bdist.win32\dumb\e:src\python-2.3-cvs: Invalid argument ---------------------------------------------------------------------- Comment By: Patrice LACOUTURE (lacouture) Date: 2005-02-02 17:43 Message: Logged In: YES user_id=1120079 It seems related to the function ensure_relative (distutils/dir_utils.py, line 217), that keeps the drive name in the relative path built. >>> ensure_relative("C:\Python24") "C:Python24" It is called by bdist_dumb to manage the relative path properly, but fails so. I can't guess what was the original intent (maybe for some other OS, maybe just a simple error?), but the following change seems to fix the issue: $ diff --from-file=dir_util.old.py dir_util.py 226c226 < path = drive + path[1:] --- > path = path[1:] (just skip the drive name and the initial os.sep if any). The ensure_relative() function is only used by bdist_dumb, so I believe this change is safe, unless the "bogus" line had some hidden intent I couldn't figure (other OS???). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993766&group_id=5470 From noreply at sourceforge.net Wed Feb 2 18:16:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 18:16:10 2005 Subject: [ python-Bugs-993766 ] bdist_dumb and --relative on Windows fails Message-ID: Bugs item #993766, was opened at 2004-07-19 15:03 Message generated for change (Comment added) made by lacouture You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993766&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_dumb and --relative on Windows fails Initial Comment: The following setup.py file: """ from distutils.core import setup, Extension setup(name="foo", scripts= ["foo.py"]) """ (plus any 'foo.py') fails when creating a .zip binary on windows: >setup.py bdist_dumb --relative running bdist_dumb ... error: build\bdist.win32\dumb\e:src\python-2.3-cvs: Invalid argument ---------------------------------------------------------------------- Comment By: Patrice LACOUTURE (lacouture) Date: 2005-02-02 18:16 Message: Logged In: YES user_id=1120079 BTW, the patch shown in my previous comment applies to distutils/dir_util.py from Python 2.4. 226c226 < path = drive + path[1:] --- > path = path[1:] ---------------------------------------------------------------------- Comment By: Patrice LACOUTURE (lacouture) Date: 2005-02-02 17:43 Message: Logged In: YES user_id=1120079 It seems related to the function ensure_relative (distutils/dir_utils.py, line 217), that keeps the drive name in the relative path built. >>> ensure_relative("C:\Python24") "C:Python24" It is called by bdist_dumb to manage the relative path properly, but fails so. I can't guess what was the original intent (maybe for some other OS, maybe just a simple error?), but the following change seems to fix the issue: $ diff --from-file=dir_util.old.py dir_util.py 226c226 < path = drive + path[1:] --- > path = path[1:] (just skip the drive name and the initial os.sep if any). The ensure_relative() function is only used by bdist_dumb, so I believe this change is safe, unless the "bogus" line had some hidden intent I couldn't figure (other OS???). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993766&group_id=5470 From noreply at sourceforge.net Wed Feb 2 18:21:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 18:21:58 2005 Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh Message-ID: Bugs item #1108992, was opened at 2005-01-25 05:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 12:21 Message: Logged In: YES user_id=149084 To keep things simple, please start IDLE with the -n switch directly on your ubuntu box for the purposes of future investigations on this issue. Can you attach to the frozen IDLE with gdb and then use 'bt' to get a backtrace and find out what was going at at the time of the freeze? If so, is it repeatable? It's occasionally reported that IDLE freezes. I've never seen it myself, running IDLE for many days on OpenBSD, Debian, RH, and Arch Linux, WindowsXP, W2K, and W98, over a period of many years, so it's hard for me to figure out what's going on. But it's peculiar that 0.8 doesn't have the problem. Are you sure? What else is the ubuntu box doing? Is the load heavy? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-02-01 08:35 Message: Logged In: YES user_id=993923 > So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. That is correct. The problem appears exactly the same when run over ssh though, which, I guess rules out any gnome/metacity/X wierdness. > I suspect a hardware problem I' sceptical about that. There's nothing in dmesg or /var/log to suggest it, and absolutely no other problems with the machine in question. >Are you starting IDLE from the command line Yes, but no messages are shown. > How much memory 255MB, IDLE uses about 3.5% of that on startup, grew to 5.7% at time of last crash ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 21:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 01:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 15:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 14:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 12:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 04:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 From noreply at sourceforge.net Wed Feb 2 19:22:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 19:22:35 2005 Subject: [ python-Bugs-1114929 ] webbrowser doesn't start default Gnome browser by default Message-ID: Bugs item #1114929, was opened at 2005-02-02 18: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=1114929&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser doesn't start default Gnome browser by default Initial Comment: I've written a patch to try to access the default Gnome web browser under Unix (if Gnome is available). This is likely to be a good choice of web browser under modern systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114929&group_id=5470 From noreply at sourceforge.net Wed Feb 2 19:50:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 19:50:33 2005 Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh Message-ID: Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark ---------------------------------------------------------------------- >Comment By: Mark Poolman (mgpoolman) Date: 2005-02-02 18:50 Message: Logged In: YES user_id=993923 >0.8 doesn't have the problem. Are you sure? Can't be certain as haven't used it for extended periods on that box, but I'll look into it. I've used IDLE daily for about 4 years on various RH and Suse, and never seen a problem until now. > What else is the ubuntu box doing? Is the load heavy? Almost nothing, it's there to evaluate ubuntu as a desktop w/s, and my main activity is getting some in-house python s/w ported to it. gdb results to follow. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 17:21 Message: Logged In: YES user_id=149084 To keep things simple, please start IDLE with the -n switch directly on your ubuntu box for the purposes of future investigations on this issue. Can you attach to the frozen IDLE with gdb and then use 'bt' to get a backtrace and find out what was going at at the time of the freeze? If so, is it repeatable? It's occasionally reported that IDLE freezes. I've never seen it myself, running IDLE for many days on OpenBSD, Debian, RH, and Arch Linux, WindowsXP, W2K, and W98, over a period of many years, so it's hard for me to figure out what's going on. But it's peculiar that 0.8 doesn't have the problem. Are you sure? What else is the ubuntu box doing? Is the load heavy? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-02-01 13:35 Message: Logged In: YES user_id=993923 > So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. That is correct. The problem appears exactly the same when run over ssh though, which, I guess rules out any gnome/metacity/X wierdness. > I suspect a hardware problem I' sceptical about that. There's nothing in dmesg or /var/log to suggest it, and absolutely no other problems with the machine in question. >Are you starting IDLE from the command line Yes, but no messages are shown. > How much memory 255MB, IDLE uses about 3.5% of that on startup, grew to 5.7% at time of last crash ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-01 02:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 06:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 20:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 19:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? ---------------------------------------------------------------------- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 09:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 From noreply at sourceforge.net Wed Feb 2 20:35:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 20:35:58 2005 Subject: [ python-Bugs-1114776 ] copy.py bug Message-ID: Bugs item #1114776, was opened at 2005-02-02 14:43 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 9 Submitted By: Vincenzo Di Somma (disommav) >Assigned to: Anthony Baxter (anthonybaxter) Summary: copy.py bug Initial Comment: upgrading from python 2.3.4 to 2.3.5rc1 I got this error on a module that was working correctly File "../Field.py", line 203, in copy properties = deepcopy(cdict) File "/usr/lib/python2.3/copy.py", line 191, in deepcopy y = copier(x, memo) File "/usr/lib/python2.3/copy.py", line 285, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.3/copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "/usr/lib/python2.3/copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-02 19:35 Message: Logged In: YES user_id=6656 Eek, that sounds pretty bad! Can you attach the code/cook up a smaller test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 From noreply at sourceforge.net Wed Feb 2 21:59:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 2 21:59:33 2005 Subject: [ python-Bugs-1115039 ] eval != literal scope in nested function Message-ID: Bugs item #1115039, was opened at 2005-02-02 20: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=1115039&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Collier (carou) Assigned to: Nobody/Anonymous (nobody) Summary: eval != literal scope in nested function Initial Comment: python 2.3 as installed by default in MacOS X 10.3.7 This may be the same as item 991196, but that's my uneducated guess since I don't understand the cause of either one... (in fact it may not even really be a bug, but at the least this is behaviour I'm unable to explain). It seems that fewer symbols are available to eval() than are available to literal code. The best way to describe the problem is with the attached short example file. In the function evalfunction2(), a call via eval() is unable to resolve the symbol name evalfunction1 - even though it would be possible to call evalfunction1() directly. But if the code *does* call evalfunction1() directly, then the eval() can see that symbol too(!). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115039&group_id=5470 From noreply at sourceforge.net Thu Feb 3 00:08:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 00:08:35 2005 Subject: [ python-Feature Requests-1114404 ] All Statements Should Have Return Values (Syntax Proposal) Message-ID: Feature Requests item #1114404, was opened at 2005-02-01 20:27 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1114404&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: All Statements Should Have Return Values (Syntax Proposal) Initial Comment: Python should allow a return value for some statements or blocks such as `print` or `def`. This should not always happen, but could certainly be useful. This can be used instead of lambdas when something more complex is required (the `def` example.) What seems to me to be the most natural syntax is to simply wrap the statement in parentheses. For example: >>> foo = (print 'bar') bar >>> foo 'bar' >>> f = (def f(x): if x < 0: return -5 return x ** 2 ) >>> f >>> # A useful example: >>> do_some_sort_of_logging( ( raise SomeSortOfError ) ) It will generally be obvious what should be returned, but why not be more explicit? Here are some loose specs: `def` would return the defined function. `class` would return the defined class. `print` would return the string representation of the printed object. `raise` will return the exception. `import` returns the module or a tuple of modules. This is not mean to be complete or a definitive syntax, but I'd certainly like this discussed and something along the lines of this proposal implemented. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2005-02-02 18:08 Message: Logged In: YES user_id=7733 In Python, expressions return values. Statements don't. That's fundamental to the language. In any case, such a proposal is too broad to discuss here. If you'd like to proceed, please write a PEP. See http://www.python.org/peps/pep-0001.html for the procedure. Better yet, please discuss it on comp.lang.python (python-list@python.org) first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1114404&group_id=5470 From noreply at sourceforge.net Thu Feb 3 00:26:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 00:26:08 2005 Subject: [ python-Bugs-1115039 ] eval != literal scope in nested function Message-ID: Bugs item #1115039, was opened at 2005-02-02 15:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115039&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andrew Collier (carou) Assigned to: Nobody/Anonymous (nobody) Summary: eval != literal scope in nested function Initial Comment: python 2.3 as installed by default in MacOS X 10.3.7 This may be the same as item 991196, but that's my uneducated guess since I don't understand the cause of either one... (in fact it may not even really be a bug, but at the least this is behaviour I'm unable to explain). It seems that fewer symbols are available to eval() than are available to literal code. The best way to describe the problem is with the attached short example file. In the function evalfunction2(), a call via eval() is unable to resolve the symbol name evalfunction1 - even though it would be possible to call evalfunction1() directly. But if the code *does* call evalfunction1() directly, then the eval() can see that symbol too(!). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-02 18:26 Message: Logged In: YES user_id=80475 Sorry, this isn't a bug. The eval() function is documented to only search globals() and local(). The nested scope of eval's caller is not included. In your code, callfunction2 works because callfunction1 can be found in the nested scope. In contrast, evalfunction2 fails because evalfunction1 is not in the locals() or globals(); instead, is in a enclosing nested scope which is not searched. The reason that evalfunction2 works if you uncomment the extra code is the subsequent reference to evalfunction1 gets it brought into locals() at compilation time (when the def is executed). For real code, is you want a nested scope object to be found by eval, then either reference it in the same function that calls eval() or, more explicitly, just add it to a dictionary of things that should be visible to eval(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115039&group_id=5470 From noreply at sourceforge.net Thu Feb 3 04:26:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 04:26:34 2005 Subject: [ python-Bugs-1114776 ] copy.py bug Message-ID: Bugs item #1114776, was opened at 2005-02-03 01:43 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Vincenzo Di Somma (disommav) Assigned to: Anthony Baxter (anthonybaxter) Summary: copy.py bug Initial Comment: upgrading from python 2.3.4 to 2.3.5rc1 I got this error on a module that was working correctly File "../Field.py", line 203, in copy properties = deepcopy(cdict) File "/usr/lib/python2.3/copy.py", line 191, in deepcopy y = copier(x, memo) File "/usr/lib/python2.3/copy.py", line 285, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.3/copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "/usr/lib/python2.3/copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-03 14:26 Message: Logged In: YES user_id=29957 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293338 has a fuller stack trace. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-03 06:35 Message: Logged In: YES user_id=6656 Eek, that sounds pretty bad! Can you attach the code/cook up a smaller test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 From noreply at sourceforge.net Thu Feb 3 07:01:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 07:01:42 2005 Subject: [ python-Bugs-1107258 ] os.pathsep is wrong on Mac OS X Message-ID: Bugs item #1107258, was opened at 2005-01-22 03:07 Message generated for change (Comment added) made by boredzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1107258&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Brett Cannon (bcannon) Summary: os.pathsep is wrong on Mac OS X Initial Comment: I'm running Python 2.4 on Darwin 7.5 (Mac OS X 10.3.5). os.path.pathsep should be returning '/', since that's what everything that works with paths (the rest of the path module, plus the file class, etc.) expects. and yet it returns ':'. making this even stranger is the fact that repr(os.path) returns the path to posixpath. ---------------------------------------------------------------------- >Comment By: Mac-arena the Bored Zo (boredzo) Date: 2005-02-02 22:01 Message: Logged In: YES user_id=711099 I wasn't suggesting that Darwin shouldn't use posixpath, I was wondering why it would be returning ':' for the path separator. thanks for the explanation. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-22 11:03 Message: Logged In: YES user_id=357491 You are misunderstanding what os.path.pathsep is for. It is the string that separates paths themselves, not parts of a path. It's ':' because that is how you separate paths on Darwin and any UNIX platform (e.g., "/usr/ bin:/usr/local/bin". And because Darwin is UNIX it uses posixpath. Closing as invalid since the setting is right and is not even in the official docs so general usage is not supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1107258&group_id=5470 From noreply at sourceforge.net Thu Feb 3 14:11:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 14:11:46 2005 Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug Message-ID: Bugs item #1115379, was opened at 2005-02-03 14: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=1115379&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 From noreply at sourceforge.net Thu Feb 3 17:41:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 17:41:23 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) >Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Thu Feb 3 18:06:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 3 18:06:18 2005 Subject: [ python-Bugs-1113484 ] document {m} regex matcher wrt empty matches Message-ID: Bugs item #1113484, was opened at 2005-01-31 22:46 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113484&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Gustavo Niemeyer (niemeyer) Summary: document {m} regex matcher wrt empty matches Initial Comment: The {m} matcher seems not to be applicable to (some) empty matches. For example this will raise a regex compile error: >>> re.compile("(a*){4}") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/sre.py", line 179, in compile return _compile(pattern, flags) File "/usr/lib/python2.3/sre.py", line 230, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat However this matcher is compiled without error: >>> re.compile("(\ba*){4}") <_sre.SRE_Pattern object at 0xb7f86c58> I don't know why the first example gives an error, but it should perhaps be mentioned in the documentation about the {} regex operator. ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2005-02-03 18:06 Message: Logged In: YES user_id=9205 Oops, it should have been: >>> re.compile(r"(\ba*){4}") And now the error is consistent (now tested in Python 2.4 instead of 2.3): Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/sre.py", line 180, in compile return _compile(pattern, flags) File "/usr/lib/python2.4/sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat So it seems that {m} operator does not like potentially empty matches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113484&group_id=5470 From noreply at sourceforge.net Fri Feb 4 02:27:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 02:27:08 2005 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-04 10: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=1115886&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Fri Feb 4 02:36:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 02:36:30 2005 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-04 10:27 Message generated for change (Settings changed) made by falsetru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 >Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Fri Feb 4 05:16:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 05:16:05 2005 Subject: [ python-Bugs-798058 ] IDLE / PyOS_InputHook Message-ID: Bugs item #798058, was opened at 2003-08-31 03:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798058&group_id=5470 >Category: IDLE >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE / PyOS_InputHook Initial Comment: [This bug report is a follow-up of a discussion with Matthew Cowler of help@python] I noticed an inconsistency with the usage of the PyOS_InputHook variable between Python 2.3's IDLE and Python run from the (DOS or linux) command prompt. This problem does not occur with earlier versions of Python. First I will describe the problem, then why it is important to me. The PyOS_InputHook variable can be used to install a callback function that gets called periodically (via readline's rl_event_hook) when Python is waiting for terminal input. When Python is run as a terminal application (from the DOS or linux command prompt), PyOS_InputHook is NULL initially. Python C extension modules can set PyOS_InputHook to a function which is to be called periodically. This works with Python 2.3 and older versions. In Python 2.2, IDLE makes use of the PyOS_InputHook variable, presumably to get messages delivered to the Tkinter window. Python C extension modules that are loaded from IDLE find that PyOS_InputHook is not NULL, and therefore cannot specify a different callback function via PyOS_InputHook, as that would freeze the Tkinter window. Now on Python 2.2, in practice that is not a problem. IDLE in Python 2.2 runs in a single thread. This thread contains a message loop (probably hidden in the Tk library) that takes care of the messages destined for the Tk window. If we open an additional (non-Tk) window from our C extension module, then its messages also get processed by Tk's message loop as it is running in the same thread. So we don't need an additional message loop for our non-Tk window, and we don't need to change PyOS_InputHook. In Python 2.3, IDLE works differently, as it talks to its interactive interpreter on the TCP/IP loopback interface and does not make use of PyOS_InputHook. If I import my C extension module from IDLE, it shows that PyOS_InputHook is NULL. In addition, multithreading is now used, with three threads on Windows and two on Linux and Mac OS X. (I am not sure where the additional thread on Windows is coming from). In particular, the C extension module and Tk's message loop are running in separate threads. So if I open a non-Tk window from my C extension module, its messages are not handled by Tk's message loop. The solution would be to have a message loop in my C extension module also, which is how the C extension module works when Python is run as a terminal application. As PyOS_InputHook is NULL (both with and without IDLE) when I import my extension module, I can point it to a message loop in the extension module without causing havoc. However, whereas Python without IDLE calls the function specified by PyOS_InputHook correctly, Python with IDLE fails to call PyOS_InputHook. Hence, with IDLE I am stuck in a thread without a message loop, and no way to provide a message loop of my own. If I run IDLE with the "-n" command-line argument to disable running Python code in a sub-process, there is only one thread, and I can use that thread's message loop without problems. Would it be possible in Python 2.3 to have PyOS_InputHook called also if IDLE / Tkinter is running? I would think that that no longer interferes with the correct operation of Tkinter / IDLE, as after importing IDLE, PyOS_InputHook is NULL anyway. This problem is important to me because of the Windows-port of Pygist (gist scientific plotting package for Python), which I codeveloped several months ago. The core graphics routines of Pygist are written in C for performance reasons. Pygist does not work with Python 2.3 with IDLE, while it does work with Python 2.2 with IDLE. There are no problems with Python 2.3 run from the DOS command prompt, nor with PythonWin or PyShell. The problem with Python 2.3 with IDLE is that the graphics window no longer receives its messages. In usual Windows programs, there is one message loop, which looks like while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } In Python 2.2 with IDLE, we use Tk's message loop to get messages delivered to the Pygist graphics window. When running Python 2.2 and Python 2.3 as a terminal application, we start our own message loop in the C extension module and point to it using PyOS_InputHook. With Python 2.3 with IDLE, Tk's message loop is in a separate thread, so we can't use it, while at the same time PyOS_InputHook is being ignored. Hence Pygist's graphics window freezes. Note that Pygist is different from many other plotting packages for Python, as it returns to the Python prompt after opening a graphics Window (allowing you to modify the window interactively). So the trick is to let both the Python interpreter and the graphics window receive their messages. With regards, Michiel de Hoon, University of Tokyo. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-03 23:16 Message: Logged In: YES user_id=149084 Michiel de Hoon's comments re this Bug on python-dev: http://mail.python.org/pipermail/python-dev/2005-January/050895.html In IDLE there are two processes. One runs the GUI and communicates with the second via the socket interface. The subprocess has two threads: MainThread, which runs the user code, and SocketThread, which monitors the socket interface. SocketThread communicates with MainThread via two Queue objects and several global flags which are involved in shutting down the subprocess. So it's the subprocess (run.py) MainThread that should call PyOS_InputHook. See Patch 989712. Noam Raphael is trying to hook in tkinter's mainloop. This should all be solved together. Putting it back in IDLE for now so I can keep an eye on it. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-02-15 20:36 Message: Logged In: YES user_id=488897 I had another look at this and it seems that the problem is in the Modules/_tkinter.c. If I understand correctly, tkinter does not use the code in Modules/readline.c, which contains the call to PyOS_InputHook, and hence PyOS_InputHook is not being called. Surprisingly, the tkinter code does set the PyOS_InputHook variable to the EventHook routine, but this seems to be in vain as PyOS_InputHook is not being called anyway. I suggest to resubmit this bug report to the Tkinter category. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798058&group_id=5470 From noreply at sourceforge.net Fri Feb 4 07:25:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 07:25:52 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 06:25 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=1115989&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Fri Feb 4 08:21:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 08:21:25 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-30 16:58 Message generated for change (Comment added) made by joshhoyt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-03 23:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Fri Feb 4 11:15:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 11:15:48 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 01:58 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 11:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 08:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Fri Feb 4 16:45:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 16:45:35 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-30 16:58 Message generated for change (Comment added) made by joshhoyt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 07:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 02:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-03 23:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Fri Feb 4 23:06:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 23:06:40 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 01:58 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-02-04 23:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 16:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 11:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 08:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Fri Feb 4 23:16:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 23:16:03 2005 Subject: [ python-Bugs-1116520 ] Prefix search is filesystem-centric Message-ID: Bugs item #1116520, was opened at 2005-02-04 17: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=1116520&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 4 Submitted By: Steve Holden (holdenweb) Assigned to: Nobody/Anonymous (nobody) Summary: Prefix search is filesystem-centric Initial Comment: With the introduction of zipimport I experimented to determine how much of the standard library could be provided in zip format. I discovered that I could entirely remove the standard library, replacing it with /lib/python24.zip, with the following caveats (this is under Cygwin, where /usr/lib appears to be a loopback mount of /lib: paths will differ on other platforms): 1. The /lib/python2.4/lib-dynload directory had to be copied to the /lib directory to make zlib available to zipimport; 2. The interpreter now produced three error messages: "Could not find platform independent libraries " "Could not find platform dependent libraries " "Consider setting $PYTHONHOME to [:]" With the move towards esoteric import mechanisms it seems that the searches for os.py in the filesystem might no longer be an appropriate way to start executing the interpreter. Should some import hook API be available to determine whether standard libraries are available without actually importing anything? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116520&group_id=5470 From noreply at sourceforge.net Fri Feb 4 23:39:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 4 23:39:47 2005 Subject: [ python-Bugs-1053687 ] PyOS_InputHook not called in subprocess Message-ID: Bugs item #1053687, was opened at 2004-10-25 07:31 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1053687&group_id=5470 >Category: IDLE >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Kurt B. Kaiser (kbk) Summary: PyOS_InputHook not called in subprocess Initial Comment: PyOS_InputHook is a variable points to a user-defined function (e.g. in an extension module) that is to be called periodically when Python is idle (e.g. waiting for user input). It is used for example by Tkinter to get messages delivered to the graphics window. For Python run from the command prompt, PyOS_InputHook (if not NULL) is called ten times per second. In IDLE, when a subprocess is being used (so the default behavior), the main process and the subprocess each have their own PyOS_InputHook. The problem is that the subprocess (the one that runs the user's commands) does not call PyOS_InputHook. So if a user (in IDLE) imports an extension module that sets PyOS_InputHook, the extension module will not run correctly as PyOS_InputHook is being ignored. The solution to this problem is probably quite simple, maybe just a line if (PyOS_InputHook) PyOS_InputHook(); but I am not familiar enough with threads to be able to figure out what the best location for such a line would be. I tried putting it inside the loop in PyEval_EvalFrame in Python/ceval.c, which solved the problem on some platforms but not on others. --Michiel. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1053687&group_id=5470 From noreply at sourceforge.net Sat Feb 5 00:02:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 00:02:39 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-30 16:58 Message generated for change (Comment added) made by joshhoyt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 15:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 14:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 07:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 02:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-03 23:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Sat Feb 5 00:16:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 00:16:55 2005 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 05:13 Message generated for change (Comment added) made by bos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-04 15:16 Message: Logged In: YES user_id=28380 With the GNU linker, you can pass in -Bstatic to force it to resolve the symbols in the local shared library, instead of globally. This also works on Irix. I don't know about other Unixes. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-02 02:35 Message: Logged In: YES user_id=6656 It's a nasty one, I'll give you that. Fred, what do you think of bos's patch? It solves the immediate issue, but I'm not sure it's a complete fix. It seems to me that it would be better to resolve the expat symbols at builf time, but I don't know how to arrange for that. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-02-01 22:09 Message: Logged In: YES user_id=28380 By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO. ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-01-31 23:53 Message: Logged In: YES user_id=28380 I've been bitten by the same bug. In my case, the problem was with Qt, not GTK. It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything. Here's the patch I use for this problem: --- python/Modules/pyexpat.c 2005-01-06 16:26:13 -08:00 +++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00 @@ -1936,9 +1936,12 @@ } #endif -#define MYCONST(name) - PyModule_AddStringConstant(errors_module, #name, - (char*)XML_ErrorString(name)) +#define MYCONST(name) + { + char *_v = (char*)XML_ErrorString(name); + if (_v) + PyModule_AddStringConstant(errors_module, #name, _v); + } MYCONST(XML_ERROR_NO_MEMORY); MYCONST(XML_ERROR_SYNTAX); ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 05:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 05:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 01:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 09:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 08:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 08:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Sat Feb 5 01:12:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 01:12:55 2005 Subject: [ python-Bugs-1116571 ] Wrong match with regex, non-greedy problem Message-ID: Bugs item #1116571, was opened at 2005-02-05 01: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=1116571&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: rengel (engel_re) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Wrong match with regex, non-greedy problem Initial Comment: # This is executable. # My test string ist rather long: tst = "In this Buch, used to designate Dinge der Wirklichkeit rather than SW Ent." # I want to match the last part of the string: # SW Ent # So I define the following pattern an compile it: pat = r"(.*?) (.*?)" rex = re.compile(pat) # Then I search the string to get a match group : mat = rex.search(tst) # If found, print the group if mat: print mat.group() # Instead of # SW Ent # I get the whole string starting with # Buch... # up to the very last # Apparently the non-greedy operator doesn't work correctly. # What's wrong? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 From noreply at sourceforge.net Sat Feb 5 08:02:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 08:02:46 2005 Subject: [ python-Bugs-1116722 ] Solaris 10 fails to compile complexobject.c Message-ID: Bugs item #1116722, was opened at 2005-02-04 23:02 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=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 10 fails to compile complexobject.c Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 From noreply at sourceforge.net Sat Feb 5 08:03:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 08:03:23 2005 Subject: [ python-Bugs-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.] Message-ID: Bugs item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Settings changed) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) >Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 From noreply at sourceforge.net Sat Feb 5 10:07:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 10:07:34 2005 Subject: [ python-Bugs-1114776 ] copy.py bug Message-ID: Bugs item #1114776, was opened at 2005-02-02 15:43 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Vincenzo Di Somma (disommav) Assigned to: Anthony Baxter (anthonybaxter) Summary: copy.py bug Initial Comment: upgrading from python 2.3.4 to 2.3.5rc1 I got this error on a module that was working correctly File "../Field.py", line 203, in copy properties = deepcopy(cdict) File "/usr/lib/python2.3/copy.py", line 191, in deepcopy y = copier(x, memo) File "/usr/lib/python2.3/copy.py", line 285, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.3/copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "/usr/lib/python2.3/copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2005-02-05 10:07 Message: Logged In: YES user_id=60314 The problem's easy to fix (using inspect.getmro instead of direct __mro__ access) but hard to reproduce -- what type not recorded in the dispatch table lacks an __mro__? Can't find one easily, and I'd like to have a unit-test reproducing the bug before I commit the fix. Vincenzo, can you explain what the type is happening to be in that value whose deepcopy gives problems? or can anybody else suggest a type as above? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-03 04:26 Message: Logged In: YES user_id=29957 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293338 has a fuller stack trace. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-02 20:35 Message: Logged In: YES user_id=6656 Eek, that sounds pretty bad! Can you attach the code/cook up a smaller test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 From noreply at sourceforge.net Sat Feb 5 23:50:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 5 23:50:05 2005 Subject: [ python-Bugs-1117048 ] Dictionary Evaluation Issue Message-ID: Bugs item #1117048, was opened at 2005-02-05 17: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=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Evaluation Issue Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Sun Feb 6 00:48:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 00:48:06 2005 Subject: [ python-Bugs-1117063 ] Typo in list.sort() documentation Message-ID: Bugs item #1117063, was opened at 2005-02-06 00: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=1117063&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in list.sort() documentation Initial Comment: There is a (8) note in the documentation of list methods. (8) describes optional arguments of the sort() method. The example is wrong for the key argument: key specifies a function of one argument that is used to extract a comparison key from each list element: "cmp=str.lower" Is should be: key specifies a function of one argument that is used to extract a comparison key from each list element: "key=str.lower" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117063&group_id=5470 From noreply at sourceforge.net Sun Feb 6 01:30:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 01:30:33 2005 Subject: [ python-Bugs-1117063 ] Typo in list.sort() documentation Message-ID: Bugs item #1117063, was opened at 2005-02-05 18:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117063&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in list.sort() documentation Initial Comment: There is a (8) note in the documentation of list methods. (8) describes optional arguments of the sort() method. The example is wrong for the key argument: key specifies a function of one argument that is used to extract a comparison key from each list element: "cmp=str.lower" Is should be: key specifies a function of one argument that is used to extract a comparison key from each list element: "key=str.lower" ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-05 19:30 Message: Logged In: YES user_id=80475 Someone already found and fixed this for 2.4.1. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117063&group_id=5470 From noreply at sourceforge.net Sun Feb 6 08:57:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 08:57:48 2005 Subject: [ python-Bugs-1114776 ] copy.py bug Message-ID: Bugs item #1114776, was opened at 2005-02-02 15:43 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Vincenzo Di Somma (disommav) Assigned to: Anthony Baxter (anthonybaxter) Summary: copy.py bug Initial Comment: upgrading from python 2.3.4 to 2.3.5rc1 I got this error on a module that was working correctly File "../Field.py", line 203, in copy properties = deepcopy(cdict) File "/usr/lib/python2.3/copy.py", line 191, in deepcopy y = copier(x, memo) File "/usr/lib/python2.3/copy.py", line 285, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.3/copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "/usr/lib/python2.3/copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2005-02-06 08:57 Message: Logged In: YES user_id=60314 Fixed (using inspect.getmro instead of direct __mro__ access) -- added unittest for that thanks to John Lenton's suggestion on c.l.py ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-05 10:07 Message: Logged In: YES user_id=60314 The problem's easy to fix (using inspect.getmro instead of direct __mro__ access) but hard to reproduce -- what type not recorded in the dispatch table lacks an __mro__? Can't find one easily, and I'd like to have a unit-test reproducing the bug before I commit the fix. Vincenzo, can you explain what the type is happening to be in that value whose deepcopy gives problems? or can anybody else suggest a type as above? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-03 04:26 Message: Logged In: YES user_id=29957 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293338 has a fuller stack trace. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-02 20:35 Message: Logged In: YES user_id=6656 Eek, that sounds pretty bad! Can you attach the code/cook up a smaller test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 From noreply at sourceforge.net Sun Feb 6 08:58:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 08:58:39 2005 Subject: [ python-Bugs-1114776 ] copy.py bug Message-ID: Bugs item #1114776, was opened at 2005-02-02 15:43 Message generated for change (Settings changed) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 9 Submitted By: Vincenzo Di Somma (disommav) Assigned to: Anthony Baxter (anthonybaxter) Summary: copy.py bug Initial Comment: upgrading from python 2.3.4 to 2.3.5rc1 I got this error on a module that was working correctly File "../Field.py", line 203, in copy properties = deepcopy(cdict) File "/usr/lib/python2.3/copy.py", line 191, in deepcopy y = copier(x, memo) File "/usr/lib/python2.3/copy.py", line 285, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.3/copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "/usr/lib/python2.3/copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-06 08:57 Message: Logged In: YES user_id=60314 Fixed (using inspect.getmro instead of direct __mro__ access) -- added unittest for that thanks to John Lenton's suggestion on c.l.py ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-05 10:07 Message: Logged In: YES user_id=60314 The problem's easy to fix (using inspect.getmro instead of direct __mro__ access) but hard to reproduce -- what type not recorded in the dispatch table lacks an __mro__? Can't find one easily, and I'd like to have a unit-test reproducing the bug before I commit the fix. Vincenzo, can you explain what the type is happening to be in that value whose deepcopy gives problems? or can anybody else suggest a type as above? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-03 04:26 Message: Logged In: YES user_id=29957 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293338 has a fuller stack trace. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-02 20:35 Message: Logged In: YES user_id=6656 Eek, that sounds pretty bad! Can you attach the code/cook up a smaller test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114776&group_id=5470 From noreply at sourceforge.net Sun Feb 6 15:04:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 15:04:30 2005 Subject: [ python-Bugs-1117302 ] sgmllib.SGMLParser Message-ID: Bugs item #1117302, was opened at 2005-02-06 14: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=1117302&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Birnie (pbirnie) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLParser Initial Comment: sgmllib.SGMLParser calls start tag and end_methods correctly until it encounters One
Two Three the
seems to cause its parsing to become confused and I conly get call backs for tag a twice (link 1 and 3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 From noreply at sourceforge.net Sun Feb 6 23:58:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 6 23:58:58 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 01:58 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-02-06 23:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-05 00:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 23:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 16:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 11:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 08:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Mon Feb 7 00:01:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 00:01:05 2005 Subject: [ python-Bugs-1117556 ] SimpleHTTPServer and mimetypes: almost together Message-ID: Bugs item #1117556, was opened at 2005-02-06 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=1117556&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117556&group_id=5470 From noreply at sourceforge.net Mon Feb 7 01:44:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 01:44:30 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 01:44:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 01:44:49 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) >Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 01:57:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 01:57:09 2005 Subject: [ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments. Message-ID: Bugs item #1117601, was opened at 2005-02-07 00: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=1117601&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Bennett (sbennett) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists returns false negatives in MAC environments. Initial Comment: In Mandatory Access Control environments (such as SELinux), it's quite possible for stat to fail with permission denied. In this case, os.path.exists will return False incorrectly. The simple(ish) fix is to check for an access denied error (which would indicate present, but not readable) when using stat to check for existence of files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 From noreply at sourceforge.net Mon Feb 7 02:08:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 02:08:04 2005 Subject: [ python-Bugs-1117048 ] Dictionary Evaluation Issue Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Settings changed) made by walterbrunswick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Evaluation Issue Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Mon Feb 7 02:09:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 02:09:19 2005 Subject: [ python-Bugs-1117048 ] Dictionary Evaluation Issue Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Settings changed) made by walterbrunswick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 1 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Evaluation Issue Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Mon Feb 7 02:51:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 02:51:41 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 05:50:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 05:50:57 2005 Subject: [ python-Bugs-1117670 ] profiler: Bad return and Bad call errors with exceptions Message-ID: Bugs item #1117670, was opened at 2005-02-06 21: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=1117670&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: profiler: Bad return and Bad call errors with exceptions Initial Comment: I ran into a weird error when trying to profile a test script of mine: AssertionError: ('Bad call', ('', 0, 'encode')) I managed to whittle it down to some minimal test cases, which are attached (although the errors they generate are slightly different.) $ python-cvs -m profile profile_badcall.py Traceback (most recent call last): [snipped ...] File "/home/donut/usr64/python/lib/python2.5/profile.py", line 444, in runctx exec cmd in globals, locals File "", line 1, in ? File "profile_badcall.py", line 10, in ? os.path.join("C",'b') File "/home/donut/usr64/python/lib/python2.5/posixpath.py", line 56, in join def join(a, *p): File "/home/donut/usr64/python/lib/python2.5/profile.py", line 228, in trace_dispatch_i if self.dispatch[event](self, frame, t): File "/home/donut/usr64/python/lib/python2.5/profile.py", line 285, in trace_dispatch_call assert (self.cur is None or AssertionError: ('Bad call', ('profile_badcall.py', 2, 'trier')) $ python-cvs -m profile profile_badreturn.py Traceback (most recent call last): [snipped...] File "/home/donut/usr64/python/lib/python2.5/profile.py", line 444, in runctx exec cmd in globals, locals File "", line 1, in ? File "/home/donut/usr64/python/lib/python2.5/profile.py", line 228, in trace_dispatch_i if self.dispatch[event](self, frame, t): File "/home/donut/usr64/python/lib/python2.5/profile.py", line 312, in trace_dispatch_return assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3]) AssertionError: ('Bad return', ('profile_badreturn.py', 1, 'trier')) The errors occur in python CVS as of 20050206 and python 2.4, but not in python 2.3.4. OS: debian sid (3.1) Arch: amd64 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470 From noreply at sourceforge.net Mon Feb 7 08:36:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 08:36:20 2005 Subject: [ python-Bugs-1103023 ] raw_input problem with readline and UTF8 Message-ID: Bugs item #1103023, was opened at 2005-01-15 11:10 Message generated for change (Comment added) made by donut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103023&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Casey Crabb (airog) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input problem with readline and UTF8 Initial Comment: Backspace doesn't remove all bytes of a multi-byte UTF-8 character. To reproduce the problem: $ export LANG=en_US.UTF-8 $ python Python 2.3.4 (#1, Jun 11 2004, 16:35:29) [GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r3, ssp-3.3-7, pie-8.5.3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline >>> raw_input() # ?, return ? '\xc3\xa4' >>> raw_input() # ?, backspace, return '\xc3' >>> A small C program does not have the same problem: #include #include #include #include void pprint(const char *s); int main(void) { char *line; for (;;) { line = readline("> "); if (!line) break; pprint(line); free(line); } return 0; } void pprint(const char *s) { while (*s) { if (isprint(*s)) putchar(*s); else printf("\x%x", *s & 0xff); s++; } putchar('\n'); } ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2005-02-07 00:36 Message: Logged In: YES user_id=65253 Hi, it looks like this might be the same problem already fixed in "[ 914291 ] Fix readline for utf-8 locales", but your python version is from before the fix went in. Can you try again with python 2.4, or 2.3.5 (when it is released, or the release23-maint branch of cvs)? Also, you could check if python's readline.so is linked to an older version of libreadline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103023&group_id=5470 From noreply at sourceforge.net Mon Feb 7 10:04:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 10:04:09 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-19 02:48 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2005-02-07 10:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 02:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 01:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 17:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 12:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 16:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 10:12:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 10:12:43 2005 Subject: [ python-Feature Requests-1117751 ] urllib.urlopen should put the http-error-code in .info() Message-ID: Feature Requests item #1117751, was opened at 2005-02-07 10: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=1117751&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen should put the http-error-code in .info() Initial Comment: urllib.urlopen / open_http should put the http-error-code somewhere in .info() the "fancy" error handling may be ok. But the errcode & errmsg should not get lost and always be accessible ex post. In current style bare urllib.urlopen is hard to use. (web pages are often down). I always need to fumble a extra urllib.URLopener even for the simplest task. E.g.: f=urllib.urlopen('http://www.python.org/') httpcode=f.info().get_errcode() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1117751&group_id=5470 From noreply at sourceforge.net Mon Feb 7 10:16:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 10:16:34 2005 Subject: [ python-Bugs-1117757 ] "in" operator bug ? Message-ID: Bugs item #1117757, was opened at 2005-02-07 10: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=1117757&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) Assigned to: Nobody/Anonymous (nobody) Summary: "in" operator bug ? Initial Comment: my python : Python 2.4 (#1, Dec 8 2004, 18:57:30) [GCC 3.3.3 (SuSE Linux)] on linux >>class C(object): >> def __getitem__ (self, name): >> return 1 >> c =C() >> 'a' in c here python never returns and CPU 100% this version works: >>class C(object): >> def __getitem__ (self, name): >> raise StopIteration >> c =C() >> 'a' in c False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117757&group_id=5470 From noreply at sourceforge.net Mon Feb 7 10:24:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 10:24:09 2005 Subject: [ python-Bugs-1117761 ] BSDDB openhash Message-ID: Bugs item #1117761, was opened at 2005-02-07 10: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=1117761&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) Assigned to: Nobody/Anonymous (nobody) Summary: BSDDB openhash Initial Comment: Python 2.4 (#1, Dec 8 2004, 18:57:30) [GCC 3.3.3 (SuSE Linux)] on linux2 >>> import bsddb >>> h = bsddb.hashopen('test','c',cachesize=100) Traceback (most recent call last): File "", line 1, in ? File "/home/alex/DLD/lib/python2.4/bsddb/__init__.py", line 288, in hashopen bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- DB->set_cachesize: method not permitted in shared environment') I replace bsddb.hashopen with a 2.3.3 version and it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&group_id=5470 From noreply at sourceforge.net Mon Feb 7 12:27:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 12:27:47 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-19 01:48 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-02-07 11:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 09:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 01:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 00:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 16:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 11:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 15:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 15:56:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 15:56:04 2005 Subject: [ python-Bugs-1117757 ] "in" operator bug ? Message-ID: Bugs item #1117757, was opened at 2005-02-07 04:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117757&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) Assigned to: Nobody/Anonymous (nobody) Summary: "in" operator bug ? Initial Comment: my python : Python 2.4 (#1, Dec 8 2004, 18:57:30) [GCC 3.3.3 (SuSE Linux)] on linux >>class C(object): >> def __getitem__ (self, name): >> return 1 >> c =C() >> 'a' in c here python never returns and CPU 100% this version works: >>class C(object): >> def __getitem__ (self, name): >> raise StopIteration >> c =C() >> 'a' in c False ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-07 09:56 Message: Logged In: YES user_id=31435 Not a bug. See the docs, or ask on comp.lang.python, for how __getitem__ works. Your original C is a class such that c [i] == 1 for any instance c and any subscript i. So "1 in c" will return True quickly, but nothing else can succeed. Add if name % 100000 == 0: print 'getting', name at the start of your original __getitem__ for a clue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117757&group_id=5470 From noreply at sourceforge.net Mon Feb 7 16:41:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 16:41:32 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-07 10:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 06:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 04:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 20:17:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 20:17:04 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-19 02:48 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2005-02-07 20:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 16:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 12:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 10:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 02:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 01:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 17:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 12:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 16:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 20:49:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 20:49:12 2005 Subject: [ python-Bugs-1118101 ] lists coupled Message-ID: Bugs item #1118101, was opened at 2005-02-07 19:49 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=1118101&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: chopf (chopf) Assigned to: Gustavo Niemeyer (niemeyer) Summary: lists coupled Initial Comment: is this normal? >>> ================================ RESTART ================================ >>> k=[1,2] >>> k [1, 2] >>> l=k >>> l [1, 2] >>> l[0]='hello' >>> l ['hello', 2] >>> k ['hello', 2] expected: [1,2] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118101&group_id=5470 From noreply at sourceforge.net Mon Feb 7 21:03:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 21:03:30 2005 Subject: [ python-Bugs-1118101 ] lists coupled Message-ID: Bugs item #1118101, was opened at 2005-02-07 14:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118101&group_id=5470 >Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: chopf (chopf) >Assigned to: Nobody/Anonymous (nobody) Summary: lists coupled Initial Comment: is this normal? >>> ================================ RESTART ================================ >>> k=[1,2] >>> k [1, 2] >>> l=k >>> l [1, 2] >>> l[0]='hello' >>> l ['hello', 2] >>> k ['hello', 2] expected: [1,2] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-07 15:03 Message: Logged In: YES user_id=31435 Yes, it's normal. You've given two names ("l" and "k") to a single list object. This is fundamental to how Python works. Maybe this will help: http://effbot.org/zone/python-objects.htm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118101&group_id=5470 From noreply at sourceforge.net Mon Feb 7 21:11:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 21:11:36 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-19 02:48 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2005-02-07 21:11 Message: Logged In: YES user_id=60314 I've checked the current codebase of the client for whom I originally wrote code using PyThreadState_SetAsyncExc, and that code is not currently used in production. It did that call while holding the GIL, FWIW. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 20:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 16:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 12:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 10:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 02:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 01:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 17:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 12:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 16:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Mon Feb 7 21:24:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 7 21:24:51 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Just van Rossum (jvr) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-07 15:24 Message: Logged In: YES user_id=31435 So we're peeing away time on a Mystery Function with no known actual uses in the entire world. Cool . ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-07 15:11 Message: Logged In: YES user_id=60314 I've checked the current codebase of the client for whom I originally wrote code using PyThreadState_SetAsyncExc, and that code is not currently used in production. It did that call while holding the GIL, FWIW. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 14:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 10:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 06:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 04:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Tue Feb 8 03:08:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 03:08:48 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 >Status: Closed Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) >Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 21:08 Message: Logged In: YES user_id=6380 OK, to prevent further waste of time I've checked in the proposed fix. I have no idea what the count>1 comment was referring to any more; I'm sure I wrote it though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 15:24 Message: Logged In: YES user_id=31435 So we're peeing away time on a Mystery Function with no known actual uses in the entire world. Cool . ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-07 15:11 Message: Logged In: YES user_id=60314 I've checked the current codebase of the client for whom I originally wrote code using PyThreadState_SetAsyncExc, and that code is not currently used in production. It did that call while holding the GIL, FWIW. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 14:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 10:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 06:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 04:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Tue Feb 8 03:19:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 03:19:39 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Closed Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-07 21:19 Message: Logged In: YES user_id=80475 Should the head lock's be backported to Py2.4? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 21:08 Message: Logged In: YES user_id=6380 OK, to prevent further waste of time I've checked in the proposed fix. I have no idea what the count>1 comment was referring to any more; I'm sure I wrote it though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 15:24 Message: Logged In: YES user_id=31435 So we're peeing away time on a Mystery Function with no known actual uses in the entire world. Cool . ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-07 15:11 Message: Logged In: YES user_id=60314 I've checked the current codebase of the client for whom I originally wrote code using PyThreadState_SetAsyncExc, and that code is not currently used in production. It did that call while holding the GIL, FWIW. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 14:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 10:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 06:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 04:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Tue Feb 8 03:27:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 03:27:40 2005 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Category: Threads Group: Python 2.4 Status: Closed Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-07 21:27 Message: Logged In: YES user_id=31435 Backport: sure, why not. Just don't ask anyone to test it . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-07 21:19 Message: Logged In: YES user_id=80475 Should the head lock's be backported to Py2.4? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 21:08 Message: Logged In: YES user_id=6380 OK, to prevent further waste of time I've checked in the proposed fix. I have no idea what the count>1 comment was referring to any more; I'm sure I wrote it though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 15:24 Message: Logged In: YES user_id=31435 So we're peeing away time on a Mystery Function with no known actual uses in the entire world. Cool . ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-07 15:11 Message: Logged In: YES user_id=60314 I've checked the current codebase of the client for whom I originally wrote code using PyThreadState_SetAsyncExc, and that code is not currently used in production. It did that call while holding the GIL, FWIW. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 14:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 10:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 06:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 04:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Tue Feb 8 03:40:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 03:41:07 2005 Subject: [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-02 00:37 Message generated for change (Comment added) made by sdati You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 Category: Tkinter Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Richardson (garyrxx) Assigned to: Martin v. L?wis (loewis) Summary: Mouse wheel crashes program Initial Comment: The following program (by Michael Peuser) crashes as soon as the mouse wheel is moved. See my post to c.l.p. on Oct 29. Gary Richardson #------------------------- from Tkinter import * def _onMouseWheel(event): print event root = Tk() root.bind('<MouseWheel>',_onMouseWheel) root.mainloop() ---------------------------------------------------------------------- Comment By: Steve Davis (sdati) Date: 2005-02-08 02:40 Message: Logged In: YES user_id=1214285 I have determined the root cause of this problem. It actually does lie in Tk, but is only revealed by Python Tkinter because of the way Python deals with events. >From Tk source -- tkWinX.c: case WM_MOUSEWHEEL: ... event.xany.send_event = -1 ... This line causes Tk to call TkpGetString() when ExpandPercents() is called with '%A' (which is done by Python for ALL events, including ). This, in turn, causes segmentation fault because event.xkey.trans_chars and event.xkey.nbytes are not initialized. So, the workaround from the Python side is pretty ugly, but I have tested it and verified that it works. There is probably a better way, but this was the obvious solution to me, since I have never needed to look at the Tkinter interface before: In Tkinter.py, define a new _subst_format and _subst_format_str: _subst_format_workaround = ('%#', '%b', '%f', '%h', '%k', '%s', '%t', '%w', '%x', '%y', '%D', '%E', '%K', '%N', '%W', '%T', '%X', '%Y', '%D') _subst_format_str_workaround = " ".join(_subst_format_workaround) Note that '%A' entry in _subst_format is replaced with '%D' entry in _subst_format_workaround. Now, in Misc._bind(), if sequence == "": cmd = ('%sif {"[%s %s]" == "break"} break\n' % (add and '+' or '', funcid, self._subst_format_str_workaround)) else: cmd = ('%sif {"[%s %s]" == "break"} break\n' % (add and '+' or '', funcid, self._subst_format_str)) I am submitting this bug to Tcl/Tk maintainers to request that they fix (Project: Tk Toolkit Request ID 1118340), but in the meantime (and for all older versions of Tk), it seems like a workaround in the Tkinter code might be appropriate. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2005-01-04 15:40 Message: Logged In: YES user_id=2138 I wasn't able to reproduce this in pure Tcl/Tk (under Wish). No surprise there. In wish, I used this: toplevel .top bind .top {puts 'foo'} And mouse wheeling in the Toplevel widget made a bunch of 'foo's appear in the wish console without crashing. HTH. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2005-01-04 15:02 Message: Logged In: YES user_id=2138 Me too. Python 2.3.4 with Tcl/Tk 8.4.9. Crash on Scroll Wheeling in WinXP SP 1. (users report it happening in SP 2 also). I'll try to make this happen in pure Tcl/Tk rather than Tkinter too. ---------------------------------------------------------------------- Comment By: John Fouhy (johnfouhy) Date: 2004-10-26 04:13 Message: Logged In: YES user_id=1084032 I can reproduce this bug. I am running Python 2.3.4 on WinXP SP2. tk84.dll is version 8.4.3; tcl84.dll is also 8.4.3. The mousewheel works correctly with a Tkinter.Text object with no additional bindings. ---------------------------------------------------------------------- Comment By: Jon Ashley (ash101) Date: 2003-12-04 17:02 Message: Logged In: YES user_id=923903 Happens for me too, on Win2K with python 2.3.2. The fault is in TCL84.DLL at an offset of 1002a58c, if that means anything to anyone. ---------------------------------------------------------------------- Comment By: Gary Richardson (garyrxx) Date: 2003-11-03 02:42 Message: Logged In: YES user_id=899035 I'm using Win98SE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 18:37 Message: Logged In: YES user_id=21627 What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 From noreply at sourceforge.net Tue Feb 8 05:33:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 05:34:02 2005 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-08 01:48 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Closed Resolution: Later Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2005-02-08 15:33 Message: Logged In: YES user_id=50945 Looks like someone is seeing something similar on FreeBSD and Python 2.4, with the added bonus of segfaults: http://twistedmatrix.com/pipermail/twisted-python/2005-February/009474.html They are apparently able to reproduce the problem, too -- but a 3rd-party extension module (psycopg) is involved, so who knows... ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2004-12-11 04:57 Message: Logged In: YES user_id=2138 Given that I can't reproduce it in a simple test, and it happens so rarely in my real applications, I'm okay with notice of it just being in google and here on sf. Maybe someday someone will encounter it again and we can make progress. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-11 04:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-11 04:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Tue Feb 8 05:51:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 05:51:36 2005 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 14:48 Message generated for change (Comment added) made by snacktime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Closed Resolution: Later Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- Comment By: Chris Ochs (snacktime) Date: 2005-02-08 04:51 Message: Logged In: YES user_id=31170 Me being that someone.... Here is some extra information in addition to what is in the referenced post on twisted-python. Besides twisted, the only other third party modules I am using are psycopg and pycrypto. I'm going to pull out the code that uses those modules one at a time and see if I can narrow it down. The segfaults/bus errors are easy to repeat and happen every time unless gdb is attached, in which case I get the exception. For some reason it seems like gdb does something that makes the code return the exception instead of segfault. I'll try to put together the smallest test case I can that segfaults and post it here. Chris chris@paymentonline.com ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2005-02-08 04:33 Message: Logged In: YES user_id=50945 Looks like someone is seeing something similar on FreeBSD and Python 2.4, with the added bonus of segfaults: http://twistedmatrix.com/pipermail/twisted-python/2005-February/009474.html They are apparently able to reproduce the problem, too -- but a 3rd-party extension module (psycopg) is involved, so who knows... ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2004-12-10 17:57 Message: Logged In: YES user_id=2138 Given that I can't reproduce it in a simple test, and it happens so rarely in my real applications, I'm okay with notice of it just being in google and here on sf. Maybe someday someone will encounter it again and we can make progress. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-10 17:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 17:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Tue Feb 8 06:21:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 06:21:29 2005 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 14:48 Message generated for change (Comment added) made by snacktime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Closed Resolution: Later Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- Comment By: Chris Ochs (snacktime) Date: 2005-02-08 05:21 Message: Logged In: YES user_id=31170 The problem stems from pycrypto. Not knowing a whole lot about threads I'm not sure if it's actually a pycrypto bug or a python bug, but I'll send a message to the pycryto guys and see what they say. The exact method that causes the segfault is RSA encrypt() ---------------------------------------------------------------------- Comment By: Chris Ochs (snacktime) Date: 2005-02-08 04:51 Message: Logged In: YES user_id=31170 Me being that someone.... Here is some extra information in addition to what is in the referenced post on twisted-python. Besides twisted, the only other third party modules I am using are psycopg and pycrypto. I'm going to pull out the code that uses those modules one at a time and see if I can narrow it down. The segfaults/bus errors are easy to repeat and happen every time unless gdb is attached, in which case I get the exception. For some reason it seems like gdb does something that makes the code return the exception instead of segfault. I'll try to put together the smallest test case I can that segfaults and post it here. Chris chris@paymentonline.com ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2005-02-08 04:33 Message: Logged In: YES user_id=50945 Looks like someone is seeing something similar on FreeBSD and Python 2.4, with the added bonus of segfaults: http://twistedmatrix.com/pipermail/twisted-python/2005-February/009474.html They are apparently able to reproduce the problem, too -- but a 3rd-party extension module (psycopg) is involved, so who knows... ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2004-12-10 17:57 Message: Logged In: YES user_id=2138 Given that I can't reproduce it in a simple test, and it happens so rarely in my real applications, I'm okay with notice of it just being in google and here on sf. Maybe someday someone will encounter it again and we can make progress. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-10 17:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 17:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Tue Feb 8 09:01:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 09:01:30 2005 Subject: [ python-Bugs-1117302 ] sgmllib.SGMLParser Message-ID: Bugs item #1117302, was opened at 2005-02-06 15:04 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Birnie (pbirnie) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLParser Initial Comment: sgmllib.SGMLParser calls start tag and end_methods correctly until it encounters One
Two Three the
seems to cause its parsing to become confused and I conly get call backs for tag a twice (link 1 and 3) ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:01 Message: Logged In: YES user_id=38376 footnote:
is an XML construct, and is not valid HTML. In HTML, "blah", so the BR section is parsed as START br DATA >Two< END br DATA a> which is 100% correct. For more on this topic, see: http://www.cs.tut.fi/~jkorpela/html/empty.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 From noreply at sourceforge.net Tue Feb 8 09:03:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 09:03:39 2005 Subject: [ python-Bugs-1117302 ] sgmllib.SGMLParser Message-ID: Bugs item #1117302, was opened at 2005-02-06 15:04 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Birnie (pbirnie) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLParser Initial Comment: sgmllib.SGMLParser calls start tag and end_methods correctly until it encounters One
Two Three the
seems to cause its parsing to become confused and I conly get call backs for tag a twice (link 1 and 3) ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:03 Message: Logged In: YES user_id=38376 footnote 2: if you need to deal with broken HTML, use TidyLib: http://utidylib.berlios.de/ http://effbot.org/zone/element-tidylib.htm ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:01 Message: Logged In: YES user_id=38376 footnote:
is an XML construct, and is not valid HTML. In HTML, "blah", so the BR section is parsed as START br DATA >Two< END br DATA a> which is 100% correct. For more on this topic, see: http://www.cs.tut.fi/~jkorpela/html/empty.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 From noreply at sourceforge.net Tue Feb 8 09:14:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 09:14:09 2005 Subject: [ python-Bugs-1117302 ] sgmllib.SGMLParser Message-ID: Bugs item #1117302, was opened at 2005-02-06 15:04 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Birnie (pbirnie) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLParser Initial Comment: sgmllib.SGMLParser calls start tag and end_methods correctly until it encounters One
Two Three the
seems to cause its parsing to become confused and I conly get call backs for tag a twice (link 1 and 3) ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:14 Message: Logged In: YES user_id=38376 footnote 3: for the link case, also note that the HTMLParser module handles this in a more practical way (that is, it limits itself to SGML features that's actually used on the web). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:03 Message: Logged In: YES user_id=38376 footnote 2: if you need to deal with broken HTML, use TidyLib: http://utidylib.berlios.de/ http://effbot.org/zone/element-tidylib.htm ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:01 Message: Logged In: YES user_id=38376 footnote:
is an XML construct, and is not valid HTML. In HTML, "blah", so the BR section is parsed as START br DATA >Two< END br DATA a> which is 100% correct. For more on this topic, see: http://www.cs.tut.fi/~jkorpela/html/empty.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 From noreply at sourceforge.net Tue Feb 8 09:27:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 09:27:07 2005 Subject: [ python-Bugs-1116571 ] Wrong match with regex, non-greedy problem Message-ID: Bugs item #1116571, was opened at 2005-02-05 01:12 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: rengel (engel_re) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Wrong match with regex, non-greedy problem Initial Comment: # This is executable. # My test string ist rather long: tst = "In this Buch, used to designate Dinge der Wirklichkeit rather than SW Ent." # I want to match the last part of the string: # SW Ent # So I define the following pattern an compile it: pat = r"(.*?) (.*?)" rex = re.compile(pat) # Then I search the string to get a match group : mat = rex.search(tst) # If found, print the group if mat: print mat.group() # Instead of # SW Ent # I get the whole string starting with # Buch... # up to the very last # Apparently the non-greedy operator doesn't work correctly. # What's wrong? ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:27 Message: Logged In: YES user_id=38376 Search returns the first (left-most) location where the pattern matches, if any. The non-greedy operator only guarantees that you get the shortest possible match at that location. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 From noreply at sourceforge.net Tue Feb 8 17:26:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 17:26:18 2005 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-09 01:26 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=1118729&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Tue Feb 8 22:40:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 8 22:40:28 2005 Subject: [ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req. Message-ID: Bugs item #1112856, was opened at 2005-01-31 01:58 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req. Initial Comment: Patch 1079734 "Make cgi.py use email instead of rfc822 or mimetools" seems to have broken the cgi.FieldStorage in cases where the request is a multipart post (for instance, when a file upload form field is used). See the attached test program. With cgi.py revision <1.83 (python 2.4 for instance) I get the expected results; 374 FieldStorage(None, None, [FieldStorage('param1', None, 'Value of param1'), FieldStorage('param2', None, 'Value of param2'), FieldStorage('file', '', ''), FieldStorage(None, None, '')]) but with cgi.py rev 1.83 (current) I get this: 374 FieldStorage(None, None, [FieldStorage('param1', None, '')]) Another thing that I observed (which isn't reproduced by this test program) is that cgi.FieldStorage.__init__ never completes when the fp is a socket-file (and the request is again a multipart post). It worked fine with the old cgi.py. ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2005-02-08 22:40 Message: Logged In: YES user_id=129426 I've added a test that shows the 'freezing' problem I talked about. Start the server.py, it will listen on port 9000. Open the post.html in your web browser, enter some form data, and submit the form. It will POST to the server.py and if you started that one with cvs-python (2.5a0) it will freeze on the marked line. If you start server.py with Python 2.4, it will work fine. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-06 23:58 Message: Logged In: YES user_id=129426 Yes, I'll try to make a test case for that within the next few days. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-05 00:02 Message: Logged In: YES user_id=693077 Irmen, can you try to create a test case where the cgi.FieldStorage never completes, so I can make sure that any fix I come up with resolves it? I will try to put together an implementation where the email parser parses the whole multipart message. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-02-04 23:06 Message: Logged In: YES user_id=129426 Johannes: while your patch makes my cgibug.py test case run fine, it has 2 problems: 1- it runs much slower than the python2.4 code (probably because of the reading back thing Josh is talking about); 2- it still doesn't fix the second problem that I observed: cgi.FieldStorage never completes when fp is a socket. I don't have a separate test case for this yet, sorry. So Josh: perhaps your idea doesn't have these 2 problems? ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 16:45 Message: Logged In: YES user_id=693077 Johannes, your patch looks fine to me. It would be nice if we didn't have to keep reading back each part from the parsed message, though. I had an idea for another approach. Use email to parse the MIME message fully, then convert it to FieldStorage fields. Parsing could go something like: == CODE == from email.FeedParser import FeedParser parser = FeedParser() # Create bogus content-type header... parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' % (self.type, self.innerboundary)) parser.feed(self.fp.read()) message = parser.close() # Then take parsed message and convert to FieldStorage fields == END CODE == This lets the email parser handle all of the complexities of MIME, but it does mean that we have to accurately re-create all of the necessary headers. I can cook up a full patch if anyone thinks this would fly. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-04 11:15 Message: Logged In: YES user_id=469548 Here's a patch. We're interested in two things in the patched loop: * the rest of the multipart/form-data, including the headers for the current part, for consumption by HeaderParser (this is the tail variable) * the rest of the multipart/form-data without the headers for the current part, for consumption by FieldStorage (this is the message.get_payload() call) Josh, Irmen, do you see any problems with this patch? (BTW, this fix should be ported to the parse_multipart function as well, when I check it in (and I should make cgibug.py into a test)) ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2005-02-04 08:21 Message: Logged In: YES user_id=693077 The email.HeaderParser module that is now used for parsing headers consumes the rest of the body of the message when it is used. If there was some way of telling the parser to stop reading when it got to the end of the headers, I think this problem would be fixed. Unfortunately, there is no external interface to the email module's parser that lets us do this. I hope we can come up with a reasonable solution that does not involve reverting to using deprecated modules. Thanks for the test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Wed Feb 9 00:42:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 00:42:05 2005 Subject: [ python-Bugs-1118977 ] builtin file() vanishes Message-ID: Bugs item #1118977, was opened at 2005-02-08 23: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=1118977&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: builtin file() vanishes Initial Comment: The attached files reproduce a wierd problem where by the builtin file() function completely vanishes from python. Notice that __builtin__ changes type from module to dict. In the attached tar files find: manufacture - main program bob.py - module a.a - file to open Untar and run: python manufacture Notice that file()is no ware to be found in side of bob.py This runs the same on all 2.3 and 2.4 on Windows, Linux and Mac OS X. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118977&group_id=5470 From noreply at sourceforge.net Wed Feb 9 04:51:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 04:51:54 2005 Subject: [ python-Bugs-1118977 ] builtin file() vanishes Message-ID: Bugs item #1118977, was opened at 2005-02-08 18: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=1118977&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: builtin file() vanishes Initial Comment: The attached files reproduce a wierd problem where by the builtin file() function completely vanishes from python. Notice that __builtin__ changes type from module to dict. In the attached tar files find: manufacture - main program bob.py - module a.a - file to open Untar and run: python manufacture Notice that file()is no ware to be found in side of bob.py This runs the same on all 2.3 and 2.4 on Windows, Linux and Mac OS X. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-08 22:51 Message: Logged In: YES user_id=31435 No, __builtins__ (note the trailing 's') changes type from module to module, not __builtin__. __builtins__ is an implementation detail, and you shouldn't use it at all. __builtin__ (no trailing 's') is a built-in module, and you're free to use that, but then you have to import it explicitly: import __builtin__ __builtin__.file There's more in the Language (not Library) reference manual, in the section "Naming and Binding". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118977&group_id=5470 From noreply at sourceforge.net Wed Feb 9 14:27:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 14:27:47 2005 Subject: [ python-Bugs-1119282 ] Docs for set() omit constructor Message-ID: Bugs item #1119282, was opened at 2005-02-09 13: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=1119282&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for set() omit constructor Initial Comment: The documentation for set() and frozenset() in the library reference section 2.3.7 has no explicit description of how to create a set or frozenset. IOW, nowhere does it say what the argument(s) to set() and frozenset() are. The text from section 5.15 (the sets module) should be usable here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 From noreply at sourceforge.net Wed Feb 9 14:37:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 14:37:50 2005 Subject: [ python-Bugs-1119282 ] Docs for set() omit constructor Message-ID: Bugs item #1119282, was opened at 2005-02-09 13:27 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for set() omit constructor Initial Comment: The documentation for set() and frozenset() in the library reference section 2.3.7 has no explicit description of how to create a set or frozenset. IOW, nowhere does it say what the argument(s) to set() and frozenset() are. The text from section 5.15 (the sets module) should be usable here. ---------------------------------------------------------------------- >Comment By: Kent Johnson (kjohnson) Date: 2005-02-09 13:37 Message: Logged In: YES user_id=49695 Ah, it's documented in section 2.1, Built-in Functions. A cross-reference from section 2.3.7 might be helpful...e.g. "Instances of set and frozenset may be created by calling the set() and frozenset() built-in functions; see Section 2.1, Built-in Functions, for details." BTW the same suggestion applies for dict(), list() and tuple() - some mention of them in sections 2.3.6 and 2.3.8 seems appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 From noreply at sourceforge.net Wed Feb 9 15:51:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 15:51:09 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 08: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=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Wed Feb 9 17:57:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 17:57:09 2005 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 16: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=1119418&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Wed Feb 9 18:17:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 18:17:55 2005 Subject: [ python-Bugs-1119439 ] Python Programming FAQ should be updated for Python 2.4 Message-ID: Bugs item #1119439, was opened at 2005-02-09 17: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=1119439&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Python Programming FAQ should be updated for Python 2.4 Initial Comment: For example: * "1.4.3 How do I iterate over a sequence in reverse order?" should use reversed() * "1.4.4 How do you remove duplicates from a list?" should use set() * "1.5.2 I want to do a complicated sort: can you do a Schwartzian Transform in Python?" should use sort(key=) * section 1.6 should use new-style classes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119439&group_id=5470 From noreply at sourceforge.net Wed Feb 9 19:45:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 19:45:36 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 14:51 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-09 18:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Wed Feb 9 19:51:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 19:51:11 2005 Subject: [ python-Bugs-1119282 ] Docs for set() omit constructor Message-ID: Bugs item #1119282, was opened at 2005-02-09 08:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for set() omit constructor Initial Comment: The documentation for set() and frozenset() in the library reference section 2.3.7 has no explicit description of how to create a set or frozenset. IOW, nowhere does it say what the argument(s) to set() and frozenset() are. The text from section 5.15 (the sets module) should be usable here. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-09 13:51 Message: Logged In: YES user_id=80475 Following the style for list(), dict(), and tuple(), the constructor for set() and frozenset() is documented in section 2.1 (builtin functions). ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2005-02-09 08:37 Message: Logged In: YES user_id=49695 Ah, it's documented in section 2.1, Built-in Functions. A cross-reference from section 2.3.7 might be helpful...e.g. "Instances of set and frozenset may be created by calling the set() and frozenset() built-in functions; see Section 2.1, Built-in Functions, for details." BTW the same suggestion applies for dict(), list() and tuple() - some mention of them in sections 2.3.6 and 2.3.8 seems appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 From noreply at sourceforge.net Wed Feb 9 19:54:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 19:54:53 2005 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-08 17:26 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-09 19:54 Message: Logged In: YES user_id=51702 What you are seeing is negative zero (-0.0). It is distinct from positive zero (0.0) but 0.0 == -0.0 is always true. On some machines you can also see it by typing: >>> -0.0 -0.0 On other machines you will see "0.0" instead. You can also try printf("%f\n", -0.0); and you will notice the same thing. So I'm not sure it is a bug per se. However, it can be worked around by adding "if (v->cval.imag == 0.) v->cval.imag = 0.0;" to complexobject.c, assuming ofcourse it is OK to change negative zeros to positive ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Wed Feb 9 20:49:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 20:49:53 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 08:51 Message generated for change (Comment added) made by jrlilly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 12:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Wed Feb 9 20:51:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 20:51:25 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 08:51 Message generated for change (Comment added) made by jrlilly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:51 Message: Logged In: YES user_id=774886 that is any return of 0 from newterm ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 12:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Wed Feb 9 23:22:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 23:22:59 2005 Subject: [ python-Bugs-1119673 ] ScrolledText allows Frame.bbox to hide Text.bbox Message-ID: Bugs item #1119673, was opened at 2005-02-09 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=1119673&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Martin v. L?wis (loewis) Summary: ScrolledText allows Frame.bbox to hide Text.bbox Initial Comment: sys.version == '2.3.3a0 (#3, Jul 20 2004, 10:32:48) \n[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)]' from ScrolledText import ScrolledText s = ScrolledText() s.pack() I wish to call bbox on the Text, but s.bbox is the surrounding Frame's bbox, and the Text's bbox method is lost. I suppose these lines from ScrolledText.py should be expanded to include 'bbox', but I have not tested such a fix: if m[0] != '_' and m != 'config' and m != 'configure': setattr(self, m, getattr(self.frame, m)) For special situations (of which bbox is probably *not* one), the Text methods should probably be available under something like s.text.bbox(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119673&group_id=5470 From noreply at sourceforge.net Wed Feb 9 23:36:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 9 23:36:45 2005 Subject: [ python-Bugs-1119673 ] ScrolledText allows Frame.bbox to hide Text.bbox Message-ID: Bugs item #1119673, was opened at 2005-02-09 13:22 Message generated for change (Comment added) made by drewp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119673&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Martin v. L?wis (loewis) Summary: ScrolledText allows Frame.bbox to hide Text.bbox Initial Comment: sys.version == '2.3.3a0 (#3, Jul 20 2004, 10:32:48) \n[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)]' from ScrolledText import ScrolledText s = ScrolledText() s.pack() I wish to call bbox on the Text, but s.bbox is the surrounding Frame's bbox, and the Text's bbox method is lost. I suppose these lines from ScrolledText.py should be expanded to include 'bbox', but I have not tested such a fix: if m[0] != '_' and m != 'config' and m != 'configure': setattr(self, m, getattr(self.frame, m)) For special situations (of which bbox is probably *not* one), the Text methods should probably be available under something like s.text.bbox(). ---------------------------------------------------------------------- >Comment By: Drew Perttula (drewp) Date: 2005-02-09 13:36 Message: Logged In: YES user_id=127598 A workaround: s = ScrolledText() new.instancemethod(Text.bbox,s,s.__class__)(...) but, I actually have a subclass of ScrolledText, and I can't figure out how to use the workaround. class Foo(ScrolledText): ... def foo(self): ... ... new.instancemethod(tk.Text.bbox, self, self.__class__)("insert") TypeError: unbound method bbox() must be called with Text instance as first argument (got Foo instance instead) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119673&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:05:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:05:34 2005 Subject: [ python-Bugs-1119700 ] list extend() accepts args besides lists Message-ID: Bugs item #1119700, was opened at 2005-02-09 15: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=1119700&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan Everhart (dieseldann) Assigned to: Nobody/Anonymous (nobody) Summary: list extend() accepts args besides lists Initial Comment: In section 2.3.6.4 of the PYthon Library Reference, Note (3) says that extend() raises and exception when its argument is not a list object. Extend does accept a tuple without complaint, and does the expected thing. The note should correctly specify what is acceptable as an argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119700&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:19:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:19:47 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 14:51 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-09 23:19 Message: Logged In: YES user_id=6656 Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I guess... ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 19:51 Message: Logged In: YES user_id=774886 that is any return of 0 from newterm ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 19:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 18:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:20:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:20:42 2005 Subject: [ python-Bugs-1119700 ] list extend() accepts args besides lists Message-ID: Bugs item #1119700, was opened at 2005-02-09 18:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119700&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dan Everhart (dieseldann) Assigned to: Nobody/Anonymous (nobody) Summary: list extend() accepts args besides lists Initial Comment: In section 2.3.6.4 of the PYthon Library Reference, Note (3) says that extend() raises and exception when its argument is not a list object. Extend does accept a tuple without complaint, and does the expected thing. The note should correctly specify what is acceptable as an argument. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-09 18:20 Message: Logged In: YES user_id=80475 Fixed. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119700&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:23:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:23:29 2005 Subject: [ python-Bugs-1119282 ] Docs for set() omit constructor Message-ID: Bugs item #1119282, was opened at 2005-02-09 08:27 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for set() omit constructor Initial Comment: The documentation for set() and frozenset() in the library reference section 2.3.7 has no explicit description of how to create a set or frozenset. IOW, nowhere does it say what the argument(s) to set() and frozenset() are. The text from section 5.15 (the sets module) should be usable here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-09 13:51 Message: Logged In: YES user_id=80475 Following the style for list(), dict(), and tuple(), the constructor for set() and frozenset() is documented in section 2.1 (builtin functions). ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2005-02-09 08:37 Message: Logged In: YES user_id=49695 Ah, it's documented in section 2.1, Built-in Functions. A cross-reference from section 2.3.7 might be helpful...e.g. "Instances of set and frozenset may be created by calling the set() and frozenset() built-in functions; see Section 2.1, Built-in Functions, for details." BTW the same suggestion applies for dict(), list() and tuple() - some mention of them in sections 2.3.6 and 2.3.8 seems appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119282&group_id=5470 From noreply at sourceforge.net Thu Feb 10 00:24:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 00:24:26 2005 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 11:57 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Thu Feb 10 01:02:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 01:02:14 2005 Subject: [ python-Bugs-1118729 ] Error in representation of complex numbers(again) Message-ID: Bugs item #1118729, was opened at 2005-02-09 01:26 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Error in representation of complex numbers(again) Initial Comment: >>> -(1+0j) (-1+-0j) I encountered this while I was calculating conjugate of complex numbers(e.g. z.conjugate()). Related bug * http://www.python.org/sf/1013908 One thing to note is that -(0j) can return 0j or -0j dependeing on OSes. Confirmed on SuSE 9.1 & cygwin. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2005-02-10 09:02 Message: Logged In: YES user_id=671362 Hi, Bj?rn. Sorry, not to be clear about what my complaint is. I'm not talking about if -(0j) should be 0j or -0j. It's been that way for a long time, so changing it would break old codes. My point is the signature of imaginary part. As you can see, it's represented as '+-'. Before the commit of patch #774665, it was represented as '-1-0j'. But after that, '-1+-0j'. If you test it with Python <= 2.3, you'll get (-1-0j) and I think this is how -(1+0j) should be represented on machines where - (0j) is represented as -0j. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-02-10 03:54 Message: Logged In: YES user_id=51702 What you are seeing is negative zero (-0.0). It is distinct from positive zero (0.0) but 0.0 == -0.0 is always true. On some machines you can also see it by typing: >>> -0.0 -0.0 On other machines you will see "0.0" instead. You can also try printf("%f\n", -0.0); and you will notice the same thing. So I'm not sure it is a bug per se. However, it can be worked around by adding "if (v->cval.imag == 0.) v->cval.imag = 0.0;" to complexobject.c, assuming ofcourse it is OK to change negative zeros to positive ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470 From noreply at sourceforge.net Thu Feb 10 01:02:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 01:02:26 2005 Subject: [ python-Bugs-1118977 ] builtin file() vanishes Message-ID: Bugs item #1118977, was opened at 2005-02-09 00:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118977&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: builtin file() vanishes Initial Comment: The attached files reproduce a wierd problem where by the builtin file() function completely vanishes from python. Notice that __builtin__ changes type from module to dict. In the attached tar files find: manufacture - main program bob.py - module a.a - file to open Untar and run: python manufacture Notice that file()is no ware to be found in side of bob.py This runs the same on all 2.3 and 2.4 on Windows, Linux and Mac OS X. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 01:02 Message: Logged In: YES user_id=21627 As Tim says, __builtins__ is a dictionary sometimes. Therefore, it is no surprise that __builtins__.file does not exist - dictionaries don't have a file attribute. As this is apparently what you meant when you said that file() "vanishes", I'm closing the report as invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-09 04:51 Message: Logged In: YES user_id=31435 No, __builtins__ (note the trailing 's') changes type from module to module, not __builtin__. __builtins__ is an implementation detail, and you shouldn't use it at all. __builtin__ (no trailing 's') is a built-in module, and you're free to use that, but then you have to import it explicitly: import __builtin__ __builtin__.file There's more in the Language (not Library) reference manual, in the section "Naming and Binding". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118977&group_id=5470 From noreply at sourceforge.net Thu Feb 10 01:06:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 01:06:57 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 08:51 Message generated for change (Comment added) made by jrlilly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 18:06 Message: Logged In: YES user_id=774886 if you pass setupterm 0 for the term name it just tries to get the env variable, so the env test should cover it pretty well. It might make more sense to check the env first and then pass "unkown", setuperm("unknown", -1). This would seem to match the path that curses initscr follows. This would also raise _curses and curses shared exception. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 17:19 Message: Logged In: YES user_id=6656 Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I guess... ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:51 Message: Logged In: YES user_id=774886 that is any return of 0 from newterm ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 12:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Thu Feb 10 01:33:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 01:33:39 2005 Subject: [ python-Bugs-1117761 ] BSDDB openhash Message-ID: Bugs item #1117761, was opened at 2005-02-07 10:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) Assigned to: Nobody/Anonymous (nobody) Summary: BSDDB openhash Initial Comment: Python 2.4 (#1, Dec 8 2004, 18:57:30) [GCC 3.3.3 (SuSE Linux)] on linux2 >>> import bsddb >>> h = bsddb.hashopen('test','c',cachesize=100) Traceback (most recent call last): File "", line 1, in ? File "/home/alex/DLD/lib/python2.4/bsddb/__init__.py", line 288, in hashopen bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- DB->set_cachesize: method not permitted in shared environment') I replace bsddb.hashopen with a 2.3.3 version and it works. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 01:33 Message: Logged In: YES user_id=21627 Apparently, this is caused by hashopen now allocated a DBEnv. This, in turn, is necessary to allow multiple threads to access the same database simultaneously. I'm unsure why bsddb does not support shared access and having a cache size simultaneously; it might be best to disallow the cachesize argument, and require users who want to specify it to use DB.open explicitly (with no environment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&group_id=5470 From noreply at sourceforge.net Thu Feb 10 01:37:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 01:37:06 2005 Subject: [ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug Message-ID: Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 From noreply at sourceforge.net Thu Feb 10 07:22:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 07:22:42 2005 Subject: [ python-Feature Requests-489106 ] commands.mkarg function should be public Message-ID: Feature Requests item #489106, was opened at 2001-12-04 14:40 Message generated for change (Comment added) made by donut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489106&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: commands.mkarg function should be public Initial Comment: There is a strange ommision in the commands module, you can safely get the ls -ld of a file since it shell-quotes its argument, but yet you cannot safely run other commands since the mkarg function isn't "public" (well, not if you only follow the docs, or do import *). In addition, since commands.py seems to be unix only, it would be better for the mkarg functionality to be moved to the os module so that on other OSes you could use it with os.system, etc. (well, I guess maybe it would belong in the os-specific modules like posix, nt, etc, since its probably varies) (Though it should probably be given a better name in that case, like os.mkshellarg or somesuch.) ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2005-02-09 23:22 Message: Logged In: YES user_id=65253 With the addition of the subprocess module in Python 2.4, I think this is no longer necessary. Therefore, I am closing it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489106&group_id=5470 From noreply at sourceforge.net Thu Feb 10 08:29:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 08:29:17 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 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=1119860&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Thu Feb 10 08:40:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 08:40:40 2005 Subject: [ python-Bugs-1119866 ] Static library incompatible with nptl Message-ID: Bugs item #1119866, was opened at 2005-02-10 08:40 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=1119866&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119866&group_id=5470 From noreply at sourceforge.net Thu Feb 10 08:41:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 08:41:49 2005 Subject: [ python-Bugs-1119866 ] Static library incompatible with nptl Message-ID: Bugs item #1119866, was opened at 2005-02-10 08:40 Message generated for change (Settings changed) made by ekloef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119866&group_id=5470 Category: Threads Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119866&group_id=5470 From noreply at sourceforge.net Thu Feb 10 12:22:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 12:22:41 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 14:51 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-10 11:22 Message: Logged In: YES user_id=6656 The motivation for calling setupterm() ourselves was that I noticed TERM=garbage python -c 'import curses; curses.initscr()' hit the irritating error path too. I also hadn't realised there was a version of initscr in curses/__init__.py, which makes things easier... how about the attached? ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-10 00:06 Message: Logged In: YES user_id=774886 if you pass setupterm 0 for the term name it just tries to get the env variable, so the env test should cover it pretty well. It might make more sense to check the env first and then pass "unkown", setuperm("unknown", -1). This would seem to match the path that curses initscr follows. This would also raise _curses and curses shared exception. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 23:19 Message: Logged In: YES user_id=6656 Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I guess... ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 19:51 Message: Logged In: YES user_id=774886 that is any return of 0 from newterm ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 19:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 18:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Thu Feb 10 14:41:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 10 14:41:39 2005 Subject: [ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set Message-ID: Bugs item #1119331, was opened at 2005-02-09 08:51 Message generated for change (Comment added) made by jrlilly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jacob Lilly (jrlilly) Assigned to: Nobody/Anonymous (nobody) Summary: curses.initscr - initscr exit w/o env(TERM) set Initial Comment: the initscr in ncurses will cause an immeadiation exit if the env doesn't have the TERM variable set. Could the curses.initscr be changed so it tests if TERM is set and raises an exception? It would be helpful to be able to try and except this instead of just having ncurses exit for you. ---------------------------------------------------------------------- >Comment By: Jacob Lilly (jrlilly) Date: 2005-02-10 07:41 Message: Logged In: YES user_id=774886 The only thing that worries me about that is it takes a different path than ncurses does (or at least 5.4 does). If the env variable isn't set, initscr in ncurses assumes the term type is "unknown" (if no env) and passes "unknown" along, whereas setupterm assumes that if you pass it NULL for the term and the env isn't set, then it simply returns 0. I doubt anyone will have a valid term setup for unknown, but who knows. Beyound that works for me. BTW, the gnu ncurses guys say this is the the behavior in the standard. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-10 05:22 Message: Logged In: YES user_id=6656 The motivation for calling setupterm() ourselves was that I noticed TERM=garbage python -c 'import curses; curses.initscr()' hit the irritating error path too. I also hadn't realised there was a version of initscr in curses/__init__.py, which makes things easier... how about the attached? ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 18:06 Message: Logged In: YES user_id=774886 if you pass setupterm 0 for the term name it just tries to get the env variable, so the env test should cover it pretty well. It might make more sense to check the env first and then pass "unkown", setuperm("unknown", -1). This would seem to match the path that curses initscr follows. This would also raise _curses and curses shared exception. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 17:19 Message: Logged In: YES user_id=6656 Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I guess... ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:51 Message: Logged In: YES user_id=774886 that is any return of 0 from newterm ---------------------------------------------------------------------- Comment By: Jacob Lilly (jrlilly) Date: 2005-02-09 13:49 Message: Logged In: YES user_id=774886 sorry, I should have done that in the beginning; I have it raising a RuntimeError, I think thats what it is. This doesn't really solve the problem in whole, since ncurses initscr has lots of ways it could decide to decide to exit (any return value from newterm causes it to exit), but it does solve a more common one. Anything else would require modifying ncruses to be responsible. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 12:45 Message: Logged In: YES user_id=6656 How amazingly terrible (on ncurses part). Do you want to/are you able to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470 From noreply at sourceforge.net Fri Feb 11 01:04:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 01:04:12 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-11 01: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=1120452&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Fri Feb 11 04:45:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 04:46:02 2005 Subject: [ python-Feature Requests-1087418 ] long int bitwise ops speedup (patch included) Message-ID: Feature Requests item #1087418, was opened at 2004-12-18 00:22 Message generated for change (Comment added) made by gregsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: long int bitwise ops speedup (patch included) Initial Comment: The 'inner loop' for applying bitwise ops to longs is quite inefficient. The improvement in the attached diff is - 'a' is never shorter than 'b' (result: only test 1 loop index condition instead of 3) - each operation ( & | ^ ) has its own loop, instead of switch inside loop - I found that, when this is done, a lot of things can be simplified, resulting in further speedup, and the resulting code is not very much longer than before (my libpython2.4.dll .text got 140 bytes longer). Operations on longs of a few thousand bits appear to be 2 ... 2.5 times faster with this patch. I'm not 100% sure the code is right, but it passes test_long.py, anyway. ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2005-02-10 22:45 Message: Logged In: YES user_id=292741 I started by just factoring out the inner switch loop. But then it becomes evident that when op = '^', you always have maska == maskb, so there's no point in doing the ^mask at all. And when op == '|', then maska==maskb==0. So likewise. And if you put a check in so that len(a) >= len(b), then the calculation of len_z can be simplified. It also becomes easy to break the end off the loops, so that, say, or'ing a small number with a really long becomes mostly a copy. etc. It's was just a series of small simple changes following from the refactoring of the loop/switch. I see a repeatable 1.5 x speedup at 300 bits, which I think is significant (I wasn't using negative #s, which of course have their own extra overhead). The difference should be even higher on CPUs that don't have several 100 mW of branch-prediction circuitry. One use case is that you can simulate an array of hundreds or thousands of simple 1-bit processors in pure python using long operations, and get very good performance, even better with this fix. This app involves all logical ops, with the occasional shift. IMHO, I don't think the changed code is more complex; it's a little longer, but it's more explicit in what is really being done, and it doesn't roll together 3 cases, which don't really have that much in common, for the sake of brevity. It wasn't obvious to me about the masks being redundant until after I did the factoring, and this is my point - rolling it together hides that. The original author may not have noticed the redundancy. I see a lot of effort being expended on very complex multiply operations, why should the logical ops be left behind for the sake of a few lines? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-07 01:54 Message: Logged In: YES user_id=80475 Patch Review ------------ On Windows using MSC 6.0, I could only reproduce about a small speedup at around 300 bits. While the patch is short, it adds quite a bit of complexity to the routine. Its correctness is not self-evident or certain. Even if correct, it is likely to encumber future maintenance. Unless you have important use cases and feel strongly about it, I think this one should probably not go in. An alternative to submit a patch that limits its scope to factoring out the innermost switch/case. I tried that and found that the speedup is microscopic. I suspect that that one unpredictable branch is not much of a bottleneck. More time is likely spent on creating z. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2005-01-03 14:54 Message: Logged In: YES user_id=292741 I originally timed this on a cygwin system, I've since found that cygwin timings tend to be strange and possibly misleading. On a RH8 system, I'm seeing speedup of x3.5 with longs of ~1500 bits and larger, and x1.5 speedup with only about 300 bits. Times were measured with timeit.Timer( 'a|b', 'a=...; b=...') Increase in .text size is likewise about 120 bytes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 From noreply at sourceforge.net Fri Feb 11 14:54:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 14:54:04 2005 Subject: [ python-Bugs-1120777 ] bug in unichr() documentation Message-ID: Bugs item #1120777, was opened at 2005-02-11 13: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=1120777&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marko Kreen (mkz) Assigned to: Nobody/Anonymous (nobody) Summary: bug in unichr() documentation Initial Comment: http://www.python.org/doc/2.4/lib/built-in-funcs.html: > Return the Unicode string of one character whose Unicode > code is the integer i. > [...] > The argument must be in the range [0..65535], inclusive. unichr.__doc_ says: > Return a Unicode string of one character with ordinal i; 0 <= i <= 0x10ffff. Which is correct? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&group_id=5470 From noreply at sourceforge.net Fri Feb 11 15:03:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 15:03:06 2005 Subject: [ python-Bugs-1120777 ] bug in unichr() documentation Message-ID: Bugs item #1120777, was opened at 2005-02-11 14:54 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marko Kreen (mkz) Assigned to: Nobody/Anonymous (nobody) Summary: bug in unichr() documentation Initial Comment: http://www.python.org/doc/2.4/lib/built-in-funcs.html: > Return the Unicode string of one character whose Unicode > code is the integer i. > [...] > The argument must be in the range [0..65535], inclusive. unichr.__doc_ says: > Return a Unicode string of one character with ordinal i; 0 <= i <= 0x10ffff. Which is correct? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-11 15:03 Message: Logged In: YES user_id=38388 Whether unichr() handles the UCS2 or the UCS4 range depends on the configuration option you set at Python compile time. Perhaps we should extend the documentation to mention this difference ?! Doc patches are welcome :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&group_id=5470 From noreply at sourceforge.net Fri Feb 11 15:38:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 15:38:21 2005 Subject: [ python-Bugs-1120777 ] bug in unichr() documentation Message-ID: Bugs item #1120777, was opened at 2005-02-11 13:54 Message generated for change (Comment added) made by mkz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marko Kreen (mkz) Assigned to: Nobody/Anonymous (nobody) Summary: bug in unichr() documentation Initial Comment: http://www.python.org/doc/2.4/lib/built-in-funcs.html: > Return the Unicode string of one character whose Unicode > code is the integer i. > [...] > The argument must be in the range [0..65535], inclusive. unichr.__doc_ says: > Return a Unicode string of one character with ordinal i; 0 <= i <= 0x10ffff. Which is correct? ---------------------------------------------------------------------- >Comment By: Marko Kreen (mkz) Date: 2005-02-11 14:38 Message: Logged In: YES user_id=894541 Main problem for me was that the 65535 hints that unichr() may want UTF-16 values not Unicode. That was rather confusing. Ok, attached path clarifies unichr() range. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-11 14:03 Message: Logged In: YES user_id=38388 Whether unichr() handles the UCS2 or the UCS4 range depends on the configuration option you set at Python compile time. Perhaps we should extend the documentation to mention this difference ?! Doc patches are welcome :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120777&group_id=5470 From noreply at sourceforge.net Fri Feb 11 15:57:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 15:57:24 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-11 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-11 14:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Fri Feb 11 16:43:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 16:43:05 2005 Subject: [ python-Bugs-1120862 ] Problem in join function definition Message-ID: Bugs item #1120862, was opened at 2005-02-11 15:43 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=1120862&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: yseb (yseb) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in join function definition Initial Comment: There is a problem in the last sentence of the join definition. ========================================== join( words[, sep]) Concatenate a list or tuple of words with intervening occurrences of sep. The default value for sep is a single space character. It is always true that "string.join (string.split(s, sep), sep)" equals s. ========================================== It is true that string.join(string.split(s, sep), sep)" is always equals to s. But string.join(string.split(s)) is not always equals to s especially for repeated sequence of spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 From noreply at sourceforge.net Fri Feb 11 18:23:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 18:24:02 2005 Subject: [ python-Bugs-919614 ] Python configured with --disable-unicode fails tests, more Message-ID: Bugs item #919614, was opened at 2004-03-19 11:23 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919614&group_id=5470 Category: Installation >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Python configured with --disable-unicode fails tests, more Initial Comment: When building Python with: ./configure --disable-unicode the test suite has many spurious failures because modules and tests assume that unicode support is available. Installing this Python (using "make install") fails at the end of the first run of compileall.py, since that script detects and reports failures; the output contains many lines with the message Sorry: ValueError: ('Unicode escapes not legal when Unicode disabled',) This should be fixed, or --disable-unicode should be removed. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 12:23 Message: Logged In: YES user_id=3066 The trunk and release24-maint branch will no longer compile with --diable-unicode. I get the following error message from the trunk: c++ -pthread -Xlinker -export-dynamic -o python Modules/python.o libpython2.5.a -lpthread -ldl -lutil -lm libpython2.5.a(posixmodule.o)(.text+0x39a0): In function `posix_tmpnam': ../Modules/posixmodule.c:6161: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp' libpython2.5.a(posixmodule.o)(.text+0x3906): In function `posix_tempnam': ../Modules/posixmodule.c:6116: warning: the use of `tempnam' is dangerous, better use `mkstemp' libpython2.5.a(_codecsmodule.o)(.text+0xf9): In function `codec_encode': ../Modules/_codecsmodule.c:108: undefined reference to `PyUnicode_GetDefaultEncoding' libpython2.5.a(_codecsmodule.o)(.text+0x165): In function `codec_decode': ../Modules/_codecsmodule.c:141: undefined reference to `PyUnicode_GetDefaultEncoding' collect2: ld returned 1 exit status The release24-maint branch gives similar results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919614&group_id=5470 From noreply at sourceforge.net Fri Feb 11 19:06:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 19:06:21 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 01:25 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 13:06 Message: Logged In: YES user_id=3066 Fixed for Python 2.4.1 and 2.5: Lib/xmlrpclib.py 1.36.2.1, 1.40 Lib/test/test_xmlrpc.py 1.5.4.1, 1.7 I committed the attached patch and added a unit test. Python 2.3 got left out since this doesn't seem critical enough to destabilize old applications. I won't strongly object if someone backports it to 2.3.6, if they actually think there's going to be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Fri Feb 11 20:36:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 20:36:16 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-10 19:04 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 09:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Fri Feb 11 20:55:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 11 20:55:55 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-10 19:04 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 09:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Sat Feb 12 01:36:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 01:36:42 2005 Subject: [ python-Bugs-1121152 ] file seek error Message-ID: Bugs item #1121152, was opened at 2005-02-11 17: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=1121152&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Lawhorn (lawhorn999) Assigned to: Nobody/Anonymous (nobody) Summary: file seek error Initial Comment: When opening a file for overwrite ("rb+"), sucessive read/writes fail to advance the pointer. The tell() indicates that the pointer is advancing, but the resulting file simply repeats an earlier record. See attached file for an example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121152&group_id=5470 From noreply at sourceforge.net Sat Feb 12 01:51:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 01:51:36 2005 Subject: [ python-Feature Requests-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname Message-ID: Feature Requests item #1110010, was opened at 2005-01-26 17:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname Initial Comment: One of the side effects of the new-style classes is that objects don't necessarily have __dict__ attached to them. It used to be possible to write things like def __str__(self): return "Node %(name)s, %(nlinks)d links, active: %(active)s" % self.__dict__ ... but this doesn't work if the class doesn't have a __dict__. Even if does, I'm not sure it will always get members from base classes. There is a 'vars' function; you could put 'vars(self)' in the above instead of self.__dict__, but it still doesn't work if the class doesn't have a __dict__. I can see different solutions for this: (1) change the 'string %' operator so that it allows %(.name)s, leading to a getattr() on the right-side argument rather than a getitem. return "Node %(.name)s, %(.nlinks)d links, active: %(.active)s" % self (2) Make a builtin like vars, but which works when the object doesn't have a __dict__ I.e. attrmap(x) would return a mapping which is bound to x, and reading attrmap(x)['attname'] is the same as getattr(x,'attname'). Thus return "Node %(name)s, %(nlinks)d links, active: %(active)s" % attrmap(self) This attrmap() function can be implemented in pure python, of course. I originally thought (1) made a lot of sense, but (2) seems to work just as well and doesn't require changing much. Also, (1) allows cases like "%(name)s %(.name2)s", which are not very useful, but are very likely to be created by accident; whereas in (2) you are deciding on the right of the '%' whether you are naming attributes or providing mapping keys. I'm not sure it's a good idea change 'vars' to have this behaviour, since vars(x).keys() currently works in a predictable way when vars(x) works; whereas attrmap(x).keys() may not be complete, or possible, even when attrmap(x) is useful. I.e. when x has a __getattr__ defined. On the other hand, vars(x) doesn't currently do much at all, so maybe it's possible to enhance it like this without breaking anything. The motivation for this came from the "%(name)s" issue, but the attrmap() function would be useful in other places e.g. processdata( infile, outfile, **attrmap(options)) ... where options might be obtained from optparse, e.g. Or, an attrmap can be used with the new Templates: string.Template('Node $name').substitute( attrmap(node)) Both of these examples will work with vars(), but only when the object actually has __dict__. This is why I'm thinking it may make sense to enhance vars: some code may be broken by the change; but other code, broken by new-style classes, may be unbroken by this change. The proxy could be writable, so that attrmap(x)['a'] = y is the same as x.a = y .. which could have more uses. A possible useful (possibly weird) variation: attrmap accepts 1 or more parameters, and the resulting proxy is bound to all of them. when attrmap(x,y,z)['a'] is done, the proxy will try x.a, y.a, z.a until one of them doesn't raise AttributeError. So it's equivalent to merging dictionaries. This would be useful in the %(name)s or Template cases, where you want information from several objects. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-12 01:51 Message: Logged In: YES user_id=21627 I think I would rather not to see this as a builtin, e.g. putting it into UserDict.AttrMap instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 From noreply at sourceforge.net Sat Feb 12 01:52:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 01:52:14 2005 Subject: [ python-Feature Requests-1104021 ] wishlist: os.feed_urandom(input) Message-ID: Feature Requests item #1104021, was opened at 2005-01-17 17:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: wishlist: os.feed_urandom(input) Initial Comment: Both unixy /dev/randoms and Microsoft's CryptGenRandom offer an API for userland to feed entropy into the system's pool. It would be nice if os.urandom() supported this feature. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-12 01:52 Message: Logged In: YES user_id=21627 Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 From noreply at sourceforge.net Sat Feb 12 02:54:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 02:55:01 2005 Subject: [ python-Bugs-1121152 ] file seek error Message-ID: Bugs item #1121152, was opened at 2005-02-11 19:36 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121152&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard Lawhorn (lawhorn999) Assigned to: Nobody/Anonymous (nobody) Summary: file seek error Initial Comment: When opening a file for overwrite ("rb+"), sucessive read/writes fail to advance the pointer. The tell() indicates that the pointer is advancing, but the resulting file simply repeats an earlier record. See attached file for an example. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-11 20:54 Message: Logged In: YES user_id=31435 Sorry, write the code in C and you'll see the same behavior. For a file opened for update, the effect of input followed by output is undefined unless a file-positioning call is made between the I/O calls; the effect of output followed by input is also undefined, unless a file-positioning call or a call to flush () is made between them. Your comment "This line should NOT be needed" is simply incorrect: you are in fact trying to do input immediately following output. If you want defined behavior, then you must seek between them, and/or flush() after the write(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121152&group_id=5470 From noreply at sourceforge.net Sat Feb 12 03:53:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 03:53:29 2005 Subject: [ python-Bugs-1117048 ] Dictionary Parsing Problem Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Settings changed) made by walterbrunswick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) >Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Sat Feb 12 03:59:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 03:59:11 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 03: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=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Sat Feb 12 04:19:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 04:19:26 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Sat Feb 12 04:30:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 04:30:57 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Sat Feb 12 04:46:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 04:46:51 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-11 21:59 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-11 22:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 22:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 22:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Sat Feb 12 18:10:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 18:10:20 2005 Subject: [ python-Bugs-1120862 ] Problem in join function definition Message-ID: Bugs item #1120862, was opened at 2005-02-11 16:43 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: yseb (yseb) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in join function definition Initial Comment: There is a problem in the last sentence of the join definition. ========================================== join( words[, sep]) Concatenate a list or tuple of words with intervening occurrences of sep. The default value for sep is a single space character. It is always true that "string.join (string.split(s, sep), sep)" equals s. ========================================== It is true that string.join(string.split(s, sep), sep)" is always equals to s. But string.join(string.split(s)) is not always equals to s especially for repeated sequence of spaces. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-12 18:10 Message: Logged In: YES user_id=38376 And? If the documentation explains how something works, does it also have to list a couple of other things that doesn't work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 From noreply at sourceforge.net Sat Feb 12 18:12:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 18:12:39 2005 Subject: [ python-Bugs-1116571 ] Wrong match with regex, non-greedy problem Message-ID: Bugs item #1116571, was opened at 2005-02-05 01:12 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 Category: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: rengel (engel_re) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Wrong match with regex, non-greedy problem Initial Comment: # This is executable. # My test string ist rather long: tst = "In this Buch, used to designate Dinge der Wirklichkeit rather than SW Ent." # I want to match the last part of the string: # SW Ent # So I define the following pattern an compile it: pat = r"(.*?) (.*?)" rex = re.compile(pat) # Then I search the string to get a match group : mat = rex.search(tst) # If found, print the group if mat: print mat.group() # Instead of # SW Ent # I get the whole string starting with # Buch... # up to the very last # Apparently the non-greedy operator doesn't work correctly. # What's wrong? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:27 Message: Logged In: YES user_id=38376 Search returns the first (left-most) location where the pattern matches, if any. The non-greedy operator only guarantees that you get the shortest possible match at that location. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 From noreply at sourceforge.net Sat Feb 12 18:18:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 18:18:22 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-12 12:18 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=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Sat Feb 12 20:22:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 20:22:48 2005 Subject: [ python-Bugs-1120862 ] Problem in join function definition Message-ID: Bugs item #1120862, was opened at 2005-02-11 10:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: yseb (yseb) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in join function definition Initial Comment: There is a problem in the last sentence of the join definition. ========================================== join( words[, sep]) Concatenate a list or tuple of words with intervening occurrences of sep. The default value for sep is a single space character. It is always true that "string.join (string.split(s, sep), sep)" equals s. ========================================== It is true that string.join(string.split(s, sep), sep)" is always equals to s. But string.join(string.split(s)) is not always equals to s especially for repeated sequence of spaces. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:22 Message: Logged In: YES user_id=80475 I concur. The sentence is correct: >>> s = ' the quick brown \t\t fox jumped ' >>> sep = ' ' >>> s == string.join(string.split(s, sep), sep) True Possibly the docs could go on to talk about string.join(string.split(s)). However that would just be adding rambling verbiage that is unlikely to be helpful to anyone who has just read what string.split(s) actually does. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-12 12:10 Message: Logged In: YES user_id=38376 And? If the documentation explains how something works, does it also have to list a couple of other things that doesn't work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 From noreply at sourceforge.net Sat Feb 12 20:48:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 20:48:35 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 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=1121475&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Sat Feb 12 20:50:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 20:50:59 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-12 12:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) >Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Sat Feb 12 21:21:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 21:21:48 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Settings changed) made by sswamida You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 8 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Sat Feb 12 21:22:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 21:22:18 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Settings changed) made by sswamida You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Sat Feb 12 21:47:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 12 21:47:08 2005 Subject: [ python-Bugs-1121494 ] distutils.dir_utils not unicode compatible Message-ID: Bugs item #1121494, was opened at 2005-02-12 21:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morten Lied Johansen (epcylon) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.dir_utils not unicode compatible Initial Comment: When sourcefiles are passed in as unicodestrings, distutils.dir_utils. mkpath will throw a DistutilsInternalError, as shown in the example attached. Using: Python 2.4 (#1, Feb 12 2005, 20:12:07) 2.6.9-gentoo-r9 GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&group_id=5470 From noreply at sourceforge.net Sun Feb 13 01:27:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 01:27:55 2005 Subject: [ python-Bugs-1121579 ] subprocess example missing "stdout=PIPE" Message-ID: Bugs item #1121579, was opened at 2005-02-12 16: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=1121579&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Monte Davidoff (mdavidoff) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess example missing "stdout=PIPE" Initial Comment: In the Python Library Reference, section 6.8.3.2, the Popen for p2 is missing "stdout=PIPE". Correct line is: p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE) This typo also occurs in subprocess.py line 232. The executable example on line 1118 is correct. Python 2.4, Red Hat Linux 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121579&group_id=5470 From noreply at sourceforge.net Sun Feb 13 02:30:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 02:30:58 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-13 03:18 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-13 11:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-13 05:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Sun Feb 13 03:25:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 03:25:37 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-13 03:18 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-13 12:25 Message: Logged In: YES user_id=1038590 The generator in the previous comment was incorrect (tuple swallows the StopIteration, so it never terminates). Try this instead: def partition(iterable, part_len): itr = iter(iterable) while 1: item = tuple(islice(itr, part_len)) if len(item) < part_len: raise StopIteration yield item ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-13 11:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-13 05:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Sun Feb 13 18:21:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 18:21:42 2005 Subject: [ python-Bugs-1121875 ] SMTPHandler argument misdescribed Message-ID: Bugs item #1121875, was opened at 2005-02-13 17:21 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=1121875&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter (peter2108) Assigned to: Nobody/Anonymous (nobody) Summary: SMTPHandler argument misdescribed Initial Comment: The documentation for SMTPHandler in the logging module says "The toaddrs should be a list of strings without domain names (That's what the mailhost is for)." which does not seem to be correct. The toaddr should be a list of strings like 'john@somewhere.com'. This occurs in 2.3 and 2.4 documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121875&group_id=5470 From noreply at sourceforge.net Sun Feb 13 23:59:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 13 23:59:42 2005 Subject: [ python-Bugs-1095802 ] "Macintosh" references in the docs need to be checked. Message-ID: Bugs item #1095802, was opened at 2005-01-04 07:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095802&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Brett Cannon (bcannon) Summary: "Macintosh" references in the docs need to be checked. Initial Comment: As of 2.4 Python no longer runs on MacOS9 or earlier. We need to go through all the documentation loooking for references to "macintosh", "mac", "apple", "macos" and such to check whether these references are still valid. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-13 14:59 Message: Logged In: YES user_id=357491 OK, applied to both 2.5 and 2.4 . Attached is a text file with the CVS commit log; too many files to list the new rev. #s individually. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-11 16:46 Message: Logged In: YES user_id=357491 I will review it, I just can't make any guarantee as to when I will get to it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-11 07:56 Message: Logged In: YES user_id=45365 Oh yes, lest we forget: if the patches are accepted they should also be applied to the 2.4 maintainance branch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-11 07:54 Message: Logged In: YES user_id=45365 Brett, can I coerce you into reviewing this patch? If not assign back to me and I'll find another victim... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-06 01:59 Message: Logged In: YES user_id=45365 "Macintosh" is fine as a reference, but we need to check that the tekst is actually relevant to OSX. There may be lots of things that can go, referring to non-virtual memory or :-separated filenames, or resource forks, or whatever. Or, at the very least, it may need rewording. As to darwin: I wouldn't cater for that. Technically it's nice to support it, but I'd be surprised if there were a 1000 people out there actually running it. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:21 Message: Logged In: YES user_id=357491 Should we change the mentions to "OS X" or "darwin"? It would help remove any possible misunderstanding of OS 9 support and make sure we caught all doc mentions. Could also help specify and difference between Darwin and OS X explicitly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095802&group_id=5470 From noreply at sourceforge.net Mon Feb 14 00:05:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 00:05:18 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 >Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 5 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Mon Feb 14 11:40:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 11:40:15 2005 Subject: [ python-Feature Requests-1122279 ] Option to force variables to be declared Message-ID: Feature Requests item #1122279, was opened at 2005-02-14 21: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=1122279&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zac Evans (karadoc) Assigned to: Nobody/Anonymous (nobody) Summary: Option to force variables to be declared Initial Comment: My most common python programming error is to spell a variable different ways in different parts of a program. Often this generates no warnings, and is a difficult problem to track down. The Zen of Python says that 'Explicit is better than Implicit'. I would like it if I could set an option so that I had to explicitly declare variables before I can use them. eg. x = 5 would generate a warning, but x = int() x = 5 would not. I do believe that explicit is better than implicit with respect to programming; and I know that this feature would save me a _lot_ of debugging on my larger python projects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 From noreply at sourceforge.net Mon Feb 14 12:14:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 12:14:25 2005 Subject: [ python-Bugs-1122301 ] marshal may crash on truncated input Message-ID: Bugs item #1122301, was opened at 2005-02-14 12: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=1122301&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: marshal may crash on truncated input Initial Comment: marshal doesn't behave well on truncated or otherwise malformed input. here's a short demo script, from a recent comp.lang.python thread: ::: the problem is that the following may or may not reach the "done!" statement, somewhat depending on python version, memory allocator, and what data you pass to dumps. import marshal data = marshal.dumps((1, 2, 3, "hello", 4, 5, 6)) for i in range(len(data), -1, -1): try: print marshal.loads(data[:i]) except EOFError: print "EOFError" except ValueError: print "ValueError" print "done!" (try different data combinations, to see how far you get on your platform...) fixing this should be relatively easy, and should result in a safe unmarshaller (your application will still have to limit the amount of data fed into load/loads, of course). ::: (also note that marshal may raise either EOFError or ValueError exceptions, again somewhat depending on how the file is damaged. a little consistency wouldn't hurt, but I'm not sure if/how this can be fixed...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&group_id=5470 From noreply at sourceforge.net Mon Feb 14 12:17:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 12:17:41 2005 Subject: [ python-Bugs-1117302 ] sgmllib.SGMLParser Message-ID: Bugs item #1117302, was opened at 2005-02-06 15:04 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Paul Birnie (pbirnie) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLParser Initial Comment: sgmllib.SGMLParser calls start tag and end_methods correctly until it encounters One
Two Three the
seems to cause its parsing to become confused and I conly get call backs for tag a twice (link 1 and 3) ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 12:17 Message: Logged In: YES user_id=38376 closing, due to lack of feedback. using HTMLParser instead of sgmllib should solve the problem. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:14 Message: Logged In: YES user_id=38376 footnote 3: for the link case, also note that the HTMLParser module handles this in a more practical way (that is, it limits itself to SGML features that's actually used on the web). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:03 Message: Logged In: YES user_id=38376 footnote 2: if you need to deal with broken HTML, use TidyLib: http://utidylib.berlios.de/ http://effbot.org/zone/element-tidylib.htm ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:01 Message: Logged In: YES user_id=38376 footnote:
is an XML construct, and is not valid HTML. In HTML, "blah", so the BR section is parsed as START br DATA >Two< END br DATA a> which is 100% correct. For more on this topic, see: http://www.cs.tut.fi/~jkorpela/html/empty.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117302&group_id=5470 From noreply at sourceforge.net Mon Feb 14 12:31:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 12:31:15 2005 Subject: [ python-Bugs-1092701 ] os.remove fails on win32 with read-only file Message-ID: Bugs item #1092701, was opened at 2004-12-29 15:30 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092701&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 3 Submitted By: Joshua Weage (jpweage) Assigned to: Nobody/Anonymous (nobody) Summary: os.remove fails on win32 with read-only file Initial Comment: On Windows XP SP2 and Python 2.3.3 or 2.4 a call to os.remove returns Errno 13 permission denied on a read-only file. On linux, python will delete a read-only file. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 12:31 Message: Logged In: YES user_id=38376 This is a platform issue; Windows associates delete privileges with the file, Unix with the directory. I doubt it's a good idea to "fix" Python's remove by making it incompatible with the C library's implementation. (on the C level, unlink() is the same thing as remove(), btw). ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2005-01-01 10:13 Message: Logged In: YES user_id=967320 Yup. I can reproduce that on Win2k. Seems posixmodule.c uses _unlink, _wunlink, which are documented at MS as failing on readonly: "Each of these functions returns 0 if successful. Otherwise, the function returns ?1 and sets errno to EACCES, which means the path specifies a read-only file, or to ENOENT, which means the file or path is not found or the path specified a directory." Seems others have "fixed" it by just changing the mode and trying again: http://sources.redhat.com/ml/cygwin/2001-05/msg01209.html https://www.cvshome.org/cyclic/cvs/unoff-watcom.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092701&group_id=5470 From noreply at sourceforge.net Mon Feb 14 12:35:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 12:35:17 2005 Subject: [ python-Bugs-1054564 ] RE '*.?' cores if len of found string exceeds 10000 Message-ID: Bugs item #1054564, was opened at 2004-10-26 14:55 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054564&group_id=5470 Category: Regular Expressions Group: Python 2.2.3 >Status: Closed >Resolution: Out of Date >Priority: 9 Submitted By: Rob (rwhent) Assigned to: Fredrik Lundh (effbot) Summary: RE '*.?' cores if len of found string exceeds 10000 Initial Comment: Whilst parsing some extremely long strings I found that the re.match causes segmentation faults on Solaris 2.8 when strings being matched contain '*.?' and the contents of the regex which matches this part of the regex exceeds 10000 chars (actually it seemed to be exactly at 8192 chars) This is the regex used: if re.match('^.*?\[\s*[A-Za-z_0-9]+\s*\].*',string): This regex looks for '[alphaNum_]' present in a large string When it failed the string was 8192 chars long with no matching '[alphaNum_]' present. If I reduce the length of the string below 8192 it works ok. This is a major issue to my application as some string to be parsed are very large. I saw some discussion on another bulletin board with a similar issue ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 12:35 Message: Logged In: YES user_id=38376 closing, due to lack of feedback. suggested workarounds should solve the problem. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-10-30 17:44 Message: Logged In: YES user_id=341410 In the case of this particular search, you could write your own little searcher. The following could likely be done better, but this is a quick 5-minute job that won't core on you unless something is really wrong with Python, and may be a reasonable stopgap until someone re-does the regular expression library. import string def find_thing(s): sp = 0 d = dict.fromkeys(list(string.letters+string.digits+'_')) while sp < len(s): start = None for i in xrange(sp, len(s)): if s[i] == '[': start = i break if start is None: return for i in xrange(start+1, len(s)): if s[i] in d: continue elif s[i] == ']': return s[start:i+1] else: sp = i break It returns None on failure to find, and the string otherwise. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-10-26 15:24 Message: Logged In: YES user_id=38376 btw, if you're searching for things, why not use the "search" method? if re.search('\[\s*[A-Za-z_0-9]+\s*\]', string): (also, "[A-Za-z_0-9]" is better spelled "\w") ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-10-26 15:20 Message: Logged In: YES user_id=38376 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054564&group_id=5470 From noreply at sourceforge.net Mon Feb 14 16:50:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 16:50:40 2005 Subject: [ python-Feature Requests-567969 ] Missing socketpair() function. Message-ID: Feature Requests item #567969, was opened at 2002-06-12 12:46 Message generated for change (Comment added) made by grahamh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567969&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: Missing socketpair() function. Initial Comment: Coming from a C++ background, I have noticed the absence of a socketpair() function in the socket module. I have implemented a couple of workarounds (see attached sockpair2.py), which I use a lot. But there are security and portability problems lurking. How about a nice shiny new socketpair() call in socketmodule? Thanks, Graham. ---------------------------------------------------------------------- >Comment By: Graham Horler (grahamh) Date: 2005-02-14 15:50 Message: Logged In: YES user_id=543663 I see python2.4 has a socketpair() function courtesy of Dave Cole - excellent. So, this Feature Request can now be closed I spose. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-15 14:23 Message: Logged In: YES user_id=21627 Good idea. Would you like to work on a patch? Notice that this would involve autoconf machinery, since I doubt that socketpair is universally available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567969&group_id=5470 From noreply at sourceforge.net Mon Feb 14 18:28:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 18:28:05 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 17:28 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=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Egon Frerich (friedrich) Assigned to: Nobody/Anonymous (nobody) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Mon Feb 14 23:17:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 14 23:17:58 2005 Subject: [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 23:17 Message: Logged In: YES user_id=38376 (should I mark this as "won't fix" and close it?) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-20 21:25 Message: Logged In: YES user_id=21627 The problem with the OEMCP is more complex, given the chcp utility (i.e. that the console code page may vary from console to console), see patch 612627. So I don't think we should keep a database of OEM code pages. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 21:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply at sourceforge.net Tue Feb 15 00:19:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 00:19:37 2005 Subject: [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-15 00:19 Message: Logged In: YES user_id=21627 I think that would be appropriate. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 23:17 Message: Logged In: YES user_id=38376 (should I mark this as "won't fix" and close it?) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-20 21:25 Message: Logged In: YES user_id=21627 The problem with the OEMCP is more complex, given the chcp utility (i.e. that the console code page may vary from console to console), see patch 612627. So I don't think we should keep a database of OEM code pages. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 21:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply at sourceforge.net Tue Feb 15 00:35:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 00:35:56 2005 Subject: [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-15 00:19 Message: Logged In: YES user_id=21627 I think that would be appropriate. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 23:17 Message: Logged In: YES user_id=38376 (should I mark this as "won't fix" and close it?) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-20 21:25 Message: Logged In: YES user_id=21627 The problem with the OEMCP is more complex, given the chcp utility (i.e. that the console code page may vary from console to console), see patch 612627. So I don't think we should keep a database of OEM code pages. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 21:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply at sourceforge.net Tue Feb 15 08:04:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 08:04:15 2005 Subject: [ python-Bugs-1122916 ] incorrect handle of declaration in markupbase Message-ID: Bugs item #1122916, was opened at 2005-02-14 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=1122916&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect handle of declaration in markupbase Initial Comment: When parsing the document below using sgmllib: hello The incorrect declaration is returned with hello as one single character data: "hello" markupbase should have treated it as an error (to be consistent with it strict treatment in _scan_name). I believe the line 73 of markupbase.py should be if rawdata[j:j+2] in ("-", ""): intead of if rawdata[j:j+1] in ("-", ""): Also note that the condition in line 79 will not be true if rawdata[j:j+1] == '--' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122916&group_id=5470 From noreply at sourceforge.net Tue Feb 15 10:31:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 10:31:04 2005 Subject: [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-15 10:31 Message: Logged In: YES user_id=38388 We already have locale_alias table mappings for the Ukraine, albeit different ones. I'll look into updating the windows_locale table to include all the identifiers from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp, the official source for these ids. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-15 00:19 Message: Logged In: YES user_id=21627 I think that would be appropriate. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 23:17 Message: Logged In: YES user_id=38376 (should I mark this as "won't fix" and close it?) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-20 21:25 Message: Logged In: YES user_id=21627 The problem with the OEMCP is more complex, given the chcp utility (i.e. that the console code page may vary from console to console), see patch 612627. So I don't think we should keep a database of OEM code pages. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 21:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply at sourceforge.net Tue Feb 15 10:32:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 10:32:09 2005 Subject: [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: M.-A. Lemburg (lemburg) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-15 10:31 Message: Logged In: YES user_id=38388 We already have locale_alias table mappings for the Ukraine, albeit different ones. I'll look into updating the windows_locale table to include all the identifiers from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp, the official source for these ids. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-15 00:19 Message: Logged In: YES user_id=21627 I think that would be appropriate. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 23:17 Message: Logged In: YES user_id=38376 (should I mark this as "won't fix" and close it?) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-20 21:25 Message: Logged In: YES user_id=21627 The problem with the OEMCP is more complex, given the chcp utility (i.e. that the console code page may vary from console to console), see patch 612627. So I don't think we should keep a database of OEM code pages. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 21:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply at sourceforge.net Tue Feb 15 18:09:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 18:09:13 2005 Subject: [ python-Bugs-1122916 ] incorrect handle of declaration in markupbase Message-ID: Bugs item #1122916, was opened at 2005-02-14 23:04 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122916&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect handle of declaration in markupbase Initial Comment: When parsing the document below using sgmllib: hello The incorrect declaration is returned with hello as one single character data: "hello" markupbase should have treated it as an error (to be consistent with it strict treatment in _scan_name). I believe the line 73 of markupbase.py should be if rawdata[j:j+2] in ("-", ""): intead of if rawdata[j:j+1] in ("-", ""): Also note that the condition in line 79 will not be true if rawdata[j:j+1] == '--' ---------------------------------------------------------------------- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-02-15 09:09 Message: Logged In: YES user_id=561546 To clarify the syndrome, actually everything after the hello\r\n" This means all the tags like are not parsed as tags but as character data as soon as there is a Bugs item #1123268, was opened at 2005-02-15 11: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=1123268&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aaron C. Spike (acspike) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Curses-Function doc Initial Comment: The description of the filter() method on says "This may be used for enabling cgaracter-at-a-time line editing without touching the rest of the screen." cgaracter should likely be character ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123268&group_id=5470 From noreply at sourceforge.net Tue Feb 15 18:57:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 18:57:20 2005 Subject: [ python-Feature Requests-1122279 ] Option to force variables to be declared Message-ID: Feature Requests item #1122279, was opened at 2005-02-14 05:40 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zac Evans (karadoc) Assigned to: Nobody/Anonymous (nobody) Summary: Option to force variables to be declared Initial Comment: My most common python programming error is to spell a variable different ways in different parts of a program. Often this generates no warnings, and is a difficult problem to track down. The Zen of Python says that 'Explicit is better than Implicit'. I would like it if I could set an option so that I had to explicitly declare variables before I can use them. eg. x = 5 would generate a warning, but x = int() x = 5 would not. I do believe that explicit is better than implicit with respect to programming; and I know that this feature would save me a _lot_ of debugging on my larger python projects. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:57 Message: Logged In: YES user_id=764593 For various reasons, this won't soon get into the core. Meanwhile, there are some tools like pychecker which may help. I've also found that declaring __slots__ makes the errors surface a little bit faster, when I'm dealing with attributes. (The most common reason for me to need the variable name in widely separated places.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 From noreply at sourceforge.net Tue Feb 15 20:29:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 20:29:42 2005 Subject: [ python-Feature Requests-1122279 ] Option to force variables to be declared Message-ID: Feature Requests item #1122279, was opened at 2005-02-14 02:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zac Evans (karadoc) Assigned to: Nobody/Anonymous (nobody) Summary: Option to force variables to be declared Initial Comment: My most common python programming error is to spell a variable different ways in different parts of a program. Often this generates no warnings, and is a difficult problem to track down. The Zen of Python says that 'Explicit is better than Implicit'. I would like it if I could set an option so that I had to explicitly declare variables before I can use them. eg. x = 5 would generate a warning, but x = int() x = 5 would not. I do believe that explicit is better than implicit with respect to programming; and I know that this feature would save me a _lot_ of debugging on my larger python projects. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-15 11:29 Message: Logged In: YES user_id=357491 This will never get in as proposed for technical reasons. What is the difference between ``x=5`` and ``x=int()``? To the compiler they are just assignments to a variable, one just happens to involve a function call. The only way to get the feature you want is to somehow have a more specific way of declaring variables, like a 'var' keyword or something and that will probably never go. As Jim suggested, PyChecker is great for this kind of thing. There are things in the works to help lead to PyChecker being added to the standard library so your problem should get a partial solution included in Python some time in the future. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 09:57 Message: Logged In: YES user_id=764593 For various reasons, this won't soon get into the core. Meanwhile, there are some tools like pychecker which may help. I've also found that declaring __slots__ makes the errors surface a little bit faster, when I'm dealing with attributes. (The most common reason for me to need the variable name in widely separated places.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 From noreply at sourceforge.net Tue Feb 15 20:49:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 20:49:25 2005 Subject: [ python-Bugs-1123354 ] test_peepholer failing on HEAD Message-ID: Bugs item #1123354, was opened at 2005-02-15 14:49 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=1123354&group_id=5470 Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: test_peepholer failing on HEAD Initial Comment: On WinXP with current CVS HEAD: FAIL: test_folding_of_binops_on_constants (__main__.TestTranforms) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "../lib/test/test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError and asm contains the big string 'x'*1000 instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 From noreply at sourceforge.net Tue Feb 15 23:49:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 15 23:49:53 2005 Subject: [ python-Bugs-1123354 ] test_peepholer failing on HEAD Message-ID: Bugs item #1123354, was opened at 2005-02-15 14:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: test_peepholer failing on HEAD Initial Comment: On WinXP with current CVS HEAD: FAIL: test_folding_of_binops_on_constants (__main__.TestTranforms) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "../lib/test/test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError and asm contains the big string 'x'*1000 instead. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 17:49 Message: Logged In: YES user_id=80475 Can you confirm that it works after deleting the pyc file? If so, I'll bump the magic number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 From noreply at sourceforge.net Wed Feb 16 00:03:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 00:04:01 2005 Subject: [ python-Bugs-1123354 ] test_peepholer failing on HEAD Message-ID: Bugs item #1123354, was opened at 2005-02-15 14:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: test_peepholer failing on HEAD Initial Comment: On WinXP with current CVS HEAD: FAIL: test_folding_of_binops_on_constants (__main__.TestTranforms) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "../lib/test/test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError and asm contains the big string 'x'*1000 instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-15 18:03 Message: Logged In: YES user_id=31435 Well, I'm using rt.bat from PCbuild to run the tests. That deletes all the .pyc and .pyo files reachable from Lib before running the tests. So, no, deleting .pyc doesn't matter here. ...\PCbuild>python rmpyc.py 81 .pyc deleted, 0 .pyo deleted ...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo File Not Found ...\PCbuild>rt test_peepholer Deleting .pyc/.pyo files ... 14 .pyc deleted, 0 .pyo deleted ...\PCbuild>python -E -tt ../lib/test/regrtest.py test_peepholer test_peepholer test test_peepholer failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError 1 test failed: test_peepholer About to run again without deleting .pyc/.pyo first: Press any key to continue . . . Terminate batch job (Y/N)? y Is it possible, e.g., that you have an unchecked-in change on your development machine? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 17:49 Message: Logged In: YES user_id=80475 Can you confirm that it works after deleting the pyc file? If so, I'll bump the magic number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 From noreply at sourceforge.net Wed Feb 16 00:48:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 00:48:36 2005 Subject: [ python-Bugs-1123354 ] test_peepholer failing on HEAD Message-ID: Bugs item #1123354, was opened at 2005-02-15 14:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: test_peepholer failing on HEAD Initial Comment: On WinXP with current CVS HEAD: FAIL: test_folding_of_binops_on_constants (__main__.TestTranforms) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "../lib/test/test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError and asm contains the big string 'x'*1000 instead. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 18:48 Message: Logged In: YES user_id=80475 Hmm, I don't see how we could get different results. After a fresh cvs up and recompilation, I get: C:\py25>cvs st Python/compile.c =================================================================== File: compile.c Status: Up-to-date Working revision: 2.344 Repository revision: 2.344 /cvsroot/python/python/dist/src/Python/compile. ,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) C:\py25>cvs st Lib/test/test_peepholer.py =================================================================== File: test_peepholer.py Status: Up-to-date Working revision: 1.11 Repository revision: 1.11 /cvsroot/python/python/dist/src/Lib/test/test_pe epholer.py,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) C:\py25\Lib\test>python -tt test_peepholer.py test_elim_extra_return (__main__.TestTranforms) ... ok test_elim_inversion_of_is_or_in (__main__.TestTranforms) ... ok test_folding_of_binops_on_constants (__main__.TestTranforms) ... ok test_folding_of_tuples_of_constants (__main__.TestTranforms) ... ok test_none_as_constant (__main__.TestTranforms) ... ok test_pack_unpack (__main__.TestTranforms) ... ok test_unot (__main__.TestTranforms) ... ok test_while_one (__main__.TestTranforms) ... ok ---------------------------------------------------------------------- Ran 8 tests in 0.170s OK C:\py25>python Python 2.5a0 (#46, Feb 15 2005, 18:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from dis import dis >>> dis(compile('a="x"*1000', '', 'single')) 1 0 LOAD_CONST 0 ('x') 3 LOAD_CONST 1 (1000) 6 BINARY_MULTIPLY 7 STORE_NAME 0 (a) 10 LOAD_CONST 2 (None) 13 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 18:03 Message: Logged In: YES user_id=31435 Well, I'm using rt.bat from PCbuild to run the tests. That deletes all the .pyc and .pyo files reachable from Lib before running the tests. So, no, deleting .pyc doesn't matter here. ...\PCbuild>python rmpyc.py 81 .pyc deleted, 0 .pyo deleted ...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo File Not Found ...\PCbuild>rt test_peepholer Deleting .pyc/.pyo files ... 14 .pyc deleted, 0 .pyo deleted ...\PCbuild>python -E -tt ../lib/test/regrtest.py test_peepholer test_peepholer test test_peepholer failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError 1 test failed: test_peepholer About to run again without deleting .pyc/.pyo first: Press any key to continue . . . Terminate batch job (Y/N)? y Is it possible, e.g., that you have an unchecked-in change on your development machine? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 17:49 Message: Logged In: YES user_id=80475 Can you confirm that it works after deleting the pyc file? If so, I'll bump the magic number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 From noreply at sourceforge.net Wed Feb 16 02:21:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 02:21:13 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-15 17:21 Message: Logged In: YES user_id=357491 If you read the pickle docs it says you can only pickle "functions defined at the top level of a module". The lambdas are you having your decorator return are not defined at the module level and thus do not meet that requirement. The same basic issue goes with your callable class. The function you are storing in self.f is not the same as was is defined at the module level since self.f is 'func' prior to wrapping while what 'func' has at the global level is an instance of 'C'. The reason your example works is because '_func` is defined at the module level and thus pickle can find it to pickle. Decorators skip the intermediate step of storing the undecorated function at the module level. It would be better to use the pickling protocol to define methods to allow your callable class to help with the pickling process. And just so you know, your class examples should be calling self.f instead of f. Closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Wed Feb 16 02:45:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 02:45:58 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Comment added) made by sswamida You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed >Resolution: None Priority: 5 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- >Comment By: S Joshua Swamidass (sswamida) Date: 2005-02-15 17:45 Message: Logged In: YES user_id=786138 Yes, everything you said is correct, though i think this is not ideal behavior. If we decorate a function at the top level of a module, shouldn't it be pickleable? If not, then as my original point was, decorated functions are not compatible with pickle. Is there any case you can give me where a decorated function is defined in the top level of a module and can be pickled? I can't think of one, but i could be wrong. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-15 17:21 Message: Logged In: YES user_id=357491 If you read the pickle docs it says you can only pickle "functions defined at the top level of a module". The lambdas are you having your decorator return are not defined at the module level and thus do not meet that requirement. The same basic issue goes with your callable class. The function you are storing in self.f is not the same as was is defined at the module level since self.f is 'func' prior to wrapping while what 'func' has at the global level is an instance of 'C'. The reason your example works is because '_func` is defined at the module level and thus pickle can find it to pickle. Decorators skip the intermediate step of storing the undecorated function at the module level. It would be better to use the pickling protocol to define methods to allow your callable class to help with the pickling process. And just so you know, your class examples should be calling self.f instead of f. Closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Wed Feb 16 02:56:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 02:56:32 2005 Subject: [ python-Bugs-1123354 ] test_peepholer failing on HEAD Message-ID: Bugs item #1123354, was opened at 2005-02-15 14:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: test_peepholer failing on HEAD Initial Comment: On WinXP with current CVS HEAD: FAIL: test_folding_of_binops_on_constants (__main__.TestTranforms) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "../lib/test/test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError and asm contains the big string 'x'*1000 instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-15 20:56 Message: Logged In: YES user_id=31435 Peculiar! I have the same CVS status output, and recompiled Python from scratch earlier just to be sure. Oh, dang, I'm sorry. Turns out my Visual Studio run was still pointing at the 24-maint branch checkout -- I wasn't recompiling the HEAD at all. Works fine! False alarm. Sorry, Raymond! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 18:48 Message: Logged In: YES user_id=80475 Hmm, I don't see how we could get different results. After a fresh cvs up and recompilation, I get: C:\py25>cvs st Python/compile.c =================================================================== File: compile.c Status: Up-to-date Working revision: 2.344 Repository revision: 2.344 /cvsroot/python/python/dist/src/Python/compile. ,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) C:\py25>cvs st Lib/test/test_peepholer.py =================================================================== File: test_peepholer.py Status: Up-to-date Working revision: 1.11 Repository revision: 1.11 /cvsroot/python/python/dist/src/Lib/test/test_pe epholer.py,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) C:\py25\Lib\test>python -tt test_peepholer.py test_elim_extra_return (__main__.TestTranforms) ... ok test_elim_inversion_of_is_or_in (__main__.TestTranforms) ... ok test_folding_of_binops_on_constants (__main__.TestTranforms) ... ok test_folding_of_tuples_of_constants (__main__.TestTranforms) ... ok test_none_as_constant (__main__.TestTranforms) ... ok test_pack_unpack (__main__.TestTranforms) ... ok test_unot (__main__.TestTranforms) ... ok test_while_one (__main__.TestTranforms) ... ok ---------------------------------------------------------------------- Ran 8 tests in 0.170s OK C:\py25>python Python 2.5a0 (#46, Feb 15 2005, 18:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from dis import dis >>> dis(compile('a="x"*1000', '', 'single')) 1 0 LOAD_CONST 0 ('x') 3 LOAD_CONST 1 (1000) 6 BINARY_MULTIPLY 7 STORE_NAME 0 (a) 10 LOAD_CONST 2 (None) 13 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 18:03 Message: Logged In: YES user_id=31435 Well, I'm using rt.bat from PCbuild to run the tests. That deletes all the .pyc and .pyo files reachable from Lib before running the tests. So, no, deleting .pyc doesn't matter here. ...\PCbuild>python rmpyc.py 81 .pyc deleted, 0 .pyo deleted ...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo File Not Found ...\PCbuild>rt test_peepholer Deleting .pyc/.pyo files ... 14 .pyc deleted, 0 .pyo deleted ...\PCbuild>python -E -tt ../lib/test/regrtest.py test_peepholer test_peepholer test test_peepholer failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError 1 test failed: test_peepholer About to run again without deleting .pyc/.pyo first: Press any key to continue . . . Terminate batch job (Y/N)? y Is it possible, e.g., that you have an unchecked-in change on your development machine? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 17:49 Message: Logged In: YES user_id=80475 Can you confirm that it works after deleting the pyc file? If so, I'll bump the magic number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 From noreply at sourceforge.net Wed Feb 16 03:58:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 03:58:45 2005 Subject: [ python-Bugs-1123354 ] test_peepholer failing on HEAD Message-ID: Bugs item #1123354, was opened at 2005-02-15 14:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: test_peepholer failing on HEAD Initial Comment: On WinXP with current CVS HEAD: FAIL: test_folding_of_binops_on_constants (__main__.TestTranforms) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "../lib/test/test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError and asm contains the big string 'x'*1000 instead. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 21:58 Message: Logged In: YES user_id=80475 C'est le vie. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 20:56 Message: Logged In: YES user_id=31435 Peculiar! I have the same CVS status output, and recompiled Python from scratch earlier just to be sure. Oh, dang, I'm sorry. Turns out my Visual Studio run was still pointing at the 24-maint branch checkout -- I wasn't recompiling the HEAD at all. Works fine! False alarm. Sorry, Raymond! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 18:48 Message: Logged In: YES user_id=80475 Hmm, I don't see how we could get different results. After a fresh cvs up and recompilation, I get: C:\py25>cvs st Python/compile.c =================================================================== File: compile.c Status: Up-to-date Working revision: 2.344 Repository revision: 2.344 /cvsroot/python/python/dist/src/Python/compile. ,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) C:\py25>cvs st Lib/test/test_peepholer.py =================================================================== File: test_peepholer.py Status: Up-to-date Working revision: 1.11 Repository revision: 1.11 /cvsroot/python/python/dist/src/Lib/test/test_pe epholer.py,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) C:\py25\Lib\test>python -tt test_peepholer.py test_elim_extra_return (__main__.TestTranforms) ... ok test_elim_inversion_of_is_or_in (__main__.TestTranforms) ... ok test_folding_of_binops_on_constants (__main__.TestTranforms) ... ok test_folding_of_tuples_of_constants (__main__.TestTranforms) ... ok test_none_as_constant (__main__.TestTranforms) ... ok test_pack_unpack (__main__.TestTranforms) ... ok test_unot (__main__.TestTranforms) ... ok test_while_one (__main__.TestTranforms) ... ok ---------------------------------------------------------------------- Ran 8 tests in 0.170s OK C:\py25>python Python 2.5a0 (#46, Feb 15 2005, 18:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from dis import dis >>> dis(compile('a="x"*1000', '', 'single')) 1 0 LOAD_CONST 0 ('x') 3 LOAD_CONST 1 (1000) 6 BINARY_MULTIPLY 7 STORE_NAME 0 (a) 10 LOAD_CONST 2 (None) 13 RETURN_VALUE ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 18:03 Message: Logged In: YES user_id=31435 Well, I'm using rt.bat from PCbuild to run the tests. That deletes all the .pyc and .pyo files reachable from Lib before running the tests. So, no, deleting .pyc doesn't matter here. ...\PCbuild>python rmpyc.py 81 .pyc deleted, 0 .pyo deleted ...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo File Not Found ...\PCbuild>rt test_peepholer Deleting .pyc/.pyo files ... 14 .pyc deleted, 0 .pyo deleted ...\PCbuild>python -E -tt ../lib/test/regrtest.py test_peepholer test_peepholer test test_peepholer failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_peepholer.py", line 134, in test_folding_of_binops_on_constants self.assert_('(1000)' in asm) AssertionError 1 test failed: test_peepholer About to run again without deleting .pyc/.pyo first: Press any key to continue . . . Terminate batch job (Y/N)? y Is it possible, e.g., that you have an unchecked-in change on your development machine? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-15 17:49 Message: Logged In: YES user_id=80475 Can you confirm that it works after deleting the pyc file? If so, I'll bump the magic number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470 From noreply at sourceforge.net Wed Feb 16 05:14:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 05:14:37 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-16 04: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=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Wed Feb 16 07:06:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 07:06:53 2005 Subject: [ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails starting on 2.4 Message-ID: Bugs item #1123695, was opened at 2005-02-16 01: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=1123695&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stephan Sokolow (ssokolow) Assigned to: Nobody/Anonymous (nobody) Summary: attempting to use urllib2 on some URLs fails starting on 2.4 Initial Comment: The following will work correctly on Python 2.3.3 but fails on Python 2.4 Python 2.4 (#1, Dec 4 2004, 01:33:42) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib2 >>> urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/socket.py", line 285, in read data = self._sock.recv(recv_size) File "/usr/local/lib/python2.4/httplib.py", line 456, in read return self._read_chunked(amt) File "/usr/local/lib/python2.4/httplib.py", line 495, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int(): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&group_id=5470 From noreply at sourceforge.net Wed Feb 16 07:48:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 07:48:40 2005 Subject: [ python-Bugs-1123716 ] descrintro describes __new__ and __init__ behavior wrong Message-ID: Bugs item #1123716, was opened at 2005-02-15 23: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=1123716&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: descrintro describes __new__ and __init__ behavior wrong Initial Comment: The current descrintro.html says: "__new__ must return an object... If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called..." This suggests that __new__ will call __init__ of the object even if the object is a different type. The code in typeobject.c disagrees with this: static PyObject * type_call(PyTypeObject *type, PyObject *args, PyObject *kwds) { ... /* If the returned object is not an instance of type, it won't be initialized. */ if (!PyType_IsSubtype(obj->ob_type, type)) return obj; ... } Suggested fix: "__new__ must return an object... If you return an existing object, the constructor call will still call its __init__ method unless the object is an instance of a different class..." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123716&group_id=5470 From noreply at sourceforge.net Wed Feb 16 08:08:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 08:08:32 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 07:25 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:08 Message: Logged In: YES user_id=38376 (footnote: like any other global interpreter setting, changing the default encoding is a bad idea in general. the setdefaultencoding hook was added for experimentation during unicode development, and the idea was to remove it when things had settled down. too bad the documentation doesn't reflect this, though...). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 19:06 Message: Logged In: YES user_id=3066 Fixed for Python 2.4.1 and 2.5: Lib/xmlrpclib.py 1.36.2.1, 1.40 Lib/test/test_xmlrpc.py 1.5.4.1, 1.7 I committed the attached patch and added a unit test. Python 2.3 got left out since this doesn't seem critical enough to destabilize old applications. I won't strongly object if someone backports it to 2.3.6, if they actually think there's going to be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Wed Feb 16 08:17:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 08:17:47 2005 Subject: [ python-Bugs-1123727 ] gensuitemodule.processfile fails Message-ID: Bugs item #1123727, was opened at 2005-02-16 07: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=1123727&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: gensuitemodule.processfile fails Initial Comment: gensuitemodule.processfile fails for an application as trivial as Safari, while the same procedure works OK on version 2.3. On version 2.3: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') [lots of dialogs] On version 2.4, same machine: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 222, in processfile verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete creatorsignature, dummy = MacOS.GetCreatorAndType(fname) Error: (-43, 'File not found') I'm pretty conviced the application did not move in the 20 seconds between those two invocations :-) Any suggestions? - Jurjen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 From noreply at sourceforge.net Wed Feb 16 08:22:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 08:22:30 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 01:25 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-16 02:22 Message: Logged In: YES user_id=3066 Agreed. It's use in the test was simply to duplicate the environment the xmlrpclib code failed in. Getting all the right people to agree that it should be completely removed and the default encoding always set to ASCII is a separate issue, though. This bug was a consequence of the existing, documented flexibility. As long as that exists, the standard library has to deal with it. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 02:08 Message: Logged In: YES user_id=38376 (footnote: like any other global interpreter setting, changing the default encoding is a bad idea in general. the setdefaultencoding hook was added for experimentation during unicode development, and the idea was to remove it when things had settled down. too bad the documentation doesn't reflect this, though...). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 13:06 Message: Logged In: YES user_id=3066 Fixed for Python 2.4.1 and 2.5: Lib/xmlrpclib.py 1.36.2.1, 1.40 Lib/test/test_xmlrpc.py 1.5.4.1, 1.7 I committed the attached patch and added a unit test. Python 2.3 got left out since this doesn't seem critical enough to destabilize old applications. I won't strongly object if someone backports it to 2.3.6, if they actually think there's going to be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Wed Feb 16 08:32:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 08:32:29 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 07:25 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:32 Message: Logged In: YES user_id=38376 Adding a brief "avoid, if possible; may break external libraries, may go away in the future; use encoded streams and explicit encodings instead" note to the "sys" documentation might be a good idea, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-16 08:22 Message: Logged In: YES user_id=3066 Agreed. It's use in the test was simply to duplicate the environment the xmlrpclib code failed in. Getting all the right people to agree that it should be completely removed and the default encoding always set to ASCII is a separate issue, though. This bug was a consequence of the existing, documented flexibility. As long as that exists, the standard library has to deal with it. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:08 Message: Logged In: YES user_id=38376 (footnote: like any other global interpreter setting, changing the default encoding is a bad idea in general. the setdefaultencoding hook was added for experimentation during unicode development, and the idea was to remove it when things had settled down. too bad the documentation doesn't reflect this, though...). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 19:06 Message: Logged In: YES user_id=3066 Fixed for Python 2.4.1 and 2.5: Lib/xmlrpclib.py 1.36.2.1, 1.40 Lib/test/test_xmlrpc.py 1.5.4.1, 1.7 I committed the attached patch and added a unit test. Python 2.3 got left out since this doesn't seem critical enough to destabilize old applications. I won't strongly object if someone backports it to 2.3.6, if they actually think there's going to be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Wed Feb 16 09:40:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 09:40:29 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by ekloef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Wed Feb 16 10:26:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 10:26:17 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 07:25 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-16 10:26 Message: Logged In: YES user_id=38388 +1 on the comment "avoid, if possible; may break external libraries; use encoded streams and explicit encodings instead". The "may go away in the future" is not true and, as far as I remember, was never taken into consideration (remember that we even wanted the default encoding to be determined by the locale at one point, but then quickly dropped that idea again... there's still code in site.py that enables this). Setting the default encoding to something other than ASCII is only possible in site.py and sitecustomize.py - for a good reason. The site maintainer should be able to use a different default if needed for whatever reason. OTOH, libraries should not assume the ASCII setting of the default encoding and always make their assumption explicit :-) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:32 Message: Logged In: YES user_id=38376 Adding a brief "avoid, if possible; may break external libraries, may go away in the future; use encoded streams and explicit encodings instead" note to the "sys" documentation might be a good idea, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-16 08:22 Message: Logged In: YES user_id=3066 Agreed. It's use in the test was simply to duplicate the environment the xmlrpclib code failed in. Getting all the right people to agree that it should be completely removed and the default encoding always set to ASCII is a separate issue, though. This bug was a consequence of the existing, documented flexibility. As long as that exists, the standard library has to deal with it. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:08 Message: Logged In: YES user_id=38376 (footnote: like any other global interpreter setting, changing the default encoding is a bad idea in general. the setdefaultencoding hook was added for experimentation during unicode development, and the idea was to remove it when things had settled down. too bad the documentation doesn't reflect this, though...). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 19:06 Message: Logged In: YES user_id=3066 Fixed for Python 2.4.1 and 2.5: Lib/xmlrpclib.py 1.36.2.1, 1.40 Lib/test/test_xmlrpc.py 1.5.4.1, 1.7 I committed the attached patch and added a unit test. Python 2.3 got left out since this doesn't seem critical enough to destabilize old applications. I won't strongly object if someone backports it to 2.3.6, if they actually think there's going to be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Wed Feb 16 10:31:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 10:31:45 2005 Subject: [ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify' Message-ID: Bugs item #1115989, was opened at 2005-02-04 07:25 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlrpclib: wrong decoding in '_stringify' Initial Comment: '_stringify' tries to convert a unicode string into a pure ascii string by 'str(string)'. This can lead to catastrophic behaviour when Python's "defaultencoding" is not "ascii". The attached patch uses "string.encode('ascii')" instead to become independent of the default encoding. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 10:31 Message: Logged In: YES user_id=38376 "may go away in the future" is definitely true, if you consider Python rather than just the CPython implementation. the whole concept of globally configurable conversion rules may not make any sense at all in a revised string model... (and afaicr, dropping the set function was discussed. don't recall in what forum, though, and have no time to go looking for it.) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-16 10:26 Message: Logged In: YES user_id=38388 +1 on the comment "avoid, if possible; may break external libraries; use encoded streams and explicit encodings instead". The "may go away in the future" is not true and, as far as I remember, was never taken into consideration (remember that we even wanted the default encoding to be determined by the locale at one point, but then quickly dropped that idea again... there's still code in site.py that enables this). Setting the default encoding to something other than ASCII is only possible in site.py and sitecustomize.py - for a good reason. The site maintainer should be able to use a different default if needed for whatever reason. OTOH, libraries should not assume the ASCII setting of the default encoding and always make their assumption explicit :-) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:32 Message: Logged In: YES user_id=38376 Adding a brief "avoid, if possible; may break external libraries, may go away in the future; use encoded streams and explicit encodings instead" note to the "sys" documentation might be a good idea, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-16 08:22 Message: Logged In: YES user_id=3066 Agreed. It's use in the test was simply to duplicate the environment the xmlrpclib code failed in. Getting all the right people to agree that it should be completely removed and the default encoding always set to ASCII is a separate issue, though. This bug was a consequence of the existing, documented flexibility. As long as that exists, the standard library has to deal with it. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-16 08:08 Message: Logged In: YES user_id=38376 (footnote: like any other global interpreter setting, changing the default encoding is a bad idea in general. the setdefaultencoding hook was added for experimentation during unicode development, and the idea was to remove it when things had settled down. too bad the documentation doesn't reflect this, though...). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-11 19:06 Message: Logged In: YES user_id=3066 Fixed for Python 2.4.1 and 2.5: Lib/xmlrpclib.py 1.36.2.1, 1.40 Lib/test/test_xmlrpc.py 1.5.4.1, 1.7 I committed the attached patch and added a unit test. Python 2.3 got left out since this doesn't seem critical enough to destabilize old applications. I won't strongly object if someone backports it to 2.3.6, if they actually think there's going to be a 2.3.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470 From noreply at sourceforge.net Wed Feb 16 17:38:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 17:38:14 2005 Subject: [ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails starting on 2.4 Message-ID: Bugs item #1123695, was opened at 2005-02-16 07:06 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stephan Sokolow (ssokolow) Assigned to: Nobody/Anonymous (nobody) Summary: attempting to use urllib2 on some URLs fails starting on 2.4 Initial Comment: The following will work correctly on Python 2.3.3 but fails on Python 2.4 Python 2.4 (#1, Dec 4 2004, 01:33:42) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib2 >>> urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/socket.py", line 285, in read data = self._sock.recv(recv_size) File "/usr/local/lib/python2.4/httplib.py", line 456, in read return self._read_chunked(amt) File "/usr/local/lib/python2.4/httplib.py", line 495, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int(): ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-02-16 17:38 Message: Logged In: YES user_id=9205 This bug is in httplib.py, and I already submitted patch 900744. I wonder why on Python 2.3 it seems to work though, it should fail the same way since this bug is also present in Python 2.3. But it might be some change in urllib2 that triggers this in Python 2.4 and not in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&group_id=5470 From noreply at sourceforge.net Wed Feb 16 21:07:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 21:07:59 2005 Subject: [ python-Bugs-1117048 ] Dictionary Parsing Problem Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 15:07 Message: Logged In: YES user_id=593130 What do you mean by 'dict with an error in it'? I don't know that I can produce such a thing with Python. Or how globals could have an error. I suppose you could give a dict an unprintable key or value (by having __str__ raise an exception), but I would consider that a bug in the program and an error in the key/value and not the dict. I think the behavior on trying to print a collection with such nasty objects is best left undefined. Or do you have something else in mind? In any case, reading and writing data streams in chunks is standard practice. If a dict were large enough, its text representation would not even fit in RAM all at once. And, in any case ... Bug reports should give a specific example of the purported bug, complete with cut and paste of (minimal) code and output or error trace. They may need a reference to the relevant section of the manuals. If you don't have a verifiable example, please close this. Specific feature requests can be submitted as an RFE. Design discussions should be kept to discussion forums. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Wed Feb 16 21:26:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 21:26:23 2005 Subject: [ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments. Message-ID: Bugs item #1117601, was opened at 2005-02-06 19:57 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Bennett (sbennett) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists returns false negatives in MAC environments. Initial Comment: In Mandatory Access Control environments (such as SELinux), it's quite possible for stat to fail with permission denied. In this case, os.path.exists will return False incorrectly. The simple(ish) fix is to check for an access denied error (which would indicate present, but not readable) when using stat to check for existence of files. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 15:26 Message: Logged In: YES user_id=593130 Does 'access denied' always mean 'present but not readable' in every environment that gives such messages? I ask because I have vague memories of wasting time trying to get access to something that did not exist, because access denied (or something like that) meant that I was denied access even to info about whether it existed or not. In any case, a reproducible example would help someone to verify, fix, and write a test case for this if it is deemed to be a fixable bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 From noreply at sourceforge.net Wed Feb 16 22:11:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 22:11:26 2005 Subject: [ python-Bugs-1124278 ] PyDateTime_FromDateAndTime documented as PyDate_FromDateAndT Message-ID: Bugs item #1124278, was opened at 2005-02-16 14: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=1124278&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: smilechaser (smilechaser) Assigned to: Nobody/Anonymous (nobody) Summary: PyDateTime_FromDateAndTime documented as PyDate_FromDateAndT Initial Comment: In datetime.h there exists a macro called: PyDateTime_FromDateAndTime but in the documentation (7.5.12 of the Python/C API Reference Manual) it is documented as: PyDate_FromDateAndTime ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124278&group_id=5470 From noreply at sourceforge.net Wed Feb 16 22:34:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 22:34:07 2005 Subject: [ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode Message-ID: Bugs item #1124295, was opened at 2005-02-16 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=1124295&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: Function's __name__ no longer accessible in restricted mode Initial Comment: This change breaks an obscure bit of Zope's security machinery, which uses the __name__ of a function to construct the synthetic attribute name under which the roles for a method are stored. $ ../bin/python2.3 Python 2.3.4 (#3, Jan 27 2005, 10:46:13) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs func >>> ^D $ ../bin/python2.4 Python 2.4 (#1, Feb 16 2005, 13:11:02) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs Traceback (most recent call last): File "", line 1, in ? File "", line 3, in ? RuntimeError: function attributes not accessible in restricted mode >>> ^D ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 From noreply at sourceforge.net Wed Feb 16 22:58:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 22:58:13 2005 Subject: [ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode Message-ID: Bugs item #1124295, was opened at 2005-02-16 16:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 8 Submitted By: Tres Seaver (tseaver) >Assigned to: Tim Peters (tim_one) Summary: Function's __name__ no longer accessible in restricted mode Initial Comment: This change breaks an obscure bit of Zope's security machinery, which uses the __name__ of a function to construct the synthetic attribute name under which the roles for a method are stored. $ ../bin/python2.3 Python 2.3.4 (#3, Jan 27 2005, 10:46:13) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs func >>> ^D $ ../bin/python2.4 Python 2.4 (#1, Feb 16 2005, 13:11:02) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs Traceback (most recent call last): File "", line 1, in ? File "", line 3, in ? RuntimeError: function attributes not accessible in restricted mode >>> ^D ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-16 16:58 Message: Logged In: YES user_id=31435 Assigned to me, and boosted priority, since this should be addressed for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 From noreply at sourceforge.net Wed Feb 16 23:21:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 23:21:07 2005 Subject: [ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently Message-ID: Bugs item #1119418, was opened at 2005-02-09 11:57 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 6 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() builtin accepts keyword arg silently Initial Comment: Calling ``xrange(10, 100, step=10)`` results in a xrange(10, 100) iterator silently. In contrast, ``range(10, 100, step=10)`` raises an exception. See test program below. Two possible fixes: 1. fix xrange() so that it returns a xrange(10, 100, 10) iterator 2. make sure that xrange() raises an exception too. #!/usr/bin/env python def foo( min_, max_, step=1 ): print min_, max_, step print '====================' foo(10, 100, 10) foo(10, 100, step=10) print '====================' print xrange(10, 100, 10) print xrange(10, 100, step=10) print '====================' print range(10, 100, 10) print range(10, 100, step=10) elbow:/usr/.../lib/python2.4$ /tmp/a.py ==================== 10 100 10 10 100 10 ==================== xrange(10, 100, 10) xrange(10, 100) ==================== [10, 20, 30, 40, 50, 60, 70, 80, 90] Traceback (most recent call last): File "/tmp/a.py", line 16, in ? print range(10, 100, step=10) TypeError: range() takes no keyword arguments > /tmp/a.py(16)?() -> print range(10, 100, step=10) (Pdb) elbow:/usr/.../lib/python2.4$ ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 17:21 Message: Logged In: YES user_id=593130 Functions coded in C generally do not take keyword arguments. (Special coding is required to achieve otherwise.) In 2.2, range and xrange both followed this rule: >>> xrange(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: xrange() takes no keyword arguments >>> range(1,20,step=2) Traceback (most recent call last): File "", line 1, in ? TypeError: range() takes no keyword arguments So, removal of the error message by 2.4 seem to be a bug. Surprise: >>> str(object=1) '1' >>> str(i=2) Traceback (most recent call last): File "", line 1, in ? TypeError: 'i' is an invalid keyword argument for this function There is nothing in the doc(Lib Ref) or doc string of str vs. range and xrange that would lead me to expect this. I looked around CVS a bit to see if the past or possible future change was something simple, but I could not find source of error message in bltinmodule.c, ceval.c, getargs.c, rangeobject.c, or typeobject.c, so I will leave this to someone else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&group_id=5470 From noreply at sourceforge.net Wed Feb 16 23:46:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 23:46:59 2005 Subject: [ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments. Message-ID: Bugs item #1117601, was opened at 2005-02-07 00:57 Message generated for change (Comment added) made by sbennett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Bennett (sbennett) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists returns false negatives in MAC environments. Initial Comment: In Mandatory Access Control environments (such as SELinux), it's quite possible for stat to fail with permission denied. In this case, os.path.exists will return False incorrectly. The simple(ish) fix is to check for an access denied error (which would indicate present, but not readable) when using stat to check for existence of files. ---------------------------------------------------------------------- >Comment By: Stephen Bennett (sbennett) Date: 2005-02-16 22:46 Message: Logged In: YES user_id=817465 As far as I know (at least for SELinux), permission denied on stat() always means that the file exists, but getattr isn't allowed. As for a reproducible test case, probably the simplest example is a vanilla Fedora Core 3 system with SELinux enabled and strict policy. From a regular user account, call os.path.exists("/etc/shadow"). It will return False even though the file exists. For comparison, an `ls -l /etc/shadow` from the command line will simply print 'Permission Denied'. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 20:26 Message: Logged In: YES user_id=593130 Does 'access denied' always mean 'present but not readable' in every environment that gives such messages? I ask because I have vague memories of wasting time trying to get access to something that did not exist, because access denied (or something like that) meant that I was denied access even to info about whether it existed or not. In any case, a reproducible example would help someone to verify, fix, and write a test case for this if it is deemed to be a fixable bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470 From noreply at sourceforge.net Wed Feb 16 23:49:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 16 23:49:06 2005 Subject: [ python-Bugs-1119439 ] Python Programming FAQ should be updated for Python 2.4 Message-ID: Bugs item #1119439, was opened at 2005-02-09 12:17 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119439&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Python Programming FAQ should be updated for Python 2.4 Initial Comment: For example: * "1.4.3 How do I iterate over a sequence in reverse order?" should use reversed() * "1.4.4 How do you remove duplicates from a list?" should use set() * "1.5.2 I want to do a complicated sort: can you do a Schwartzian Transform in Python?" should use sort(key=) * section 1.6 should use new-style classes ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 17:49 Message: Logged In: YES user_id=593130 I believe the FAQs are only maintained at www.python.org and not at SourceForge. If so, you should email your comments to webmaster@python.org and/or docs@python.org. I strongly urge you to work your comments up into a set of specific patches (in text form). In other words, give a specific suggested text to replace or augment the old one. Since there is no paid editor, this will make changes much easier and therefore more likely sooner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119439&group_id=5470 From noreply at sourceforge.net Thu Feb 17 00:05:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 00:05:21 2005 Subject: [ python-Bugs-1117048 ] Dictionary Parsing Problem Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by walterbrunswick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- >Comment By: WalterBrunswick (walterbrunswick) Date: 2005-02-16 18:05 Message: Logged In: YES user_id=1164416 The interpreter begins parsing the dictionary immediately, without buffering and checking for errors beforehand. In the case that an error occurs, such as a faulty key, the interpreter outputs a nasty-looking error - including the error message as part of the dictionary, as you can see from the log (ErrorLog2.log). There is no way that this can be prevented without locating the source of the problem. What I'm saying is that the interpreter should catch the error and raise an exception. But as you said, parsing data streams in chunks is standard; however, I can't see any way around this problem. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 15:07 Message: Logged In: YES user_id=593130 What do you mean by 'dict with an error in it'? I don't know that I can produce such a thing with Python. Or how globals could have an error. I suppose you could give a dict an unprintable key or value (by having __str__ raise an exception), but I would consider that a bug in the program and an error in the key/value and not the dict. I think the behavior on trying to print a collection with such nasty objects is best left undefined. Or do you have something else in mind? In any case, reading and writing data streams in chunks is standard practice. If a dict were large enough, its text representation would not even fit in RAM all at once. And, in any case ... Bug reports should give a specific example of the purported bug, complete with cut and paste of (minimal) code and output or error trace. They may need a reference to the relevant section of the manuals. If you don't have a verifiable example, please close this. Specific feature requests can be submitted as an RFE. Design discussions should be kept to discussion forums. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Thu Feb 17 01:03:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 01:03:32 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-12 12:18 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:03 Message: Logged In: YES user_id=593130 I agree that the zip doc needs improvement. Confusion will continue until it is. Here is my suggested rewrite: ------------------------------------------------------------------- zip([iterable1, ...]) Return a list of tuples, where the i-th tuple contains the i-th element from each input in the same order as the inputs. With no arguments, return an empty list (before 2.4, a TypeError was raised instead.) With a single input, return a list of 1-tuples. With multiple inputs, the output length is that of the shorted input. When multiple input lengths are equal, zip(i1, ...) is similar to map(None, i1, ...), but there is no padding when otherwise. The result of zipping a volatile iterable with itself is undefined. New in 2.0. ------------------------------------------------------------------- There you have it. More information is about 15% fewer words. The reduction came from greatly condensing the overwordy sentence about obsolete behavior into a parenthetical comment. For comparison, here is the current version. ------------------------------------------------------------------- zip( [seq1, ...]) This function returns a list of tuples, where the i-th tuple contains the i-th element from each of the argument sequences. The returned list is truncated in length to the length of the shortest argument sequence. When there are multiple argument sequences which are all of the same length, zip() is similar to map() with an initial argument of None. With a single sequence argument, it returns a list of 1- tuples. With no arguments, it returns an empty list. New in version 2.0. Changed in version 2.4: Formerly, zip() required at least one argument and zip() raised a TypeError instead of returning an empty list.. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 21:25 Message: Logged In: YES user_id=1038590 The generator in the previous comment was incorrect (tuple swallows the StopIteration, so it never terminates). Try this instead: def partition(iterable, part_len): itr = iter(iterable) while 1: item = tuple(islice(itr, part_len)) if len(item) < part_len: raise StopIteration yield item ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 20:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Thu Feb 17 01:05:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 01:05:28 2005 Subject: [ python-Bugs-1117048 ] Dictionary Parsing Problem Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by linkmastersab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:05 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak before the traceback begins, so that the traceback stands out more. An exception for this kind of trivial bug is too expensive for any good that would come out of it. ---------------------------------------------------------------------- Comment By: WalterBrunswick (walterbrunswick) Date: 2005-02-16 18:05 Message: Logged In: YES user_id=1164416 The interpreter begins parsing the dictionary immediately, without buffering and checking for errors beforehand. In the case that an error occurs, such as a faulty key, the interpreter outputs a nasty-looking error - including the error message as part of the dictionary, as you can see from the log (ErrorLog2.log). There is no way that this can be prevented without locating the source of the problem. What I'm saying is that the interpreter should catch the error and raise an exception. But as you said, parsing data streams in chunks is standard; however, I can't see any way around this problem. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 15:07 Message: Logged In: YES user_id=593130 What do you mean by 'dict with an error in it'? I don't know that I can produce such a thing with Python. Or how globals could have an error. I suppose you could give a dict an unprintable key or value (by having __str__ raise an exception), but I would consider that a bug in the program and an error in the key/value and not the dict. I think the behavior on trying to print a collection with such nasty objects is best left undefined. Or do you have something else in mind? In any case, reading and writing data streams in chunks is standard practice. If a dict were large enough, its text representation would not even fit in RAM all at once. And, in any case ... Bug reports should give a specific example of the purported bug, complete with cut and paste of (minimal) code and output or error trace. They may need a reference to the relevant section of the manuals. If you don't have a verifiable example, please close this. Specific feature requests can be submitted as an RFE. Design discussions should be kept to discussion forums. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Thu Feb 17 01:08:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 01:08:18 2005 Subject: [ python-Bugs-1117048 ] Dictionary Parsing Problem Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by linkmastersab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:08 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak before the traceback begins, so that the traceback stands out more. An exception for this kind of trivial bug is too expensive for any good that would come out of it. ---------------------------------------------------------------------- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:05 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak before the traceback begins, so that the traceback stands out more. An exception for this kind of trivial bug is too expensive for any good that would come out of it. ---------------------------------------------------------------------- Comment By: WalterBrunswick (walterbrunswick) Date: 2005-02-16 18:05 Message: Logged In: YES user_id=1164416 The interpreter begins parsing the dictionary immediately, without buffering and checking for errors beforehand. In the case that an error occurs, such as a faulty key, the interpreter outputs a nasty-looking error - including the error message as part of the dictionary, as you can see from the log (ErrorLog2.log). There is no way that this can be prevented without locating the source of the problem. What I'm saying is that the interpreter should catch the error and raise an exception. But as you said, parsing data streams in chunks is standard; however, I can't see any way around this problem. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 15:07 Message: Logged In: YES user_id=593130 What do you mean by 'dict with an error in it'? I don't know that I can produce such a thing with Python. Or how globals could have an error. I suppose you could give a dict an unprintable key or value (by having __str__ raise an exception), but I would consider that a bug in the program and an error in the key/value and not the dict. I think the behavior on trying to print a collection with such nasty objects is best left undefined. Or do you have something else in mind? In any case, reading and writing data streams in chunks is standard practice. If a dict were large enough, its text representation would not even fit in RAM all at once. And, in any case ... Bug reports should give a specific example of the purported bug, complete with cut and paste of (minimal) code and output or error trace. They may need a reference to the relevant section of the manuals. If you don't have a verifiable example, please close this. Specific feature requests can be submitted as an RFE. Design discussions should be kept to discussion forums. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Thu Feb 17 01:55:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 01:55:55 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:09:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:09:31 2005 Subject: [ python-Feature Requests-1122279 ] Option to force variables to be declared Message-ID: Feature Requests item #1122279, was opened at 2005-02-14 05:40 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zac Evans (karadoc) Assigned to: Nobody/Anonymous (nobody) Summary: Option to force variables to be declared Initial Comment: My most common python programming error is to spell a variable different ways in different parts of a program. Often this generates no warnings, and is a difficult problem to track down. The Zen of Python says that 'Explicit is better than Implicit'. I would like it if I could set an option so that I had to explicitly declare variables before I can use them. eg. x = 5 would generate a warning, but x = int() x = 5 would not. I do believe that explicit is better than implicit with respect to programming; and I know that this feature would save me a _lot_ of debugging on my larger python projects. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 20:09 Message: Logged In: YES user_id=593130 x = int() does not 'declare' x. It binds it to the result of calling int without any arguments, which is 0. >>> int() 0 So it is the same as x = 0. Various ideas about declarations and finding typos have been discussed on comp.lang.python and elsewhere. You might review some of the c.l.p threads, possibly via Google. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-15 14:29 Message: Logged In: YES user_id=357491 This will never get in as proposed for technical reasons. What is the difference between ``x=5`` and ``x=int()``? To the compiler they are just assignments to a variable, one just happens to involve a function call. The only way to get the feature you want is to somehow have a more specific way of declaring variables, like a 'var' keyword or something and that will probably never go. As Jim suggested, PyChecker is great for this kind of thing. There are things in the works to help lead to PyChecker being added to the standard library so your problem should get a partial solution included in Python some time in the future. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:57 Message: Logged In: YES user_id=764593 For various reasons, this won't soon get into the core. Meanwhile, there are some tools like pychecker which may help. I've also found that declaring __slots__ makes the errors surface a little bit faster, when I'm dealing with attributes. (The most common reason for me to need the variable name in widely separated places.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:10:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:10:57 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-12 12:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:10 Message: Logged In: YES user_id=80475 The first sentence becomes even less clear with the "in the same order" wording. The note about truncating to the shortest sequence length is essential and should not have been dropped. The py2.4 change note is in a standard form (\versionchanged{} following the explanation of current behavior) and should not have been altered. The part that addresses the OP's concern is too specific to the his one example and is unclear unless you know about that example. The wording is discomforting, doesn't add new information, and is somewhat not obvious in its meaning. I suggest simply changing "sequence" to "iterable". There is no sense in stating that the order of combination is undefined. It doesn't help with the OP's original desire to be able to predict the outcome of the example. However, it does have the negative effect of making a person question whether they've understood the preceding description of what actually zip() does do. zip() is about lockstep iteration and the docs should serve those users as straight-forwardly as possible. The OP's issue on the other hand only comes up when trying funky iterator magic -- adding a sentence about undefined ordering doesn't help one bit. There is a lesson in all this. These tools were borrowed from the world of functional programming which is all about programming that is free of side-effects. The OP's problem should be left as a code smell indicating a misuse of functionals. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:03 Message: Logged In: YES user_id=593130 I agree that the zip doc needs improvement. Confusion will continue until it is. Here is my suggested rewrite: ------------------------------------------------------------------- zip([iterable1, ...]) Return a list of tuples, where the i-th tuple contains the i-th element from each input in the same order as the inputs. With no arguments, return an empty list (before 2.4, a TypeError was raised instead.) With a single input, return a list of 1-tuples. With multiple inputs, the output length is that of the shorted input. When multiple input lengths are equal, zip(i1, ...) is similar to map(None, i1, ...), but there is no padding when otherwise. The result of zipping a volatile iterable with itself is undefined. New in 2.0. ------------------------------------------------------------------- There you have it. More information is about 15% fewer words. The reduction came from greatly condensing the overwordy sentence about obsolete behavior into a parenthetical comment. For comparison, here is the current version. ------------------------------------------------------------------- zip( [seq1, ...]) This function returns a list of tuples, where the i-th tuple contains the i-th element from each of the argument sequences. The returned list is truncated in length to the length of the shortest argument sequence. When there are multiple argument sequences which are all of the same length, zip() is similar to map() with an initial argument of None. With a single sequence argument, it returns a list of 1- tuples. With no arguments, it returns an empty list. New in version 2.0. Changed in version 2.4: Formerly, zip() required at least one argument and zip() raised a TypeError instead of returning an empty list.. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 21:25 Message: Logged In: YES user_id=1038590 The generator in the previous comment was incorrect (tuple swallows the StopIteration, so it never terminates). Try this instead: def partition(iterable, part_len): itr = iter(iterable) while 1: item = tuple(islice(itr, part_len)) if len(item) < part_len: raise StopIteration yield item ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 20:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:23:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:23:10 2005 Subject: [ python-Feature Requests-1122279 ] Option to force variables to be declared Message-ID: Feature Requests item #1122279, was opened at 2005-02-14 05:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Zac Evans (karadoc) Assigned to: Nobody/Anonymous (nobody) Summary: Option to force variables to be declared Initial Comment: My most common python programming error is to spell a variable different ways in different parts of a program. Often this generates no warnings, and is a difficult problem to track down. The Zen of Python says that 'Explicit is better than Implicit'. I would like it if I could set an option so that I had to explicitly declare variables before I can use them. eg. x = 5 would generate a warning, but x = int() x = 5 would not. I do believe that explicit is better than implicit with respect to programming; and I know that this feature would save me a _lot_ of debugging on my larger python projects. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:23 Message: Logged In: YES user_id=80475 This issue comes up every now and then but just goes with the territory because there is no straight-forward way to implement the suggested behavior (in part because Python is built around "duck typing"). My suggestions are to use PyChecker and to create variable names that are less likely to be misspelled. Good doctest or unittest discipline will also save debugging time. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 20:09 Message: Logged In: YES user_id=593130 x = int() does not 'declare' x. It binds it to the result of calling int without any arguments, which is 0. >>> int() 0 So it is the same as x = 0. Various ideas about declarations and finding typos have been discussed on comp.lang.python and elsewhere. You might review some of the c.l.p threads, possibly via Google. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-15 14:29 Message: Logged In: YES user_id=357491 This will never get in as proposed for technical reasons. What is the difference between ``x=5`` and ``x=int()``? To the compiler they are just assignments to a variable, one just happens to involve a function call. The only way to get the feature you want is to somehow have a more specific way of declaring variables, like a 'var' keyword or something and that will probably never go. As Jim suggested, PyChecker is great for this kind of thing. There are things in the works to help lead to PyChecker being added to the standard library so your problem should get a partial solution included in Python some time in the future. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:57 Message: Logged In: YES user_id=764593 For various reasons, this won't soon get into the core. Meanwhile, there are some tools like pychecker which may help. I've also found that declaring __slots__ makes the errors surface a little bit faster, when I'm dealing with attributes. (The most common reason for me to need the variable name in widely separated places.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:24:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:24:17 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 12:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Egon Frerich (friedrich) Assigned to: Nobody/Anonymous (nobody) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:25:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:25:30 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 12:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Egon Frerich (friedrich) Assigned to: Nobody/Anonymous (nobody) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:27:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:27:33 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-02-17 01:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:31:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:31:40 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-02-17 01:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:43:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:43:51 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-02-17 01:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 02:53:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 02:53:47 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-11 20:59 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-16 19:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-11 21:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 21:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 21:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Thu Feb 17 03:52:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 03:52:12 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 21:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 04:33:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 04:33:14 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-02-17 03:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 02:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 05:30:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 05:30:58 2005 Subject: [ python-Bugs-1117048 ] Dictionary Parsing Problem Message-ID: Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 23:30 Message: Logged In: YES user_id=593130 The Python interpreter does not print blank lines except as requested. While a starting linefeed would look nicer in this particular circumstance (error while outputting), I would not want it for two reasons: 1) the circumstance is extremely rare, should usually only result from a program bug, and cannot hardly be detected, so a starting linefeed would nearly always produce an extraneous blank line; 2) without the linefeed, it is completely clear that the error occured in mid-sentence, so to speak. Looking at the informative output, which I don't see as nasty, I see the following: * the error occurred while trying to get the repr of the object (a module) associated with the name 'const'. * in const, you defined a function with the special name __getattr__, which apparently gets treated as a method that overrides the default. (I was not aware you could do this for modules.) * because of the presence of __getattr__, or perhaps because of something else in const, repr() asked const, via __getattr__, whether it has a method __repr__. * your __getattr__ raised proprietary const.ConstError * since this is something other than the expected "return the (computed) attribute value or raise an AttributeError exception" (Ref Man 3.3.2 Customizing attribute access), this ended the globals() call and triggered a traceback. Without seeing the code for const, I wonder whether you really need a custom __setattr__ and __getattr__ (once fixed) or should get rid of them and use the default mechanism. Unless you see a real bug that I missed, please close this report. ---------------------------------------------------------------------- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:08 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak before the traceback begins, so that the traceback stands out more. An exception for this kind of trivial bug is too expensive for any good that would come out of it. ---------------------------------------------------------------------- Comment By: Scott Baldwin (linkmastersab) Date: 2005-02-16 19:05 Message: Logged In: YES user_id=1135743 My opinion on the most feasible solution is to simple insert a linebreak before the traceback begins, so that the traceback stands out more. An exception for this kind of trivial bug is too expensive for any good that would come out of it. ---------------------------------------------------------------------- Comment By: WalterBrunswick (walterbrunswick) Date: 2005-02-16 18:05 Message: Logged In: YES user_id=1164416 The interpreter begins parsing the dictionary immediately, without buffering and checking for errors beforehand. In the case that an error occurs, such as a faulty key, the interpreter outputs a nasty-looking error - including the error message as part of the dictionary, as you can see from the log (ErrorLog2.log). There is no way that this can be prevented without locating the source of the problem. What I'm saying is that the interpreter should catch the error and raise an exception. But as you said, parsing data streams in chunks is standard; however, I can't see any way around this problem. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 15:07 Message: Logged In: YES user_id=593130 What do you mean by 'dict with an error in it'? I don't know that I can produce such a thing with Python. Or how globals could have an error. I suppose you could give a dict an unprintable key or value (by having __str__ raise an exception), but I would consider that a bug in the program and an error in the key/value and not the dict. I think the behavior on trying to print a collection with such nasty objects is best left undefined. Or do you have something else in mind? In any case, reading and writing data streams in chunks is standard practice. If a dict were large enough, its text representation would not even fit in RAM all at once. And, in any case ... Bug reports should give a specific example of the purported bug, complete with cut and paste of (minimal) code and output or error trace. They may need a reference to the relevant section of the manuals. If you don't have a verifiable example, please close this. Specific feature requests can be submitted as an RFE. Design discussions should be kept to discussion forums. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 From noreply at sourceforge.net Thu Feb 17 05:56:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 05:56:35 2005 Subject: [ python-Bugs-1124503 ] IDLE line wrapping Message-ID: Bugs item #1124503, was opened at 2005-02-16 20:56 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=1124503&group_id=5470 Category: IDLE Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Chris Rebert (rebertc) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE line wrapping Initial Comment: As IDLE is the 'official' python editor and PEP 8 (Style Guide PEP) suggests that coders wrap lines at 79 characters, I propose that IDLE should assist this practice by highlighting lines or parts of lines longer than 79 chacacters, or something similar. It is suggested that this be a pref toggleable in the "Configure IDLE" window and be turned on by default to encourage good coding practices. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124503&group_id=5470 From noreply at sourceforge.net Thu Feb 17 05:57:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 05:57:14 2005 Subject: [ python-Bugs-1124503 ] IDLE line wrapping Message-ID: Bugs item #1124503, was opened at 2005-02-16 20:56 Message generated for change (Settings changed) made by rebertc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124503&group_id=5470 Category: IDLE Group: Feature Request Status: Open Resolution: None >Priority: 4 Submitted By: Chris Rebert (rebertc) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE line wrapping Initial Comment: As IDLE is the 'official' python editor and PEP 8 (Style Guide PEP) suggests that coders wrap lines at 79 characters, I propose that IDLE should assist this practice by highlighting lines or parts of lines longer than 79 chacacters, or something similar. It is suggested that this be a pref toggleable in the "Configure IDLE" window and be turned on by default to encourage good coding practices. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124503&group_id=5470 From noreply at sourceforge.net Thu Feb 17 06:10:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 06:10:17 2005 Subject: [ python-Bugs-1121475 ] Decorated functions are unpickleable Message-ID: Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. ========================== Examples: ========================== >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ... return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ..... pickle.PicklingError: Can't pickle : it's not the same object as __main__.func ============================== I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: ================================== >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ... return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-16 21:10 Message: Logged In: YES user_id=357491 It would be nice if you could pickle decorated functions, but the way pickle works won't allow it unless the decorator just passes the function right along: >>> def dec(func): ... func.meta = "foo" ... return func ... >>> @dec ... def blah(): pass ... >>> pickle.dumps(blah) 'c__main__\nblah\np0\n.' So it is not a hard rule that decorated functions are not pickleable. It all depends on how the decorator messes with the function it is given. If you think the documentation for pickle is misleading then please submit a documentation patch to clarify that decorators could cause issues if they return the function wrapped. ---------------------------------------------------------------------- Comment By: S Joshua Swamidass (sswamida) Date: 2005-02-15 17:45 Message: Logged In: YES user_id=786138 Yes, everything you said is correct, though i think this is not ideal behavior. If we decorate a function at the top level of a module, shouldn't it be pickleable? If not, then as my original point was, decorated functions are not compatible with pickle. Is there any case you can give me where a decorated function is defined in the top level of a module and can be pickled? I can't think of one, but i could be wrong. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-15 17:21 Message: Logged In: YES user_id=357491 If you read the pickle docs it says you can only pickle "functions defined at the top level of a module". The lambdas are you having your decorator return are not defined at the module level and thus do not meet that requirement. The same basic issue goes with your callable class. The function you are storing in self.f is not the same as was is defined at the module level since self.f is 'func' prior to wrapping while what 'func' has at the global level is an instance of 'C'. The reason your example works is because '_func` is defined at the module level and thus pickle can find it to pickle. Decorators skip the intermediate step of storing the undecorated function at the module level. It would be better to use the pickling protocol to define methods to allow your callable class to help with the pickling process. And just so you know, your class examples should be calling self.f instead of f. Closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 From noreply at sourceforge.net Thu Feb 17 06:18:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 06:18:13 2005 Subject: [ python-Bugs-1124278 ] PyDateTime_FromDateAndTime documented as PyDate_FromDateAndT Message-ID: Bugs item #1124278, was opened at 2005-02-16 13:11 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124278&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: smilechaser (smilechaser) Assigned to: Nobody/Anonymous (nobody) Summary: PyDateTime_FromDateAndTime documented as PyDate_FromDateAndT Initial Comment: In datetime.h there exists a macro called: PyDateTime_FromDateAndTime but in the documentation (7.5.12 of the Python/C API Reference Manual) it is documented as: PyDate_FromDateAndTime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-16 21:18 Message: Logged In: YES user_id=357491 Fixed in rev. 1.60 for 2.5 and rev. 1.58.2.2 in 2.4 for Doc/api/ concrete.tex . Thanks, smilechaser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124278&group_id=5470 From noreply at sourceforge.net Thu Feb 17 06:22:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 06:22:09 2005 Subject: [ python-Bugs-1124513 ] test_os fails on 2.4 Message-ID: Bugs item #1124513, was opened at 2005-02-16 21: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=1124513&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 From noreply at sourceforge.net Thu Feb 17 06:25:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 06:25:38 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 22:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 21:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 11:32:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 11:32:14 2005 Subject: [ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode Message-ID: Bugs item #1124295, was opened at 2005-02-16 21:34 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: Tres Seaver (tseaver) Assigned to: Tim Peters (tim_one) Summary: Function's __name__ no longer accessible in restricted mode Initial Comment: This change breaks an obscure bit of Zope's security machinery, which uses the __name__ of a function to construct the synthetic attribute name under which the roles for a method are stored. $ ../bin/python2.3 Python 2.3.4 (#3, Jan 27 2005, 10:46:13) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs func >>> ^D $ ../bin/python2.4 Python 2.4 (#1, Feb 16 2005, 13:11:02) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs Traceback (most recent call last): File "", line 1, in ? File "", line 3, in ? RuntimeError: function attributes not accessible in restricted mode >>> ^D ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-17 10:32 Message: Logged In: YES user_id=6656 Oops. My fault, easy to fix. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-16 21:58 Message: Logged In: YES user_id=31435 Assigned to me, and boosted priority, since this should be addressed for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 From noreply at sourceforge.net Thu Feb 17 11:44:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 11:44:11 2005 Subject: [ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode Message-ID: Bugs item #1124295, was opened at 2005-02-16 21:34 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Tres Seaver (tseaver) >Assigned to: Michael Hudson (mwh) Summary: Function's __name__ no longer accessible in restricted mode Initial Comment: This change breaks an obscure bit of Zope's security machinery, which uses the __name__ of a function to construct the synthetic attribute name under which the roles for a method are stored. $ ../bin/python2.3 Python 2.3.4 (#3, Jan 27 2005, 10:46:13) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs func >>> ^D $ ../bin/python2.4 Python 2.4 (#1, Feb 16 2005, 13:11:02) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs Traceback (most recent call last): File "", line 1, in ? File "", line 3, in ? RuntimeError: function attributes not accessible in restricted mode >>> ^D ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-17 10:44 Message: Logged In: YES user_id=6656 Fixed on HEAD in Objects/funcobject.c revision 2.68 Lib/test/test_funcattrs.py revision 1.17 and on 24-maint in Objects/funcobject.c revision 2.67.2.1 Lib/test/test_funcattrs.py revision 1.16.2.1 Copy and paste are evil... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-17 10:32 Message: Logged In: YES user_id=6656 Oops. My fault, easy to fix. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-16 21:58 Message: Logged In: YES user_id=31435 Assigned to me, and boosted priority, since this should be addressed for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 From noreply at sourceforge.net Thu Feb 17 12:10:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 12:10:15 2005 Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Message-ID: Bugs item #1124637, was opened at 2005-02-17 11: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=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter ?strand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 From noreply at sourceforge.net Thu Feb 17 12:18:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 12:18:35 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 17:28 Message generated for change (Comment added) made by friedrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Egon Frerich (friedrich) Assigned to: Nobody/Anonymous (nobody) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Egon Frerich (friedrich) Date: 2005-02-17 11:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Thu Feb 17 12:50:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 12:50:50 2005 Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Message-ID: Bugs item #1124637, was opened at 2005-02-17 12:10 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter ?strand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-02-17 12:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 From noreply at sourceforge.net Thu Feb 17 13:09:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 13:09:38 2005 Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Message-ID: Bugs item #1124637, was opened at 2005-02-17 11:10 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter ?strand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-17 12:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-02-17 11:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 From noreply at sourceforge.net Thu Feb 17 14:08:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 14:08:19 2005 Subject: [ python-Bugs-1124692 ] Math mode not well handled in \documentclass{howto} Message-ID: Bugs item #1124692, was opened at 2005-02-17 13: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=1124692&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Math mode not well handled in \documentclass{howto} Initial Comment: LaTeX loses its Math Magic (tm) when using \documentclass{howto}: underscore operator in math enviroment doesn't produce subscripts. This documents shows some oddities: \documentclass{howto} \begin{document} Water is $H_2O$, and subscript is missing from... \[ V_{0,r} \] Superscripts are instead fine, as $e^{\pi i} + 1 = 0$ shows. Also this is completely different from what obtained by \textbackslash documentclass\{article\}. \[ \sum_{k=0}^\infty \int_0^k f(x) dx \] \end{document} The bug is removed by commenting out lines 541--549 in python.sty, but i don't know how to *fix* them... (not a TeXpert) Using Python 2.3.5, Windows 2000, LaTeX2e (e-TeX 3.141592-2.2, MikTex 2.4 implementation) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470 From noreply at sourceforge.net Thu Feb 17 14:16:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 14:16:59 2005 Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Message-ID: Bugs item #1124637, was opened at 2005-02-17 22:10 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter ?strand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-18 00:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-17 23:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-02-17 22:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 From noreply at sourceforge.net Thu Feb 17 14:42:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 14:43:05 2005 Subject: [ python-Bugs-881522 ] Shelve slow after 7/8000 key Message-ID: Bugs item #881522, was opened at 2004-01-21 17:09 Message generated for change (Comment added) made by marcoberi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=881522&group_id=5470 Category: Python Library Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Marco Beri (marcoberi) Assigned to: Gregory P. Smith (greg) Summary: Shelve slow after 7/8000 key Initial Comment: After about 8.000 insertion shelve became really, really slow. This happens only with 2.3.3 #51 on Windows, not with 2.2 and with 2.3 on Linux. I try with writeback True or False: same problem. Help! :-)) ---------------------------------------------------------------------- >Comment By: Marco Beri (marcoberi) Date: 2005-02-17 13:42 Message: Logged In: YES user_id=588604 FYI, with Python 2.4 speed is again ok. So problem are confined to 2.3 version (also 2.3.5 has the shelve slow problem). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-04-22 01:39 Message: Logged In: YES user_id=31435 As threatened months ago, closed as 3rd Party, Won't Fix -- there's no sign that this will ever make progress. ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-23 10:03 Message: Logged In: YES user_id=588604 I mean: I didn't try with python 2.3 on linux (just with python 2.2) ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-23 10:01 Message: Logged In: YES user_id=588604 I give a wrong info: I didn't try it on Linux so I'm not so sure it's a windows specific problem. Besides this, looking at 2004-01-22 18:32 greg comment, it's seems that also Linux - alpha version has this problem. Probably it's better to modify category to "Python library"? ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-23 00:44 Message: Logged In: YES user_id=588604 jkew, also I god a bit of a headache. I was pretty sure to improve performances with Python 2.3.3, while they get incredibly worse. I know perhaps this is a third-party issue, but I use a python feature (shelve) and at least I think that it's better to remove it or signal this problem in the documentation. We are talking about few thousand key, not billions! BTW I didn't post twice the previuos message. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2004-01-23 00:16 Message: Logged In: YES user_id=598066 FWIW2, on skip's "miserable hack" comment below, vis-a-vis running shelve on btree: isn't this exactly the sort of thing shelve.Shelf is intended for? import bsddb import shelve db = bsddb.btopen("temp.db") sh = shelve.Shelf(db) # do stuff with sh sh.close() # automatically calls close() on the underlying db (Not sure why Shelf and friends are documented on shelve's "Restrictions" subsection...) ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-23 00:08 Message: Logged In: YES user_id=588604 I get your same results under normal cmd: 7.07 seconds vs 0.46. [c:\tmp]timer & \python23\python test3skip.py hashopen & timer Timer 1 on: 19.13.22 Timer 1 off: 19.13.29 Elapsed: 0.00.07,07 [c:\tmp]timer & \python23\python test3skip.py btopen & timer Timer 1 on: 19.13.45 Timer 1 off: 19.13.45 Elapsed: 0.00.00,46 ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2004-01-22 23:53 Message: Logged In: YES user_id=598066 FWIW, to throw another use case into the pot: I (used to) run Roundup (roundup.sf.net) trackers on anydbm/Win2K and experienced a significant drop in performance between 2.2.x (bsddb185) and 2.3.x (dbhash). I understand that this is a third-party issue, and that there were significant known problems with bsddb 1.85, but it did cause me a bit of a double-take after having heard so much about Python 2.3 being faster... I say "used to" because the slowdown prompted me to migrate to Roundup's sqlite backend, solving my problem. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-22 21:11 Message: Logged In: YES user_id=44345 If we wanted speed and didn't care about corruption, my vote would be bsddb185. ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-22 20:36 Message: Logged In: YES user_id=31435 Greg, I didn't expect you to fix it , I just didn't want the bug report closed based on misunderstanding what it was about. I've unassigned this item, and if nobody volunteers to dig into it within a few weeks, it should indeed be closed as "3rd Party" and "Wont Fix Skip, maybe we should try to force spambayes to use a btree mapping too -- then maybe we could get a whole new class of intractable corruption errors . ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-22 20:28 Message: Logged In: YES user_id=44345 Whoops, sorry about polluting the waters with the btree stuff. Dang time lag. Looking at just the hashopen times between 2.2, 2.3 and 2.4 does show that it hash file times have gotten worse since Berkeley 1.85 days. Whether or not btree times muddy these particular waters, figuring out a way to switch to a different db type and still use the shelve module may be Marco's best bet for a short term performance improvement. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-22 20:22 Message: Logged In: YES user_id=44345 I guess I get similar results on Mac OS X after looking at it a bit. The differences are just not as dramatic (or disappointing) as they are on Windows. Here's the output of a little shell script which runs test3skip.py with various Python interpreters and Berkeley DB versions: Python version: (2, 4, 0, 'alpha', 0) Berkeley DB version: 4.2.4 hashopen: 0m1.621s btopen: 0m0.608s Python version: (2, 3, 3, 'final', 0) Berkeley DB version: 4.2.0 hashopen: 0m1.359s btopen: 0m0.450s Python version: (2, 2, 0, 'final', 0) Berkeley DB version: ??? hashopen: 0m0.514s btopen: 0m0.202s Only real (wall clock) times are displayed. Mario, Unfortunately, there doesn't seem to be much we can do at this end to remedy the situation with hash files. If you want to use shelve but switch to bsddb.btopen as the underlying db file open call, try posting to comp.lang.python. Anything you do will probably be a miserable hack, but we can probably figure something out. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-01-22 19:12 Message: Logged In: YES user_id=413 python 2.2 and earlier on windows linked against some form of bsddb 1.85. python 2.3 and later link against modern BerkeleyDB (not really related to bsddb 1.85 much at all other than by name and a legacy api). They are very different libraries with very different capabilities and performance. regardless, i don't have a windows development platform anymore. someone who does, please take this. i suspect this is not something we can fix. try asking sleepycat why modern DB_HASH databases might be slower than bsddb 1.85 hash databases on windows and see what they say. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-22 18:56 Message: Logged In: YES user_id=31435 The original question is why a BDB hash is some 30x slower under 2.3 than under 2.2 or 2.1, and that does appear specific to Windows. Skip threw btrees into this too, but that complication doesn't appear relevant to the original report (despite marcoberi's hearsay 2004-01-21 18:57 comment -- others posted actual output, making clear that dbhash is used under all Python versions in test1skip). I'll note in passing that the test case inserts keys in already- mostly-sorted order, which is a friendly order for a btree- based mapping. To get back to the original report, ignore everything here concerning test3skip and btrees. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-01-22 18:32 Message: Logged In: YES user_id=413 This problem is not specific to windows. hashopen in the test3skip.py test case is 10x slower than btopen on my linux-alpha system. I don't know why BerkeleyDB hash databases are so much slower than B-Tree ones. My best suggestion is: if it hurts, don't do that. Use a btree rather thah hash database. Running the python process under strace on linux reveals nothing obvious (no system calls are being made during the time hash open is consuming lots of cpu... You'll have to ask sleepycat themselves if you want a real answer as to why hash databases don't perform well. ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-22 18:16 Message: Logged In: YES user_id=588604 I get your same results under normal cmd: 7.07 seconds vs 0.46. [c:\tmp]timer & \python23\python test3skip.py hashopen & timer Timer 1 on: 19.13.22 Timer 1 off: 19.13.29 Elapsed: 0.00.07,07 [c:\tmp]timer & \python23\python test3skip.py btopen & timer Timer 1 on: 19.13.45 Timer 1 off: 19.13.45 Elapsed: 0.00.00,46 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-22 18:02 Message: Logged In: YES user_id=44345 Try test3skip.py. You run it like this: python test3skip.py hashopen python test3skip.py btopen I ran it on win2k under cygwin so I could use the time command (but ran the Windows version of Python). Using btopen was much faster. I got rid of shelve to eliminate it and pickle as possible sources of problems. $ time /cygdrive/c/Python23/python test3skip.py hashopen real 0m6.801s user 0m0.015s sys 0m0.000s Administrator@CYCLOPS ~/tmp $ time /cygdrive/c/Python23/python test3skip.py btopen real 0m0.345s user 0m0.015s sys 0m0.015s I don't know if the relationship between real, user and sys time means anything on cygwin, but the reported real times are very repeatable and match my subjective feel of the elapsed time. This suggests there's something fishy with either the underlying library or with __setitem__ when using hash files. I'm assigning to Greg so he can take a peek. As the bsddb/ pybsddb guy he might have some better insight (certainly better than me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-22 18:01 Message: Logged In: YES user_id=44345 Try test3skip.py. You run it like this: python test3skip.py hashopen python test3skip.py btopen I ran it on win2k under cygwin so I could use the time command (but ran the Windows version of Python). Using btopen was much faster. I got rid of shelve to eliminate it and pickle as possible sources of problems. $ time /cygdrive/c/Python23/python test3skip.py hashopen real 0m6.801s user 0m0.015s sys 0m0.000s Administrator@CYCLOPS ~/tmp $ time /cygdrive/c/Python23/python test3skip.py btopen real 0m0.345s user 0m0.015s sys 0m0.015s I don't know if the relationship between real, user and sys time means anything on cygwin, but the reported real times are very repeatable and match my subjective feel of the elapsed time. This suggests there's something fishy with either the underlying library or with __setitem__ when using hash files. I'm assigning to Greg so he can take a peek. As the bsddb/ pybsddb guy he might have some better insight (certainly better than me). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-22 17:29 Message: Logged In: YES user_id=31435 FYI, on a Win98SE box, test1skip.py took about 30 seconds under 2.3.3, and about 1 second under both 2.2.3 and 2.1.3. Under 2.3.3, no significant time is taken by a.close(), so it's all in the loop. It prints "dbhash" under all versions. ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-22 07:30 Message: Logged In: YES user_id=588604 I tried your version: 31.36 seconds vs 0.65. Just to be sure I tried on three different computers with Windows 2000: same gap. [c:\tmp]timer & \Python23\python test1skip.py & timer Timer 1 on: 8.21.58 dbhash Timer 1 off: 8.22.29 Elapsed: 0.00.31,36 [c:\tmp]timer & \Python22\python test1skip.py & timer Timer 1 on: 8.22.40 dbhash Timer 1 off: 8.22.41 Elapsed: 0.00.00,65 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-01-22 00:28 Message: Logged In: YES user_id=44345 Can't reproduce on Mac OS X. I tried with 2.2, 2.3 and CVS using attached test1skip.py (no writeback - 2.2 doesn't support it, no import pickle - not used, no key prints - just muddies the water, print whichdb's result). The times are close enough to not worry me: montanaro:tmp% time python2.3 test1.py dbhash real 0m1.927s user 0m1.720s sys 0m0.080s montanaro:tmp% time python2.2 test1.py dbhash real 0m1.250s user 0m0.850s sys 0m0.360s montanaro:tmp% time python test1.py dbhash real 0m2.179s user 0m1.950s sys 0m0.120s Please try this modified version just to make sure we are both looking at the same thing. ---------------------------------------------------------------------- Comment By: Marco Beri (marcoberi) Date: 2004-01-21 23:57 Message: Logged In: YES user_id=588604 Skip Montanaro discovered that whichdb repors bsddb185 with python 2.2 and dbhash with 2.3.3. So why is it so slow after few thousand keys? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-01-21 18:24 Message: Logged In: YES user_id=11105 Hm, are windows bugs automatically assigned to me ;-)?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=881522&group_id=5470 From noreply at sourceforge.net Thu Feb 17 16:13:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 16:13:39 2005 Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Message-ID: Bugs item #1124637, was opened at 2005-02-17 06:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter ?strand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-17 10:13 Message: Logged In: YES user_id=31435 Peculiar -- test_subprocess takes about 8 seconds on my WinXP box release build, about 10 seconds debug build, and Windows is notorious for slow process creation. That's a zippy 3.4 GHz P4, but clock rate alone can't account for such a large speed difference. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-17 08:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-17 07:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-02-17 06:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 From noreply at sourceforge.net Thu Feb 17 16:17:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 16:17:23 2005 Subject: [ python-Bugs-1124637 ] test_subprocess is far too slow Message-ID: Bugs item #1124637, was opened at 2005-02-17 12:10 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter ?strand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2005-02-17 16:17 Message: Logged In: YES user_id=344921 tim_one: test_subprocess only creates 65 processes on Windows, compared to 1026 for UNIX. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:13 Message: Logged In: YES user_id=31435 Peculiar -- test_subprocess takes about 8 seconds on my WinXP box release build, about 10 seconds debug build, and Windows is notorious for slow process creation. That's a zippy 3.4 GHz P4, but clock rate alone can't account for such a large speed difference. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-17 14:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-17 13:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-02-17 12:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 From noreply at sourceforge.net Thu Feb 17 16:39:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 16:39:04 2005 Subject: [ python-Bugs-1124513 ] test_os fails on 2.4 Message-ID: Bugs item #1124513, was opened at 2005-02-17 00:22 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-17 10:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 From noreply at sourceforge.net Thu Feb 17 16:55:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 16:55:42 2005 Subject: [ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode Message-ID: Bugs item #1124295, was opened at 2005-02-16 16:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 8 Submitted By: Tres Seaver (tseaver) Assigned to: Michael Hudson (mwh) Summary: Function's __name__ no longer accessible in restricted mode Initial Comment: This change breaks an obscure bit of Zope's security machinery, which uses the __name__ of a function to construct the synthetic attribute name under which the roles for a method are stored. $ ../bin/python2.3 Python 2.3.4 (#3, Jan 27 2005, 10:46:13) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs func >>> ^D $ ../bin/python2.4 Python 2.4 (#1, Feb 16 2005, 13:11:02) [GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> code = """... def func(): ... pass ... print func.__name__ ... """ >>> exec code func >>> globs = {'__builtins__':{}} >>> exec code in globs Traceback (most recent call last): File "", line 1, in ? File "", line 3, in ? RuntimeError: function attributes not accessible in restricted mode >>> ^D ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-17 10:55 Message: Logged In: YES user_id=31435 Thanks, Michael! It _looked_ like a copy-paste glitch . I've confirmed that the specific failing Zope test works with current release24-maint branch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-17 05:44 Message: Logged In: YES user_id=6656 Fixed on HEAD in Objects/funcobject.c revision 2.68 Lib/test/test_funcattrs.py revision 1.17 and on 24-maint in Objects/funcobject.c revision 2.67.2.1 Lib/test/test_funcattrs.py revision 1.16.2.1 Copy and paste are evil... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-17 05:32 Message: Logged In: YES user_id=6656 Oops. My fault, easy to fix. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-16 16:58 Message: Logged In: YES user_id=31435 Assigned to me, and boosted priority, since this should be addressed for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470 From noreply at sourceforge.net Thu Feb 17 17:14:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 17:14:15 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 11:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 22:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 21:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 17:23:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 17:23:12 2005 Subject: [ python-Bugs-1124861 ] GetStdHandle in interactive GUI Message-ID: Bugs item #1124861, was opened at 2005-02-17 11: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=1124861&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: davids (davidschein) Assigned to: Nobody/Anonymous (nobody) Summary: GetStdHandle in interactive GUI Initial Comment: Using the suprocess module from with IDLE or PyWindows, it appears that calls GetStdHandle (STD__HANDLE) returns None, which causes an error. (All appears fine on Linux, the standard Python command-line, and ipython.) For example: >>> import subprocess >>> p = subprocess.Popen("dir", stdout=subprocess.PIPE) Traceback (most recent call last): File "", line 1, in -toplevel- p = subprocess.Popen("dir", stdout=subprocess.PIPE) File "C:\Python24\lib\subprocess.py", line 545, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 605, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 646, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required The error originates in the mswindows implementation of _get_handles. You need to set one of stdin, stdout, or strerr because the first line in the method is: if stdin == None and stdout == None and stderr == None: ...return (None, None, None, None, None, None) I added "if not handle: return GetCurrentProcess()" to _make_inheritable() as below and it worked. Of course, I really do not know what is going on, so I am letting go now... def _make_inheritable(self, handle): ..."""Return a duplicate of handle, which is inheritable""" ...if not handle: return GetCurrentProcess() ...return DuplicateHandle(GetCurrentProcess(), handle, ....................................GetCurrentProcess(), 0, 1, ....................................DUPLICATE_SAME_ACCESS) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470 From noreply at sourceforge.net Thu Feb 17 17:55:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 17:55:58 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2005-02-17 16:55 Message: Logged In: YES user_id=72053 Well, I don't see an obvious way to reclassify this item. If someone knows how to do it, please go ahead. I sent an email to the lawyer and haven't gotten a response yet. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 16:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 05:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 03:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 02:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 01:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 18:45:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 18:45:56 2005 Subject: [ python-Bugs-1123660 ] add SHA256/384/512 to lib Message-ID: Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 12:45 Message: Logged In: YES user_id=593130 Ok, next time.... You might want to look at https://sourceforge.net/tracker/index.php? func=detail&aid=1121611&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 11:55 Message: Logged In: YES user_id=72053 Well, I don't see an obvious way to reclassify this item. If someone knows how to do it, please go ahead. I sent an email to the lawyer and haven't gotten a response yet. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 11:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 22:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 21:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 From noreply at sourceforge.net Thu Feb 17 21:33:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 21:33:19 2005 Subject: [ python-Bugs-1126208 ] subprocess.py Errors with IDLE Message-ID: Bugs item #1126208, was opened at 2005-02-17 15: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=1126208&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Peter ?strand (astrand) Summary: subprocess.py Errors with IDLE Initial Comment: ===================== From: David S. alumni.tufts.edu> Subject: subprocess problem on Windows in IDLE and PythonWin Newsgroups: gmane.comp.python.general Date: Wed, 16 Feb 2005 02:05:24 +0000 Python 2.4 on Windows XP In the python command-line the following works fine: >>> from subprocess import * >>> p = Popen('dir', stdout=PIPE) >From within IDLE or PythonWin I get the following exception: Traceback (most recent call last): File "", line 1, in -toplevel- p = Popen('dir', stdout=PIPE) File "c:\python24\lib\subprocess.py", line 545, in __init__ (p2cread, p2cwrite, File "c:\python24\lib\subprocess.py", line 605, in _get_handles p2cread = self._make_inheritable(p2cread) File "c:\python24\lib\subprocess.py", line 646, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required Note it works fine on Linux also. I tested it with >>> p = Popen('ls', stdout=PIPE) ... and had no trouble. =========== I (KBK) can duplicate this on W2K using 2.4. If I run IDLE with the -n switch (no subprocess) the error doesn't occur. Unfortunately, I can't debug it because I don't have the necessary tools on Windows. It appears that the problem is in _subprocess.c:sp_DuplicateHandle(), likely that PyArg_ParseTuple() is OK but the failure occurs in the call to DuplicateHandle(). All the args to sp_DuplicateHandle() seem to be the right type. DUPLICATE_SAME_ACCESS is an integer, value 2 To find out what's going on, it would seem necessary to attach a windows debugger to IDLE's subprocess (not the IDLE GUI). Let me know if I can help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1126208&group_id=5470 From noreply at sourceforge.net Thu Feb 17 22:24:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 22:24:58 2005 Subject: [ python-Bugs-1124513 ] test_os fails on 2.4 Message-ID: Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 From noreply at sourceforge.net Thu Feb 17 22:27:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 22:27:46 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Thu Feb 17 22:30:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 22:31:02 2005 Subject: [ python-Bugs-1124513 ] test_os fails on 2.4 Message-ID: Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-02-17 22:30 Message: Logged In: YES user_id=89016 The new implementation of os._Environ.update() assumes that the argument dict is a mapping, if it provides a method items(), otherwise it treats it as an item sequence. Unfortunately the SimpleUserDict from mapping_tests.py provides only keys() and __getitem__(). So what is the minimal mapping interface? UserDict.DictMixin claims that keys and __getitem__ (and __setitem__ and __delitem__) is enough and adding __contains__, __iter__ and iteritems increases performance. So should update() try iteritems() or should an items() method be added to the SimpleUserDict in the test? CVS HEAD does not fail, because a test method test_update() has been added there, which hides the original method from mapping_tests.BasicTestMappingProtocol. Adding a call mapping_tests.BasicTestMappingProtocol.test_update(self) there results in the same exception as on the release24-maint branch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 From noreply at sourceforge.net Thu Feb 17 22:33:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 22:34:03 2005 Subject: [ python-Bugs-1124513 ] test_os fails on 2.4 Message-ID: Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-02-17 22:33 Message: Logged In: YES user_id=89016 Oops, seems are comments have crossed, thanks for the fix. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-17 22:30 Message: Logged In: YES user_id=89016 The new implementation of os._Environ.update() assumes that the argument dict is a mapping, if it provides a method items(), otherwise it treats it as an item sequence. Unfortunately the SimpleUserDict from mapping_tests.py provides only keys() and __getitem__(). So what is the minimal mapping interface? UserDict.DictMixin claims that keys and __getitem__ (and __setitem__ and __delitem__) is enough and adding __contains__, __iter__ and iteritems increases performance. So should update() try iteritems() or should an items() method be added to the SimpleUserDict in the test? CVS HEAD does not fail, because a test method test_update() has been added there, which hides the original method from mapping_tests.BasicTestMappingProtocol. Adding a call mapping_tests.BasicTestMappingProtocol.test_update(self) there results in the same exception as on the release24-maint branch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 From noreply at sourceforge.net Thu Feb 17 22:44:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 22:44:26 2005 Subject: [ python-Bugs-1124513 ] test_os fails on 2.4 Message-ID: Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-17 22:33 Message: Logged In: YES user_id=89016 Oops, seems are comments have crossed, thanks for the fix. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-17 22:30 Message: Logged In: YES user_id=89016 The new implementation of os._Environ.update() assumes that the argument dict is a mapping, if it provides a method items(), otherwise it treats it as an item sequence. Unfortunately the SimpleUserDict from mapping_tests.py provides only keys() and __getitem__(). So what is the minimal mapping interface? UserDict.DictMixin claims that keys and __getitem__ (and __setitem__ and __delitem__) is enough and adding __contains__, __iter__ and iteritems increases performance. So should update() try iteritems() or should an items() method be added to the SimpleUserDict in the test? CVS HEAD does not fail, because a test method test_update() has been added there, which hides the original method from mapping_tests.BasicTestMappingProtocol. Adding a call mapping_tests.BasicTestMappingProtocol.test_update(self) there results in the same exception as on the release24-maint branch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 From noreply at sourceforge.net Thu Feb 17 23:46:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 17 23:46:32 2005 Subject: [ python-Bugs-1138653 ] subprocesss module retains older license header Message-ID: Bugs item #1138653, was opened at 2005-02-17 17: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=1138653&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: subprocesss module retains older license header Initial Comment: The header of the file seems to imply that the module is licensed separately from the standard Python license: # subprocess - Subprocesses with accessible I/O streams # # For more information about this module, see PEP 324. # # Copyright (c) 2003-2004 by Peter Astrand # # By obtaining, using, and/or copying this software and/or its # associated documentation, you agree that you have read, understood, # and will comply with the following terms and conditions: # # Permission to use, copy, modify, and distribute this software and # its associated documentation for any purpose and without fee is # hereby granted, provided that the above copyright notice appears in # all copies, and that both that copyright notice and this permission # notice appear in supporting documentation, and that the name of the # author not be used in advertising or publicity pertaining to # distribution of the software without specific, written prior # permission. # # THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS # OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, # NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION # WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470 From noreply at sourceforge.net Fri Feb 18 08:13:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 08:13:12 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by ekloef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: daniel (ekloef) Date: 2005-02-18 08:13 Message: Logged In: YES user_id=1216071 libpythonVERSION.a which is installed in lib/pythonVERSION/config/ But like I said, this bug is only triggered if the lib and the application linking against the lib is compiled on systems with different glibc-versions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Fri Feb 18 09:32:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 09:32:06 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-18 09:32 Message: Logged In: YES user_id=21627 I see. The patch is not acceptable - what if the next version of the Linux C library needs again more bytes in the structure? The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. So in fact, an installation with NPTL should be considered as a different operating system, and you cannot expect to move binaries from one operating system to another. Instead, you have to recompile the binaries. Notice that the problem is *not* restricted to the static library. If the application is linked to the shared libpython, and if you not only move the application from one system to another, but also the shared library (e.g. because the target system does not have a libpython), the same problem occurs. So this is really a bug in Linux, which fails to provide binary compatibility across installations. Closing as third-party bug. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-18 08:13 Message: Logged In: YES user_id=1216071 libpythonVERSION.a which is installed in lib/pythonVERSION/config/ But like I said, this bug is only triggered if the lib and the application linking against the lib is compiled on systems with different glibc-versions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Fri Feb 18 09:41:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 09:41:42 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by ekloef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: daniel (ekloef) Date: 2005-02-18 09:41 Message: Logged In: YES user_id=1216071 No, the problem does NOT exist with the dynamic library since it will reference versioned glibc-functions (i.e the dynamic python library will use the backward compatible functions that is present in glibc). This is why compiling and linking static library and application on the same system is not a problem; the resulting binary will run on both linuxthreads and NPTL systems, since they will use the versioned glibc functions. However, a static library does not reference versioned functions until it is linked with either a shared library or an application. Thus, if you compile the static library on a linuxthreads systems but link an application against it on a NPTL systems, things will break, since the static library expects an older version of glibc but gets linked against a new version. But yes, this is not a python bug. It jsut took some time for me fully understand the linking process regarding the versioned glibc functions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-18 09:32 Message: Logged In: YES user_id=21627 I see. The patch is not acceptable - what if the next version of the Linux C library needs again more bytes in the structure? The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. So in fact, an installation with NPTL should be considered as a different operating system, and you cannot expect to move binaries from one operating system to another. Instead, you have to recompile the binaries. Notice that the problem is *not* restricted to the static library. If the application is linked to the shared libpython, and if you not only move the application from one system to another, but also the shared library (e.g. because the target system does not have a libpython), the same problem occurs. So this is really a bug in Linux, which fails to provide binary compatibility across installations. Closing as third-party bug. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-18 08:13 Message: Logged In: YES user_id=1216071 libpythonVERSION.a which is installed in lib/pythonVERSION/config/ But like I said, this bug is only triggered if the lib and the application linking against the lib is compiled on systems with different glibc-versions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Fri Feb 18 09:54:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 09:54:22 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-18 09:54 Message: Logged In: YES user_id=21627 So the problem occurs only when you move the static Python library from one system to another - not, say, if you move an application linked with the static library. Why would you want to move the static libpython from one system to another? ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-18 09:41 Message: Logged In: YES user_id=1216071 No, the problem does NOT exist with the dynamic library since it will reference versioned glibc-functions (i.e the dynamic python library will use the backward compatible functions that is present in glibc). This is why compiling and linking static library and application on the same system is not a problem; the resulting binary will run on both linuxthreads and NPTL systems, since they will use the versioned glibc functions. However, a static library does not reference versioned functions until it is linked with either a shared library or an application. Thus, if you compile the static library on a linuxthreads systems but link an application against it on a NPTL systems, things will break, since the static library expects an older version of glibc but gets linked against a new version. But yes, this is not a python bug. It jsut took some time for me fully understand the linking process regarding the versioned glibc functions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-18 09:32 Message: Logged In: YES user_id=21627 I see. The patch is not acceptable - what if the next version of the Linux C library needs again more bytes in the structure? The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. So in fact, an installation with NPTL should be considered as a different operating system, and you cannot expect to move binaries from one operating system to another. Instead, you have to recompile the binaries. Notice that the problem is *not* restricted to the static library. If the application is linked to the shared libpython, and if you not only move the application from one system to another, but also the shared library (e.g. because the target system does not have a libpython), the same problem occurs. So this is really a bug in Linux, which fails to provide binary compatibility across installations. Closing as third-party bug. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-18 08:13 Message: Logged In: YES user_id=1216071 libpythonVERSION.a which is installed in lib/pythonVERSION/config/ But like I said, this bug is only triggered if the lib and the application linking against the lib is compiled on systems with different glibc-versions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Fri Feb 18 10:03:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 10:03:27 2005 Subject: [ python-Bugs-1119860 ] Static library incompatible with nptl Message-ID: Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by ekloef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. ---------------------------------------------------------------------- >Comment By: daniel (ekloef) Date: 2005-02-18 10:03 Message: Logged In: YES user_id=1216071 Correct. If you already have a number of python libraries for different architectures, then you don't want to further increase that number by having multiple libraries for one or more architectures. It's a pain to maintain. But you may still want to build the main application on different systems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-18 09:54 Message: Logged In: YES user_id=21627 So the problem occurs only when you move the static Python library from one system to another - not, say, if you move an application linked with the static library. Why would you want to move the static libpython from one system to another? ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-18 09:41 Message: Logged In: YES user_id=1216071 No, the problem does NOT exist with the dynamic library since it will reference versioned glibc-functions (i.e the dynamic python library will use the backward compatible functions that is present in glibc). This is why compiling and linking static library and application on the same system is not a problem; the resulting binary will run on both linuxthreads and NPTL systems, since they will use the versioned glibc functions. However, a static library does not reference versioned functions until it is linked with either a shared library or an application. Thus, if you compile the static library on a linuxthreads systems but link an application against it on a NPTL systems, things will break, since the static library expects an older version of glibc but gets linked against a new version. But yes, this is not a python bug. It jsut took some time for me fully understand the linking process regarding the versioned glibc functions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-18 09:32 Message: Logged In: YES user_id=21627 I see. The patch is not acceptable - what if the next version of the Linux C library needs again more bytes in the structure? The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. So in fact, an installation with NPTL should be considered as a different operating system, and you cannot expect to move binaries from one operating system to another. Instead, you have to recompile the binaries. Notice that the problem is *not* restricted to the static library. If the application is linked to the shared libpython, and if you not only move the application from one system to another, but also the shared library (e.g. because the target system does not have a libpython), the same problem occurs. So this is really a bug in Linux, which fails to provide binary compatibility across installations. Closing as third-party bug. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-18 08:13 Message: Logged In: YES user_id=1216071 libpythonVERSION.a which is installed in lib/pythonVERSION/config/ But like I said, this bug is only triggered if the lib and the application linking against the lib is compiled on systems with different glibc-versions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. ---------------------------------------------------------------------- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 From noreply at sourceforge.net Fri Feb 18 12:13:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 12:13:38 2005 Subject: [ python-Bugs-856047 ] urllib.py does not use "no_proxy" Message-ID: Bugs item #856047, was opened at 2003-12-08 05:15 Message generated for change (Comment added) made by ensc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Baarda (abo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py does not use "no_proxy" Initial Comment: urllib.py uses "*_proxy" variables to identify proxies to use in the "getproxies()" function. However, it does not use the corresponding "no_proxy" variable in the "proxy_bypass()" method. This affects any platform that can use "*_proxy" environment variables to specify proxies. This includes win32, which will use environment variables before the registry if they are defined. On win32 this causes the confusing behaviour of using the registry for "proxy_bypass()" checking when "*_proxy" environment variables are used to identify the proxies. Attached is a patch against python-2.3.2 that adds support for "no_proxy". Note that win32 will correctly favor using "no_proxy" over using the registry if any "*_proxy" variables are defined. ---------------------------------------------------------------------- Comment By: Enrico Scholz (ensc) Date: 2005-02-18 12:13 Message: Logged In: YES user_id=10773 What is the state of this bug? Is something wrong with the patch that it was not applied yet? It is something annoying to unset $http_proxy manually for some programs. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2003-12-08 05:27 Message: Logged In: YES user_id=10273 Whups... failed to attach patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 From noreply at sourceforge.net Fri Feb 18 16:31:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 16:31:22 2005 Subject: [ python-Bugs-1143855 ] Python syntax is not so XML friendly! Message-ID: Bugs item #1143855, was opened at 2005-02-18 15:31 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=1143855&group_id=5470 Category: Parser/Compiler Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Colbert Philippe (cp1965) Assigned to: Nobody/Anonymous (nobody) Summary: Python syntax is not so XML friendly! Initial Comment: I want to embed python scripts into XML files. The problems is depending on the XML readers's configuration, the space or tab characters might or might not be eliminated. This is a a serious risk. That is why I propose that Python/Jython allow for traditional Java style separators block ({ }). This would be optional and would improve the flexibility of Python. The programmer can always choose which style he/she wants to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143855&group_id=5470 From noreply at sourceforge.net Fri Feb 18 16:52:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 16:52:09 2005 Subject: [ python-Bugs-1143855 ] Python syntax is not so XML friendly! Message-ID: Bugs item #1143855, was opened at 2005-02-18 16:31 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143855&group_id=5470 Category: Parser/Compiler Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Colbert Philippe (cp1965) Assigned to: Nobody/Anonymous (nobody) Summary: Python syntax is not so XML friendly! Initial Comment: I want to embed python scripts into XML files. The problems is depending on the XML readers's configuration, the space or tab characters might or might not be eliminated. This is a a serious risk. That is why I propose that Python/Jython allow for traditional Java style separators block ({ }). This would be optional and would improve the flexibility of Python. The programmer can always choose which style he/she wants to use. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2005-02-18 16:52 Message: Logged In: YES user_id=43607 I'm not in charge of the language, but I give you very little chance that this is accepted. The XML standard has this to say about white space: "An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content. A special attribute named xml:space MAY be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, MUST be declared if it is used. When declared, it MUST be given as an enumerated type whose values are one or both of "default" and "preserve"." If your XML processor doesn't pass on white space in the presence of xml:space="preserve" it is in error and you should complain to there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143855&group_id=5470 From noreply at sourceforge.net Fri Feb 18 17:26:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 17:26:04 2005 Subject: [ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4 Message-ID: Bugs item #1143895, was opened at 2005-02-18 16:26 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=1143895&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: inspect.getsource() breakage in 2.4 Initial Comment: In a real-life case, inspect.getsource() used to produce the correct result on 2.3 but no longer does on 2.4: def somefunc(x, y): # comments ...body... With 2.4 (and 2.5 CVS) the body is completely skipped because the first line doesn't end with a colon. In my opinion that's a critical problem for any code relying on getsource(), even though such code can be considered as relying on a large pile of fragile hacks in the first place... Attached is a patch for test_inspect.py, showing the problem (also includes a different, much more convoluted bug example). It seems that looking for and around ':' in the first line isn't such a good idea; relying more fully on the tokenizer would probably be a better solution. Assigned to jlgijsbers, as the author of the changes that broke this (Dec 12th, 2004). (No blame intended, the change was meant to fix a different bug, and it did so.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 From noreply at sourceforge.net Fri Feb 18 20:11:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 20:11:43 2005 Subject: [ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4 Message-ID: Bugs item #1143895, was opened at 2005-02-18 17:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: inspect.getsource() breakage in 2.4 Initial Comment: In a real-life case, inspect.getsource() used to produce the correct result on 2.3 but no longer does on 2.4: def somefunc(x, y): # comments ...body... With 2.4 (and 2.5 CVS) the body is completely skipped because the first line doesn't end with a colon. In my opinion that's a critical problem for any code relying on getsource(), even though such code can be considered as relying on a large pile of fragile hacks in the first place... Attached is a patch for test_inspect.py, showing the problem (also includes a different, much more convoluted bug example). It seems that looking for and around ':' in the first line isn't such a good idea; relying more fully on the tokenizer would probably be a better solution. Assigned to jlgijsbers, as the author of the changes that broke this (Dec 12th, 2004). (No blame intended, the change was meant to fix a different bug, and it did so.) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-18 20:11 Message: Logged In: YES user_id=469548 Right now I don't have time to look into this bug deeply, but I will do so this week. I'll note that the convoluted example doesn't seem to be working under 2.3, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 From noreply at sourceforge.net Fri Feb 18 21:53:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 21:53:38 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 21:53 Message: Logged In: YES user_id=142612 Thanks for the info. I'm waiting for a stable version of VPython. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-17 02:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-12 04:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Fri Feb 18 22:10:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 22:10:26 2005 Subject: [ python-Bugs-1144057 ] future warning in commets Message-ID: Bugs item #1144057, was opened at 2005-02-18 22: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=1144057&group_id=5470 Category: Parser/Compiler Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144057&group_id=5470 From noreply at sourceforge.net Fri Feb 18 22:17:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 22:17:31 2005 Subject: [ python-Feature Requests-1143855 ] Python syntax is not so XML friendly! Message-ID: Feature Requests item #1143855, was opened at 2005-02-18 07:31 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1143855&group_id=5470 >Category: Parser/Compiler >Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Colbert Philippe (cp1965) Assigned to: Nobody/Anonymous (nobody) Summary: Python syntax is not so XML friendly! Initial Comment: I want to embed python scripts into XML files. The problems is depending on the XML readers's configuration, the space or tab characters might or might not be eliminated. This is a a serious risk. That is why I propose that Python/Jython allow for traditional Java style separators block ({ }). This would be optional and would improve the flexibility of Python. The programmer can always choose which style he/she wants to use. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-18 13:17 Message: Logged In: YES user_id=357491 First off, this is not a bug and thus should be filed as a feature request. Second, it will never happen. A key benefit of Python is that it's syntax does not allow for much flexibility in terms of how to structure your code syntactically. This makes it quite easy to read someone else's code regardless of what syntax style they use. You also have problems with possible ambiguity with dicts. In other words this is never going to happen simply because it goes against a basic Python tenant. Closed as invalid. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2005-02-18 07:52 Message: Logged In: YES user_id=43607 I'm not in charge of the language, but I give you very little chance that this is accepted. The XML standard has this to say about white space: "An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content. A special attribute named xml:space MAY be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, MUST be declared if it is used. When declared, it MUST be given as an enumerated type whose values are one or both of "default" and "preserve"." If your XML processor doesn't pass on white space in the presence of xml:space="preserve" it is in error and you should complain to there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1143855&group_id=5470 From noreply at sourceforge.net Fri Feb 18 22:21:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 22:21:31 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-11 18:59 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-02-18 13:21 Message: Logged In: YES user_id=357491 Since this seems to be a VPython issue closing as invalid. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 12:53 Message: Logged In: YES user_id=142612 Thanks for the info. I'm waiting for a stable version of VPython. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-16 17:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-11 19:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 19:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 19:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Fri Feb 18 22:21:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 18 22:21:53 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 22:21 Message: Logged In: YES user_id=142612 In response to tim_one's message (2005-02-12 04:46): I also like python and use it for several hours a day. Python 2.3.4 and 2.3.5 are very stable and I couldn't crash them (without buggy extension modules). I claim only that 2.4.0 is unstable at least in some use cases. Please see bug #1120452, for example: http://sourceforge.net/tracker/?func=detail&aid=1121201&group_id=5470&atid=105470 The attached app uses only pure python and standard library for simple HTML templating. Note, that PyMeld does not use a C extension. It can crash Python 2.4.0 with a segfault under Windows XP and Debian Linux 3.0r2 (kernel 2.4.28). The bug has been reproduces by another sourceforge users. Thanks for your comment. Greetings, Complex ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-18 22:21 Message: Logged In: YES user_id=357491 Since this seems to be a VPython issue closing as invalid. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 21:53 Message: Logged In: YES user_id=142612 Thanks for the info. I'm waiting for a stable version of VPython. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-17 02:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-12 04:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Sat Feb 19 06:21:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 06:21:40 2005 Subject: [ python-Bugs-856047 ] urllib.py does not use "no_proxy"; Message-ID: Bugs item #856047, was opened at 2003-12-08 15:15 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Baarda (abo) Assigned to: Nobody/Anonymous (nobody) >Summary: urllib.py does not use "no_proxy"; Initial Comment: urllib.py uses "*_proxy" variables to identify proxies to use in the "getproxies()" function. However, it does not use the corresponding "no_proxy" variable in the "proxy_bypass()" method. This affects any platform that can use "*_proxy" environment variables to specify proxies. This includes win32, which will use environment variables before the registry if they are defined. On win32 this causes the confusing behaviour of using the registry for "proxy_bypass()" checking when "*_proxy" environment variables are used to identify the proxies. Attached is a patch against python-2.3.2 that adds support for "no_proxy". Note that win32 will correctly favor using "no_proxy" over using the registry if any "*_proxy" variables are defined. ---------------------------------------------------------------------- >Comment By: Donovan Baarda (abo) Date: 2005-02-19 16:21 Message: Logged In: YES user_id=10273 This bug is still present in current versions of Python. The biggest problem with this patch is it only addresses urllib, when urllib2 has the same problem. I have been meaning to put together a new patch that fixes both urllib and urllib2, but haven't had time or external motivation yet. ---------------------------------------------------------------------- Comment By: Enrico Scholz (ensc) Date: 2005-02-18 22:13 Message: Logged In: YES user_id=10773 What is the state of this bug? Is something wrong with the patch that it was not applied yet? It is something annoying to unset $http_proxy manually for some programs. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2003-12-08 15:27 Message: Logged In: YES user_id=10273 Whups... failed to attach patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 From noreply at sourceforge.net Sat Feb 19 10:20:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 10:20:17 2005 Subject: [ python-Bugs-1144263 ] reload() is broken for C extension objects Message-ID: Bugs item #1144263, was opened at 2005-02-19 04: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=1144263&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew G. Knepley (knepley) Assigned to: Nobody/Anonymous (nobody) Summary: reload() is broken for C extension objects Initial Comment: 1) A C extension module (foo.so) is imported import foo 2) The library foo.so is rebuilt with changes 3) We reload the module foo = reload(foo) The reload() method calls imp.load_dynamic() which eventually gets down to _PyImport_GetDynLoadFunc(). This just calls dlopen(), which returns the old filehandle. This problem can be fixed by augmenting imp with unload_dynamic(), which could easily be implemented in a _PyImport_GetDynUnloadFunc(), which would just consult its handles[] array, and call dlclose() on the appropriate handle. This will work if Python was the only program to dlopen() foo.so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 From noreply at sourceforge.net Sat Feb 19 22:02:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 22:02:11 2005 Subject: [ python-Bugs-1144533 ] htmllib quote parse error within a tags. I am using "Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin" on a PowerBook G4 running OSX 10.3.8.

This is a test


Here is the Python trace: Traceback (most recent call last): File "cleanFeed.py", line 26, in ? clean = stripHtml.strip( feed ) File "/Users/allan/Desktop/Mood for Today/stripHtml.py", line 144, in strip parser.feed(s) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/HTMLParser.py", line 108, in feed self.goahead(0) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/HTMLParser.py", line 150, in goahead k = self.parse_endtag(i) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/HTMLParser.py", line 327, in parse_endtag self.error("bad end tag: %s" % `rawdata[i:j]`) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/HTMLParser.py", line 115, in error raise HTMLParseError(message, self.getpos()) HTMLParser.HTMLParseError: bad end tag: "", at line 1, column 309 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144533&group_id=5470 From noreply at sourceforge.net Sat Feb 19 22:27:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 22:27:18 2005 Subject: [ python-Bugs-1144263 ] reload() is broken for C extension objects Message-ID: Bugs item #1144263, was opened at 2005-02-19 09:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew G. Knepley (knepley) Assigned to: Nobody/Anonymous (nobody) Summary: reload() is broken for C extension objects Initial Comment: 1) A C extension module (foo.so) is imported import foo 2) The library foo.so is rebuilt with changes 3) We reload the module foo = reload(foo) The reload() method calls imp.load_dynamic() which eventually gets down to _PyImport_GetDynLoadFunc(). This just calls dlopen(), which returns the old filehandle. This problem can be fixed by augmenting imp with unload_dynamic(), which could easily be implemented in a _PyImport_GetDynUnloadFunc(), which would just consult its handles[] array, and call dlclose() on the appropriate handle. This will work if Python was the only program to dlopen() foo.so. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-19 21:27 Message: Logged In: YES user_id=6656 I don't believe this is quite as easy as you make out. It might be possible to make something that works for platforms that use dlopen though... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 From noreply at sourceforge.net Sat Feb 19 22:37:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 19 22:37:33 2005 Subject: [ python-Bugs-1144263 ] reload() is broken for C extension objects Message-ID: Bugs item #1144263, was opened at 2005-02-19 04:20 Message generated for change (Comment added) made by knepley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew G. Knepley (knepley) Assigned to: Nobody/Anonymous (nobody) Summary: reload() is broken for C extension objects Initial Comment: 1) A C extension module (foo.so) is imported import foo 2) The library foo.so is rebuilt with changes 3) We reload the module foo = reload(foo) The reload() method calls imp.load_dynamic() which eventually gets down to _PyImport_GetDynLoadFunc(). This just calls dlopen(), which returns the old filehandle. This problem can be fixed by augmenting imp with unload_dynamic(), which could easily be implemented in a _PyImport_GetDynUnloadFunc(), which would just consult its handles[] array, and call dlclose() on the appropriate handle. This will work if Python was the only program to dlopen() foo.so. ---------------------------------------------------------------------- >Comment By: Matthew G. Knepley (knepley) Date: 2005-02-19 16:37 Message: Logged In: YES user_id=58554 I am only interested in fixing it for the dlopen() case, which I thnk subsumes every architecture likely to have this problem appear. I have no problem fixing it myself, but I need to get all the CVS stuff setup. And I am not sure how to easily generate the patch to send (I'm used to BK). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-19 16:27 Message: Logged In: YES user_id=6656 I don't believe this is quite as easy as you make out. It might be possible to make something that works for platforms that use dlopen though... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 From noreply at sourceforge.net Sun Feb 20 02:56:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 02:56:42 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-10 19:04 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-19 20:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 09:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Sun Feb 20 02:59:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 02:59:45 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 12:28 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Egon Frerich (friedrich) >Assigned to: Kurt B. Kaiser (kbk) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-19 20:59 Message: Logged In: YES user_id=149084 Helpful in what way? What are you trying to accomplish? There is a line number indicator on the lower right of each IDLE edit window. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-17 06:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Sun Feb 20 05:34:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 05:34:28 2005 Subject: [ python-Bugs-1144263 ] reload() is broken for C extension objects Message-ID: Bugs item #1144263, was opened at 2005-02-19 04:20 Message generated for change (Comment added) made by knepley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew G. Knepley (knepley) Assigned to: Nobody/Anonymous (nobody) Summary: reload() is broken for C extension objects Initial Comment: 1) A C extension module (foo.so) is imported import foo 2) The library foo.so is rebuilt with changes 3) We reload the module foo = reload(foo) The reload() method calls imp.load_dynamic() which eventually gets down to _PyImport_GetDynLoadFunc(). This just calls dlopen(), which returns the old filehandle. This problem can be fixed by augmenting imp with unload_dynamic(), which could easily be implemented in a _PyImport_GetDynUnloadFunc(), which would just consult its handles[] array, and call dlclose() on the appropriate handle. This will work if Python was the only program to dlopen() foo.so. ---------------------------------------------------------------------- >Comment By: Matthew G. Knepley (knepley) Date: 2005-02-19 23:34 Message: Logged In: YES user_id=58554 I have coded the proposed solution (changed import.c, importdl.c, and dynload_shlib.c). I will assemble a test case for it next week. ---------------------------------------------------------------------- Comment By: Matthew G. Knepley (knepley) Date: 2005-02-19 16:37 Message: Logged In: YES user_id=58554 I am only interested in fixing it for the dlopen() case, which I thnk subsumes every architecture likely to have this problem appear. I have no problem fixing it myself, but I need to get all the CVS stuff setup. And I am not sure how to easily generate the patch to send (I'm used to BK). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-19 16:27 Message: Logged In: YES user_id=6656 I don't believe this is quite as easy as you make out. It might be possible to make something that works for platforms that use dlopen though... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1144263&group_id=5470 From noreply at sourceforge.net Sun Feb 20 11:12:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 11:12:36 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 17:28 Message generated for change (Comment added) made by friedrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 4 Submitted By: Egon Frerich (friedrich) Assigned to: Kurt B. Kaiser (kbk) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Egon Frerich (friedrich) Date: 2005-02-20 10:12 Message: Logged In: YES user_id=37594 Yes, and you know where the cursor is. And there is the Edit-menu item to go to a line number. Helpful means: sometimes you get a python error with the line number. In a GUI you often work with the mouse and you don't want to enter with the keyboard. So you scroll the edit window with the mouse. If there were the line number at the left border you find the line number very quickly and only with the mouse. How I said: helpfull. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 01:59 Message: Logged In: YES user_id=149084 Helpful in what way? What are you trying to accomplish? There is a line number indicator on the lower right of each IDLE edit window. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-17 11:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Sun Feb 20 11:47:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 11:47:29 2005 Subject: [ python-Feature Requests-1144057 ] future warning in commets Message-ID: Feature Requests item #1144057, was opened at 2005-02-18 16:10 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 >Category: Parser/Compiler >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 From noreply at sourceforge.net Sun Feb 20 11:47:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 11:48:00 2005 Subject: [ python-Bugs-1124692 ] Math mode not well handled in \documentclass{howto} Message-ID: Bugs item #1124692, was opened at 2005-02-17 08:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Math mode not well handled in \documentclass{howto} Initial Comment: LaTeX loses its Math Magic (tm) when using \documentclass{howto}: underscore operator in math enviroment doesn't produce subscripts. This documents shows some oddities: \documentclass{howto} \begin{document} Water is $H_2O$, and subscript is missing from... \[ V_{0,r} \] Superscripts are instead fine, as $e^{\pi i} + 1 = 0$ shows. Also this is completely different from what obtained by \textbackslash documentclass\{article\}. \[ \sum_{k=0}^\infty \int_0^k f(x) dx \] \end{document} The bug is removed by commenting out lines 541--549 in python.sty, but i don't know how to *fix* them... (not a TeXpert) Using Python 2.3.5, Windows 2000, LaTeX2e (e-TeX 3.141592-2.2, MikTex 2.4 implementation) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470 From noreply at sourceforge.net Sun Feb 20 11:52:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 11:52:19 2005 Subject: [ python-Feature Requests-1123660 ] add SHA256/384/512 to lib Message-ID: Feature Requests item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1123660&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-20 05:52 Message: Logged In: YES user_id=80475 "Break" is a bit of an over-statement. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 12:45 Message: Logged In: YES user_id=593130 Ok, next time.... You might want to look at https://sourceforge.net/tracker/index.php? func=detail&aid=1121611&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-17 11:55 Message: Logged In: YES user_id=72053 Well, I don't see an obvious way to reclassify this item. If someone knows how to do it, please go ahead. I sent an email to the lawyer and haven't gotten a response yet. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 11:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 22:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 21:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or beginning of email subject line or body text. Hence my comment. My FYI legal issue summary was based on a PyDev thread within the last week and the Contribution pages at python.org. I have no opinion on the lawyer dispute over PD. PSF's lawyer wrote his opinion in a LinuxJournal piece referenced in that thread. PSF Board is inclined to follow advice paid for. Yes, Sha module should be maintained by one person. Hope one of crypto people sees and responds to this item. There is also a current PyDev thread about sha?, md5, ssl, and licensing, but I barely paid attention. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:43 Message: Logged In: YES user_id=72053 Addendum: Note that this RFE is an enhancement request for the sha module. Therefore I think the best way to triage it is to assign it to the current sha module maintainer and let him decide what if anything to do about it. If he accepts a patch (or does one himself), it's logical for him to also take ownership of the patch at that point. Sha is a relatively uncomplicated module and it doesn't make much sense for it to have multiple maintainers. I don't think any harm will be done if this stays open for a while until someone gets around to doing a patch. But sooner or later there will be a need for it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:31 Message: Logged In: YES user_id=72053 Oops, correction to previous, US court ruling was from 9th circuit, not Supreme Court. However it doesn't appear to be a matter of controversy. Prof. Lessig's pages about Creative Commons also say that releasing stuff into the PD is valid and I think Prof. Moglen has said something similar. The PSF lawyer might want to talk to Lessig or Moglen if there's some uncertainty. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2005-02-16 20:27 Message: Logged In: YES user_id=72053 1. I submitted it as a feature request and thought that was the same thing as an RFE. If it needs to be reclassified in some way, let me know how to do that. 2. The library I mentioned was explicitly released into the public domain by the author. I'd be interested to know what the PSF's lawyer's objection is to using public domain code. The OSF license list doesn't include public domain but I think that's just an oversight. The FSF's license list says public domain code is fine as free software. http://cr.yp.to/publicdomain.html cites a US Supreme Court ruling that releasing stuff into the PD is perfectly legally valid (at least in the US). Is the lawyer complaining that there's some obstacle in other countries? If you have a written opinion from him/her I'd appreciate seeing it. I've heard this claim before but it has always sounded bogus to me. 3. I'm not at the moment versed enough in the Python C API to be able to do this patch quickly, and I have other things going on so I can't spend time on it right now. I'm also not willing to be the long-term maintainer even if I do the patch. I submitted the report mostly to give the lib. maintainers a heads-up to the new development. SHA256/384/512 (collectively known as SHA2) has been on the horizon for a long time as an SHA1 successor, but the recent results against SHA1 are going to make SHA2 into a higher priority addition than before. Other people are going to be asking for it and its absence will become a somewhat serious deficiency in the stdlib. So, someone interested in this kind of thing might want to look into it. 4. The SHA2 patches should be pretty simple. SHA2 is just like SHA1 in terms of API and basic functionality. The actual algorithms are different and the lengths of the returned hash are different but that should be a straightforward matter of adding wrappers for the new functions. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:55 Message: Logged In: YES user_id=593130 This is, of course, an RFE -- request for enhancement -- and not at all a bug report. Will SF let you reclassify it? I suspect your request is reasonable, but if you leave it here, it may get closed as Invalid -- not a bug. If you really want this to happen, I suspect you know the drill: submit a patch and help review others. What you may not know it that 'public domain' is mostly not acceptible for contributions. The PSF's paid lawyer considers it bogus for modern creations other than government work. What the PSF does want is stuff licensed under specific open source licenses and specifically contributed to Python by the author. There also needs to be a code maintainer. Getting all this takes more work that just visiting a site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1123660&group_id=5470 From noreply at sourceforge.net Sun Feb 20 11:53:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 11:53:52 2005 Subject: [ python-Feature Requests-1124503 ] IDLE line wrapping Message-ID: Feature Requests item #1124503, was opened at 2005-02-16 23:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1124503&group_id=5470 >Category: IDLE >Group: None Status: Open Resolution: None Priority: 4 Submitted By: Chris Rebert (rebertc) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE line wrapping Initial Comment: As IDLE is the 'official' python editor and PEP 8 (Style Guide PEP) suggests that coders wrap lines at 79 characters, I propose that IDLE should assist this practice by highlighting lines or parts of lines longer than 79 chacacters, or something similar. It is suggested that this be a pref toggleable in the "Configure IDLE" window and be turned on by default to encourage good coding practices. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-20 05:53 Message: Logged In: YES user_id=80475 I would find this to be an annoyance. Passing to Kurt for pronouncement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1124503&group_id=5470 From noreply at sourceforge.net Sun Feb 20 11:56:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 11:56:08 2005 Subject: [ python-Bugs-1121416 ] zip incorrectly and incompletely documented Message-ID: Bugs item #1121416, was opened at 2005-02-12 12:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:10 Message: Logged In: YES user_id=80475 The first sentence becomes even less clear with the "in the same order" wording. The note about truncating to the shortest sequence length is essential and should not have been dropped. The py2.4 change note is in a standard form (\versionchanged{} following the explanation of current behavior) and should not have been altered. The part that addresses the OP's concern is too specific to the his one example and is unclear unless you know about that example. The wording is discomforting, doesn't add new information, and is somewhat not obvious in its meaning. I suggest simply changing "sequence" to "iterable". There is no sense in stating that the order of combination is undefined. It doesn't help with the OP's original desire to be able to predict the outcome of the example. However, it does have the negative effect of making a person question whether they've understood the preceding description of what actually zip() does do. zip() is about lockstep iteration and the docs should serve those users as straight-forwardly as possible. The OP's issue on the other hand only comes up when trying funky iterator magic -- adding a sentence about undefined ordering doesn't help one bit. There is a lesson in all this. These tools were borrowed from the world of functional programming which is all about programming that is free of side-effects. The OP's problem should be left as a code smell indicating a misuse of functionals. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 19:03 Message: Logged In: YES user_id=593130 I agree that the zip doc needs improvement. Confusion will continue until it is. Here is my suggested rewrite: ------------------------------------------------------------------- zip([iterable1, ...]) Return a list of tuples, where the i-th tuple contains the i-th element from each input in the same order as the inputs. With no arguments, return an empty list (before 2.4, a TypeError was raised instead.) With a single input, return a list of 1-tuples. With multiple inputs, the output length is that of the shorted input. When multiple input lengths are equal, zip(i1, ...) is similar to map(None, i1, ...), but there is no padding when otherwise. The result of zipping a volatile iterable with itself is undefined. New in 2.0. ------------------------------------------------------------------- There you have it. More information is about 15% fewer words. The reduction came from greatly condensing the overwordy sentence about obsolete behavior into a parenthetical comment. For comparison, here is the current version. ------------------------------------------------------------------- zip( [seq1, ...]) This function returns a list of tuples, where the i-th tuple contains the i-th element from each of the argument sequences. The returned list is truncated in length to the length of the shortest argument sequence. When there are multiple argument sequences which are all of the same length, zip() is similar to map() with an initial argument of None. With a single sequence argument, it returns a list of 1- tuples. With no arguments, it returns an empty list. New in version 2.0. Changed in version 2.4: Formerly, zip() required at least one argument and zip() raised a TypeError instead of returning an empty list.. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 21:25 Message: Logged In: YES user_id=1038590 The generator in the previous comment was incorrect (tuple swallows the StopIteration, so it never terminates). Try this instead: def partition(iterable, part_len): itr = iter(iterable) while 1: item = tuple(islice(itr, part_len)) if len(item) < part_len: raise StopIteration yield item ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-12 20:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 From noreply at sourceforge.net Sun Feb 20 16:54:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 16:54:24 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 12:28 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 4 Submitted By: Egon Frerich (friedrich) Assigned to: Kurt B. Kaiser (kbk) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 10:54 Message: Logged In: YES user_id=149084 If you right click on the line number in the traceback you will have the option of viewing the associated source code. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-20 05:12 Message: Logged In: YES user_id=37594 Yes, and you know where the cursor is. And there is the Edit-menu item to go to a line number. Helpful means: sometimes you get a python error with the line number. In a GUI you often work with the mouse and you don't want to enter with the keyboard. So you scroll the edit window with the mouse. If there were the line number at the left border you find the line number very quickly and only with the mouse. How I said: helpfull. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-19 20:59 Message: Logged In: YES user_id=149084 Helpful in what way? What are you trying to accomplish? There is a line number indicator on the lower right of each IDLE edit window. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-17 06:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Sun Feb 20 17:00:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 17:00:06 2005 Subject: [ python-Feature Requests-1124503 ] IDLE line wrapping Message-ID: Feature Requests item #1124503, was opened at 2005-02-16 23:56 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1124503&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 4 Submitted By: Chris Rebert (rebertc) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE line wrapping Initial Comment: As IDLE is the 'official' python editor and PEP 8 (Style Guide PEP) suggests that coders wrap lines at 79 characters, I propose that IDLE should assist this practice by highlighting lines or parts of lines longer than 79 chacacters, or something similar. It is suggested that this be a pref toggleable in the "Configure IDLE" window and be turned on by default to encourage good coding practices. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 11:00 Message: Logged In: YES user_id=149084 I'd agree with Raymond. Three things have been done to help with this: first, the default window width is set at 80 char. Second, there is a column number indicator in the lower right, it's easy to keep an eye on it when you're typing a long line. Finally, there is a paragraph formatting feature which will re-wrap comments and doc strings to a configurable width. Now if Sourceforge could just do something clever to fix the farging line wrap in these comment windows.... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-20 05:53 Message: Logged In: YES user_id=80475 I would find this to be an annoyance. Passing to Kurt for pronouncement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1124503&group_id=5470 From noreply at sourceforge.net Sun Feb 20 21:01:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 21:01:30 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 17:28 Message generated for change (Comment added) made by friedrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 4 Submitted By: Egon Frerich (friedrich) Assigned to: Kurt B. Kaiser (kbk) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- >Comment By: Egon Frerich (friedrich) Date: 2005-02-20 20:01 Message: Logged In: YES user_id=37594 Thank you ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 15:54 Message: Logged In: YES user_id=149084 If you right click on the line number in the traceback you will have the option of viewing the associated source code. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-20 10:12 Message: Logged In: YES user_id=37594 Yes, and you know where the cursor is. And there is the Edit-menu item to go to a line number. Helpful means: sometimes you get a python error with the line number. In a GUI you often work with the mouse and you don't want to enter with the keyboard. So you scroll the edit window with the mouse. If there were the line number at the left border you find the line number very quickly and only with the mouse. How I said: helpfull. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 01:59 Message: Logged In: YES user_id=149084 Helpful in what way? What are you trying to accomplish? There is a line number indicator on the lower right of each IDLE edit window. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-17 11:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Sun Feb 20 23:45:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 20 23:45:24 2005 Subject: [ python-Feature Requests-1122532 ] Line Numbers Message-ID: Feature Requests item #1122532, was opened at 2005-02-14 12:28 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 4 Submitted By: Egon Frerich (friedrich) Assigned to: Kurt B. Kaiser (kbk) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-20 15:01 Message: Logged In: YES user_id=37594 Thank you ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 10:54 Message: Logged In: YES user_id=149084 If you right click on the line number in the traceback you will have the option of viewing the associated source code. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-20 05:12 Message: Logged In: YES user_id=37594 Yes, and you know where the cursor is. And there is the Edit-menu item to go to a line number. Helpful means: sometimes you get a python error with the line number. In a GUI you often work with the mouse and you don't want to enter with the keyboard. So you scroll the edit window with the mouse. If there were the line number at the left border you find the line number very quickly and only with the mouse. How I said: helpfull. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-19 20:59 Message: Logged In: YES user_id=149084 Helpful in what way? What are you trying to accomplish? There is a line number indicator on the lower right of each IDLE edit window. ---------------------------------------------------------------------- Comment By: Egon Frerich (friedrich) Date: 2005-02-17 06:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-16 20:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 From noreply at sourceforge.net Mon Feb 21 09:10:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 09:10:47 2005 Subject: [ python-Bugs-1145231 ] No os.statvfs on FreeBSD Message-ID: Bugs item #1145231, was opened at 2005-02-21 09: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=1145231&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Volker Stolz (volkersf) Assigned to: Nobody/Anonymous (nobody) Summary: No os.statvfs on FreeBSD Initial Comment: There's no statvfs-wrapper on FreeBSD because it doesn't have statvfs(). But there's statfs() which might be sufficient: http://www.freebsd.org/cgi/man.cgi? query=statfs&apropos=0&sektion=0&manpath=FreeBSD+5.3- RELEASE+and+Ports&format=html Python 2.4 (#2, Jan 4 2005, 04:22:40) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> dir (os) ...'spawnvpe', 'stat', 'stat_float_times', 'stat_result', 'statvfs_result', 'strerror',... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145231&group_id=5470 From noreply at sourceforge.net Mon Feb 21 10:02:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 10:02:58 2005 Subject: [ python-Bugs-1145257 ] shutil.copystat() may fail... Message-ID: Bugs item #1145257, was opened at 2005-02-21 10:02 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=1145257&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copystat() may fail... Initial Comment: Hi, The shutil.copystat() may fail in case when the destination file has read-only attribute. It's because the implementation calls the os.utime() first and os.chmod() later. In Windows (I am not sure if also in Unix-based system), the os.utime() fails for read-only files. The implementation should ensure the read/write access by " try: os.chmod(dst, 0600)..." before calling the os.utime(). The file mode will be copied from the source file in the next step anyway. The simplistic test attached (Unix line ending used inside the tst.py zipped inside). Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145257&group_id=5470 From noreply at sourceforge.net Mon Feb 21 10:17:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 10:17:48 2005 Subject: [ python-Feature Requests-1144057 ] future warning in commets Message-ID: Feature Requests item #1144057, was opened at 2005-02-18 22:10 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-02-21 10:17 Message: Logged In: YES user_id=89016 I don't think we should change this. The encoding is something that affects the whole file not just the executable part of it. When a file that claims to be ASCII contains bytes > 0x7f there's something fishy going on, no matter where these bytes are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 From noreply at sourceforge.net Mon Feb 21 10:48:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 21 10:48:35 2005 Subject: [ python-Bugs-1145231 ] No os.statvfs on FreeBSD Message-ID: Bugs item #1145231, was opened at 2005-02-21 17:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145231&group_id=5470 Category: Python Library >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Volker Stolz (volkersf) >Assigned to: Hye-Shik Chang (perky) Summary: No os.statvfs on FreeBSD Initial Comment: There's no statvfs-wrapper on FreeBSD because it doesn't have statvfs(). But there's statfs() which might be sufficient: http://www.freebsd.org/cgi/man.cgi? query=statfs&apropos=0&sektion=0&manpath=FreeBSD+5.3- RELEASE+and+Ports&format=html Python 2.4 (#2, Jan 4 2005, 04:22:40) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> dir (os) ...'spawnvpe', 'stat', 'stat_float_times', 'stat_result', 'statvfs_result', 'strerror',... ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-02-21 18:48 Message: Logged In: YES user_id=55188 FreeBSD has statvfs(3) since FreeBSD 5.0. Looking at FreeBSD's statvfs implementation (which is a wrapper function for statfs system call), statfs has little bit different structure than statvfs and it may need some translation routine. FreeBSD 4 is on the way to being a legacy platform, and you can still use py-freebsd to utilize statfs(2) on FreeBSD 4 and older. So I'm sorry but I don't feel that adding some ifdef blocks is worthy enough. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145231&group_id=5470 From noreply at sourceforge.net Tue Feb 22 03:47:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 03:48:00 2005 Subject: [ python-Bugs-1145950 ] Strange behaviour concerning variable names Message-ID: Bugs item #1145950, was opened at 2005-02-22 03:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145950&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Nawothnig (flexo_) Assigned to: Nobody/Anonymous (nobody) Summary: Strange behaviour concerning variable names Initial Comment: For some reason python coders seem to be unaware of the fact that Python allows variable names to be longer than one char - let's have a look at a function from BitTorrent for example: def decode_list(x, f): r, f = [], f+1 while x[f] != 'e': v, f = decode_func[x[f]](x, f) r.append(v) return (r, f + 1) I'm not sure about the reasons for this behaviour yet but I suspect serious brain-damage caused by indentation-based structuring. A possible workaround: switching to a sane language like Ruby. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145950&group_id=5470 From noreply at sourceforge.net Tue Feb 22 11:16:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 11:16:12 2005 Subject: [ python-Bugs-1145950 ] Strange behaviour concerning variable names Message-ID: Bugs item #1145950, was opened at 2005-02-22 02:47 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145950&group_id=5470 Category: Parser/Compiler >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Felix Nawothnig (flexo_) Assigned to: Nobody/Anonymous (nobody) Summary: Strange behaviour concerning variable names Initial Comment: For some reason python coders seem to be unaware of the fact that Python allows variable names to be longer than one char - let's have a look at a function from BitTorrent for example: def decode_list(x, f): r, f = [], f+1 while x[f] != 'e': v, f = decode_func[x[f]](x, f) r.append(v) return (r, f + 1) I'm not sure about the reasons for this behaviour yet but I suspect serious brain-damage caused by indentation-based structuring. A possible workaround: switching to a sane language like Ruby. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-22 10:16 Message: Logged In: YES user_id=6656 Ho ho ho. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145950&group_id=5470 From noreply at sourceforge.net Tue Feb 22 14:07:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 14:07:36 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-11 01:04 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 >Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 14:07 Message: Logged In: YES user_id=142612 This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 02:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 20:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 20:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 15:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Tue Feb 22 14:10:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 14:10:39 2005 Subject: [ python-Bugs-1146231 ] bsddb3 build problems on FreeBSD (2.4 + 2.5) Message-ID: Bugs item #1146231, was opened at 2005-02-23 00: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=1146231&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb3 build problems on FreeBSD (2.4 + 2.5) Initial Comment: FreeBSD's ports system has another variation on naming the Sleepcat DB library. The attached patch adds support for this naming variation. The patch is actually for CVS head, but applies to the 2.4 maintenance branch (with an offset). In my particular case, my FreeBSD box has both DB 4.1 and DB 4.0 installed; the build was finding the 4.1 headers and compiling against them, but then linking to the 4.0 library. In consequence, all the tests which depend on the _bsddb module (test_anydbm, test_bsddb, test_bsddb185, test_shelve, test_whichdb) were failing or dumping core. This patch (or something with similar effect) should be applied in time for 2.4.1 in my opinion (I could do that, but would like the release manager's approval). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1146231&group_id=5470 From noreply at sourceforge.net Tue Feb 22 15:51:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 15:51:54 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-11 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-02-22 14:51 Message: Logged In: YES user_id=6656 Well, I still can't make it crash. Can one of you provide a crashing driver script? Better still would be finding which regexp and which input is the problem. (Unless it's a memory-scribble random crasher type bug...) ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 13:07 Message: Logged In: YES user_id=142612 This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 01:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 19:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 19:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 14:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Tue Feb 22 16:19:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 16:19:16 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-11 01:04 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 16:19 Message: Logged In: YES user_id=142612 Some additional information and summary: My machine is a 3.0Hz Intel P4 with 1Gbyte memory, without overclocking. I use 2 antivirus (1 active) and 3 antispyware apps + firewall. The memory has been tested for 6 hours with Knoppix's memtest without any error, so my machine can be considered to be stable. The attached script can crash python 2.4.0 at least for me and jumjjewett. Do not run the script from IDLE, since it can hide the segfault. I usually run my scripts from SciTE (see: www.scintilla.org ). The bug can be reproduced on stock Python 2.4.0 (MSI installer). PyMeld is pure python (uses only the standard library), no C extension modules used. I did not test this bug with the latest CVS versions of Python 2.4. Is produces segfault under Linux. I'll try to narrow down this bug for specific regex patterns. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-22 15:51 Message: Logged In: YES user_id=6656 Well, I still can't make it crash. Can one of you provide a crashing driver script? Better still would be finding which regexp and which input is the problem. (Unless it's a memory-scribble random crasher type bug...) ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 14:07 Message: Logged In: YES user_id=142612 This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 02:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 20:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 20:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 15:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Tue Feb 22 20:04:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 20:05:00 2005 Subject: [ python-Bugs-1147646 ] Windows deadlock with PyEval_ReleaseLock Message-ID: Bugs item #1147646, was opened at 2005-02-22 11: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=1147646&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lou Montulli (montulli) Assigned to: Nobody/Anonymous (nobody) Summary: Windows deadlock with PyEval_ReleaseLock Initial Comment: This problem is described well by this post from '03 http://mail.python.org/pipermail/python-dev/2003-August/037729.html The problem still seems to exist. The solution described within the post will not work in all cases because if you do not call PyEval_ReleaseLock then other threads will be deadlocked, and if you do call PyEval_ReleaseLock, the thread that originally called InitThreads will be deadlocked. The only work around that I have found so far is to use a separate thread that will never call scripts call InitThreads and then PyEval_ReleaseLock. After that all threads will run correctly, but the thread that originally called InitThreads cannot run python. Feel free to contact me for any other details, or call me a bonehead if I screwed something up. lou a montulli o org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1147646&group_id=5470 From noreply at sourceforge.net Tue Feb 22 23:14:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 22 23:14:23 2005 Subject: [ python-Bugs-1149413 ] fix bsddb documentation psize -> pgsize Message-ID: Bugs item #1149413, was opened at 2005-02-22 23: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=1149413&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: fix bsddb documentation psize -> pgsize Initial Comment: Where: http://docs.python.org/lib/module-bsddb.html You say there: btopen( filename[, flag[, mode[, btflags[, cachesize[, maxkeypage[, minkeypage[, psize[, lorder]]]]]]]]) the word psize should be replaced with pgsize. An example would help: >>> d = bsddb.btopen(None, "c", cachesize=768000, pgsize=65536) >>> d = bsddb.btopen(None, "n", cachesize=768000, pgsize=65536) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 201, in btopen flags = _checkflag(flag, file) File "/usr/lib/python2.3/bsddb/__init__.py", line 249, in _checkflag if os.path.isfile(file): File "/usr/lib/python2.3/posixpath.py", line 200, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, NoneType found >>> The latter is I believe possibly a bug in the python wrapper not handling 'n' properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&group_id=5470 From noreply at sourceforge.net Wed Feb 23 00:15:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 00:15:33 2005 Subject: [ python-Bugs-1149447 ] bssdb wrapper does not export some low-level functions Message-ID: Bugs item #1149447, was opened at 2005-02-23 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=105470&aid=1149447&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: bssdb wrapper does not export some low-level functions Initial Comment: If you go and read docs/api_c/db_list.html in any newer BerkelyDB source tree, you find some methods not exported in/usr/lib/python2.3/bsddb/__init__.py although at least some do exist in dbobj.py. For example, of my interrest were two mentioned in the patch. I believe someone should go and make sure they are present. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149447&group_id=5470 From noreply at sourceforge.net Wed Feb 23 00:58:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 00:58:25 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-10 19:04 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-22 18:58 Message: Logged In: YES user_id=764593 It probably is a memory scribble bug, though it might not be in re. For instance, the __getattr__ and __setattr__ try to do some shortcuts saving position, and they may cause the out- of-bounds. The crashes are very dependent on order. I wasn't kidding when I said it ran fine and printed None if run as a whole, but crashed when the same lines were input one by one. (Which gave idle a chance to do different things with memory in between, and didn't define a function object.) Also note that the second attribute access (even to a previously OK attribute) could cause a crash, unless it had had a chance to clear things up first -- but then it raised a MemoryError, when I almost certainly wasn't yet out of RAM. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 10:19 Message: Logged In: YES user_id=142612 Some additional information and summary: My machine is a 3.0Hz Intel P4 with 1Gbyte memory, without overclocking. I use 2 antivirus (1 active) and 3 antispyware apps + firewall. The memory has been tested for 6 hours with Knoppix's memtest without any error, so my machine can be considered to be stable. The attached script can crash python 2.4.0 at least for me and jumjjewett. Do not run the script from IDLE, since it can hide the segfault. I usually run my scripts from SciTE (see: www.scintilla.org ). The bug can be reproduced on stock Python 2.4.0 (MSI installer). PyMeld is pure python (uses only the standard library), no C extension modules used. I did not test this bug with the latest CVS versions of Python 2.4. Is produces segfault under Linux. I'll try to narrow down this bug for specific regex patterns. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-22 09:51 Message: Logged In: YES user_id=6656 Well, I still can't make it crash. Can one of you provide a crashing driver script? Better still would be finding which regexp and which input is the problem. (Unless it's a memory-scribble random crasher type bug...) ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 08:07 Message: Logged In: YES user_id=142612 This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-19 20:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 09:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Wed Feb 23 01:01:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 01:01:41 2005 Subject: [ python-Bugs-1149447 ] bssdb wrapper does not export some low-level functions Message-ID: Bugs item #1149447, was opened at 2005-02-23 00:15 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149447&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: bssdb wrapper does not export some low-level functions Initial Comment: If you go and read docs/api_c/db_list.html in any newer BerkelyDB source tree, you find some methods not exported in/usr/lib/python2.3/bsddb/__init__.py although at least some do exist in dbobj.py. For example, of my interrest were two mentioned in the patch. I believe someone should go and make sure they are present. ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2005-02-23 01:01 Message: Logged In: YES user_id=696559 Please read docs/ref/env/db_config.html and allow users to specify the DB_CONFIG file to override any methods not expoerted through bsddb wrapper yet. Using that approach, user can alter many options available only when database is created! docs/ref/am_misc/tune.html docs/ref/am_misc/faq.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149447&group_id=5470 From noreply at sourceforge.net Wed Feb 23 14:21:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 14:21:41 2005 Subject: [ python-Bugs-1149798 ] hotshot.runctx: builtins missing Message-ID: Bugs item #1149798, was opened at 2005-02-23 13:21 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=1149798&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot.runctx: builtins missing Initial Comment: We start with a boring example. >>> import profile >>> profile.Profile().runctx('print len',{},{}) No news here. But if we do exactly the same using hotshot, we get: >>> import hotshot >>> hotshot.Profile('/tmp/hs').runctx('print len',{},{}) Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/hotshot/__init__.py", line 65, in runctx self._prof.runcode(code, globals, locals) File "", line 1, in ? NameError: name 'len' is not defined The following workaround works: >>> hotshot.Profile('/tmp/hs').runctx('print len',{'__builtins__': __builtins__},{}) But I don't believe this is the way hotshot is supposed to work. This is on Mac Python, IDE, both 2.3 and 2.4, but I think that doesn't matter at all! - Jurjen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149798&group_id=5470 From noreply at sourceforge.net Wed Feb 23 14:26:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 14:26:46 2005 Subject: [ python-Bugs-1149804 ] macostools.mkdirs: not thread-safe Message-ID: Bugs item #1149804, was opened at 2005-02-23 13:26 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=1149804&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: macostools.mkdirs: not thread-safe Initial Comment: Here is an easily fixable semi-bug in macostools: When two threads are creating the same directory structure, one of them will fail as soon as the other thread made a directory. This is trivially fixable by ignoring the error, but I'm not sure if it is worth it, like this: def mkdirs(dst): """Make directories leading to 'dst' if they don't exist yet""" if dst == '' or os.path.exists(dst): return head, tail = os.path.split(dst) if os.sep == ':' and not ':' in head: head = head + ':' mkdirs(head) try: os.mkdir(dst, 0777) except OSError, err: if err.errno==17: #file exists #someone else has created the directory in the meantime. That's fine with me! pass else: raise - Jurjen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149804&group_id=5470 From noreply at sourceforge.net Wed Feb 23 14:33:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 14:33:05 2005 Subject: [ python-Feature Requests-1144057 ] future warning in commets Message-ID: Feature Requests item #1144057, was opened at 2005-02-18 16:10 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-02-23 08:33 Message: Logged In: YES user_id=99874 I agree with doerwalter. If the file is in ascii, then it should be in ascii... even comments. If it's not in ascii, that's fine, but it needs to be marked as to what encoding it IS in. I don't happen to know of any encodings in which certain bytes with the high bit set indicate newlines, but imagine that there were one. The newline marks the end of the comment, so it makes a syntactic difference in the program... we must be able to recognize newlines in order to parse the file. And if we don't know the encoding, then how can we possibly recognize newlines? I propose rejecting the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-21 04:17 Message: Logged In: YES user_id=89016 I don't think we should change this. The encoding is something that affects the whole file not just the executable part of it. When a file that claims to be ASCII contains bytes > 0x7f there's something fishy going on, no matter where these bytes are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 From noreply at sourceforge.net Wed Feb 23 14:44:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 14:44:06 2005 Subject: [ python-Feature Requests-1144057 ] future warning in commets Message-ID: Feature Requests item #1144057, was opened at 2005-02-18 22:10 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 Category: Parser/Compiler Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) >Assigned to: M.-A. Lemburg (lemburg) Summary: future warning in commets Initial Comment: Python uses '#' as start of comment, generally these lines can (should) be ignored by python compiler but .. deprecation warnings are issued when comment contains non ascii letters - ord(ch) not in range 0-127 can we disable it in this situation ? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-02-23 14:44 Message: Logged In: YES user_id=38388 +1, this request is not in line with the source code encoding PEP. Rejecting the request. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-02-23 14:33 Message: Logged In: YES user_id=99874 I agree with doerwalter. If the file is in ascii, then it should be in ascii... even comments. If it's not in ascii, that's fine, but it needs to be marked as to what encoding it IS in. I don't happen to know of any encodings in which certain bytes with the high bit set indicate newlines, but imagine that there were one. The newline marks the end of the comment, so it makes a syntactic difference in the program... we must be able to recognize newlines in order to parse the file. And if we don't know the encoding, then how can we possibly recognize newlines? I propose rejecting the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-02-21 10:17 Message: Logged In: YES user_id=89016 I don't think we should change this. The encoding is something that affects the whole file not just the executable part of it. When a file that claims to be ASCII contains bytes > 0x7f there's something fishy going on, no matter where these bytes are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1144057&group_id=5470 From noreply at sourceforge.net Wed Feb 23 16:02:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 23 16:02:51 2005 Subject: [ python-Bugs-1123716 ] descrintro describes __new__ and __init__ behavior wrong Message-ID: Bugs item #1123716, was opened at 2005-02-16 01:48 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123716&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: descrintro describes __new__ and __init__ behavior wrong Initial Comment: The current descrintro.html says: "__new__ must return an object... If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called..." This suggests that __new__ will call __init__ of the object even if the object is a different type. The code in typeobject.c disagrees with this: static PyObject * type_call(PyTypeObject *type, PyObject *args, PyObject *kwds) { ... /* If the returned object is not an instance of type, it won't be initialized. */ if (!PyType_IsSubtype(obj->ob_type, type)) return obj; ... } Suggested fix: "__new__ must return an object... If you return an existing object, the constructor call will still call its __init__ method unless the object is an instance of a different class..." ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-02-23 10:02 Message: Logged In: YES user_id=99874 I agree strongly that the docs need to be clarified. I spent a while playing around with it and confirmed that your reading of it appears to be correct, and your proposed wording is simple and straightforward. I second the request to make this change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123716&group_id=5470 From noreply at sourceforge.net Thu Feb 24 00:03:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 00:03:29 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-11 21:59 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-23 18:03 Message: Logged In: YES user_id=593130 In my opinion, reopening this, in the absence of additional information that there really is a bug in Python itself, is an inappropriate waste of developer time. Please reclose until such time as you do have such evidence. Please take any further discussion of the general stability of the 2.4 release to a more appropriate forum, such as comp.lang.python, or the corresponding mailing list. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 16:21 Message: Logged In: YES user_id=142612 In response to tim_one's message (2005-02-12 04:46): I also like python and use it for several hours a day. Python 2.3.4 and 2.3.5 are very stable and I couldn't crash them (without buggy extension modules). I claim only that 2.4.0 is unstable at least in some use cases. Please see bug #1120452, for example: http://sourceforge.net/tracker/?func=detail&aid=1121201&group_id=5470&atid=105470 The attached app uses only pure python and standard library for simple HTML templating. Note, that PyMeld does not use a C extension. It can crash Python 2.4.0 with a segfault under Windows XP and Debian Linux 3.0r2 (kernel 2.4.28). The bug has been reproduces by another sourceforge users. Thanks for your comment. Greetings, Complex ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-18 16:21 Message: Logged In: YES user_id=357491 Since this seems to be a VPython issue closing as invalid. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 15:53 Message: Logged In: YES user_id=142612 Thanks for the info. I'm waiting for a stable version of VPython. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-16 20:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-11 22:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 22:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 22:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Thu Feb 24 01:32:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 01:32:58 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-11 00:04 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-02-24 00:32 Message: Logged In: YES user_id=35752 I can reproduce the crash on my machine if I revert the patch for bug #1072259 (_sre.c 2.110). Here's what gdb says: 0x0810342a in sre_match (state=0xbfffca80, pattern=0x81bfbf2) at ../Modules/_sre.c:854 854 state->mark[j++] = NULL; (gdb) p j $7 = -1209149847 (gdb) p &(state->mark) $8 = (void *(*)[200]) 0xbfffcaa8 (gdb) p &j $9 = (int *) 0xbfffc9c0 Either the bug has been fixed or _sre has been changed enough that the test no longer triggers a crash. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-22 23:58 Message: Logged In: YES user_id=764593 It probably is a memory scribble bug, though it might not be in re. For instance, the __getattr__ and __setattr__ try to do some shortcuts saving position, and they may cause the out- of-bounds. The crashes are very dependent on order. I wasn't kidding when I said it ran fine and printed None if run as a whole, but crashed when the same lines were input one by one. (Which gave idle a chance to do different things with memory in between, and didn't define a function object.) Also note that the second attribute access (even to a previously OK attribute) could cause a crash, unless it had had a chance to clear things up first -- but then it raised a MemoryError, when I almost certainly wasn't yet out of RAM. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 15:19 Message: Logged In: YES user_id=142612 Some additional information and summary: My machine is a 3.0Hz Intel P4 with 1Gbyte memory, without overclocking. I use 2 antivirus (1 active) and 3 antispyware apps + firewall. The memory has been tested for 6 hours with Knoppix's memtest without any error, so my machine can be considered to be stable. The attached script can crash python 2.4.0 at least for me and jumjjewett. Do not run the script from IDLE, since it can hide the segfault. I usually run my scripts from SciTE (see: www.scintilla.org ). The bug can be reproduced on stock Python 2.4.0 (MSI installer). PyMeld is pure python (uses only the standard library), no C extension modules used. I did not test this bug with the latest CVS versions of Python 2.4. Is produces segfault under Linux. I'll try to narrow down this bug for specific regex patterns. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-22 14:51 Message: Logged In: YES user_id=6656 Well, I still can't make it crash. Can one of you provide a crashing driver script? Better still would be finding which regexp and which input is the problem. (Unless it's a memory-scribble random crasher type bug...) ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 13:07 Message: Logged In: YES user_id=142612 This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-20 01:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 19:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 19:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 14:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Thu Feb 24 01:41:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 01:41:53 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 02:59 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) >Assigned to: Neil Schemenauer (nascheme) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-02-24 00:41 Message: Logged In: YES user_id=35752 Complex, You can increase the chances of sometone trying to debug this by producing as small a test as possible. The attached script (2D_Box.pyw) uses the 'scipy', 'psyco', and 'visual' modules. Eliminating as many of them as possible will be a big help. As far as I can tell, bug #1120452 has nothing to do with this bug. It's looks like a bug in the _sre module and it appears that it has already been fixed in the CVS version of Python. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-23 23:03 Message: Logged In: YES user_id=593130 In my opinion, reopening this, in the absence of additional information that there really is a bug in Python itself, is an inappropriate waste of developer time. Please reclose until such time as you do have such evidence. Please take any further discussion of the general stability of the 2.4 release to a more appropriate forum, such as comp.lang.python, or the corresponding mailing list. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 21:21 Message: Logged In: YES user_id=142612 In response to tim_one's message (2005-02-12 04:46): I also like python and use it for several hours a day. Python 2.3.4 and 2.3.5 are very stable and I couldn't crash them (without buggy extension modules). I claim only that 2.4.0 is unstable at least in some use cases. Please see bug #1120452, for example: http://sourceforge.net/tracker/?func=detail&aid=1121201&group_id=5470&atid=105470 The attached app uses only pure python and standard library for simple HTML templating. Note, that PyMeld does not use a C extension. It can crash Python 2.4.0 with a segfault under Windows XP and Debian Linux 3.0r2 (kernel 2.4.28). The bug has been reproduces by another sourceforge users. Thanks for your comment. Greetings, Complex ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-18 21:21 Message: Logged In: YES user_id=357491 Since this seems to be a VPython issue closing as invalid. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 20:53 Message: Logged In: YES user_id=142612 Thanks for the info. I'm waiting for a stable version of VPython. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-17 01:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-12 03:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 03:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 03:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Thu Feb 24 01:53:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 01:53:56 2005 Subject: [ python-Bugs-1123727 ] gensuitemodule.processfile fails Message-ID: Bugs item #1123727, was opened at 2005-02-16 07:17 Message generated for change (Comment added) made by hhas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: gensuitemodule.processfile fails Initial Comment: gensuitemodule.processfile fails for an application as trivial as Safari, while the same procedure works OK on version 2.3. On version 2.3: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') [lots of dialogs] On version 2.4, same machine: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 222, in processfile verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete creatorsignature, dummy = MacOS.GetCreatorAndType(fname) Error: (-43, 'File not found') I'm pretty conviced the application did not move in the 20 seconds between those two invocations :-) Any suggestions? - Jurjen ---------------------------------------------------------------------- Comment By: has (hhas) Date: 2005-02-24 00:53 Message: Logged In: YES user_id=996627 I think the MacOS extension is broken. The gensuitemodule error you observe on Python 2.4 is probably being masked on Python 2.3 by other bugs that have since been cleaned up. e.g. The following errors OMM (OS10.2.8, Python 2.3.3): print MacOS.GetCreatorAndType('/Applications/TextEdit.app') --> MacOS.Error: (-43, 'File not found') Seems to work on non bundle-based applications, but not bundle-based ones. Maybe you could check this and file a new report on the MacOS extension if you can confirm it. has p.s. Note that gensuitemodule and friends are obsolete. See appscript: http://freespace.virgin.net/hamish.sanderson/appscript.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 From noreply at sourceforge.net Thu Feb 24 02:54:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 02:55:17 2005 Subject: [ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED Message-ID: Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Neil Schemenauer (nascheme) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-24 02:54 Message: Logged In: YES user_id=142612 I'll use 2.3 until the next stable 2.4 release. I closed this bug report - as requested. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-02-24 01:41 Message: Logged In: YES user_id=35752 Complex, You can increase the chances of sometone trying to debug this by producing as small a test as possible. The attached script (2D_Box.pyw) uses the 'scipy', 'psyco', and 'visual' modules. Eliminating as many of them as possible will be a big help. As far as I can tell, bug #1120452 has nothing to do with this bug. It's looks like a bug in the _sre module and it appears that it has already been fixed in the CVS version of Python. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-24 00:03 Message: Logged In: YES user_id=593130 In my opinion, reopening this, in the absence of additional information that there really is a bug in Python itself, is an inappropriate waste of developer time. Please reclose until such time as you do have such evidence. Please take any further discussion of the general stability of the 2.4 release to a more appropriate forum, such as comp.lang.python, or the corresponding mailing list. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 22:21 Message: Logged In: YES user_id=142612 In response to tim_one's message (2005-02-12 04:46): I also like python and use it for several hours a day. Python 2.3.4 and 2.3.5 are very stable and I couldn't crash them (without buggy extension modules). I claim only that 2.4.0 is unstable at least in some use cases. Please see bug #1120452, for example: http://sourceforge.net/tracker/?func=detail&aid=1121201&group_id=5470&atid=105470 The attached app uses only pure python and standard library for simple HTML templating. Note, that PyMeld does not use a C extension. It can crash Python 2.4.0 with a segfault under Windows XP and Debian Linux 3.0r2 (kernel 2.4.28). The bug has been reproduces by another sourceforge users. Thanks for your comment. Greetings, Complex ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-02-18 22:21 Message: Logged In: YES user_id=357491 Since this seems to be a VPython issue closing as invalid. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-18 21:53 Message: Logged In: YES user_id=142612 Thanks for the info. I'm waiting for a stable version of VPython. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-02-17 02:53 Message: Logged In: YES user_id=699438 Also note that : http://vpython.org/win_download24.html has the following text ;-) """ This version of VPython for Python 2.4 should be considered experimental. Known bugs: 1) Programs that use the "text" module to display block letters (including the demo programs stonehenge.py and texttest.py) fail on some computers. We would appreciate feedback on any bugs you may find. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-12 04:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 From noreply at sourceforge.net Thu Feb 24 04:24:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 04:24:19 2005 Subject: [ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Message-ID: Bugs item #1120452, was opened at 2005-02-10 19:04 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-23 22:24 Message: Logged In: YES user_id=149084 The IDLE subprocess does different things with memory because it's threaded, with one thread minding the sockets and the other executing user code. So I'd stay away from IDLE when working on this. (Also, the debug traces are excessively complex.) ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-02-23 19:32 Message: Logged In: YES user_id=35752 I can reproduce the crash on my machine if I revert the patch for bug #1072259 (_sre.c 2.110). Here's what gdb says: 0x0810342a in sre_match (state=0xbfffca80, pattern=0x81bfbf2) at ../Modules/_sre.c:854 854 state->mark[j++] = NULL; (gdb) p j $7 = -1209149847 (gdb) p &(state->mark) $8 = (void *(*)[200]) 0xbfffcaa8 (gdb) p &j $9 = (int *) 0xbfffc9c0 Either the bug has been fixed or _sre has been changed enough that the test no longer triggers a crash. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-22 18:58 Message: Logged In: YES user_id=764593 It probably is a memory scribble bug, though it might not be in re. For instance, the __getattr__ and __setattr__ try to do some shortcuts saving position, and they may cause the out- of-bounds. The crashes are very dependent on order. I wasn't kidding when I said it ran fine and printed None if run as a whole, but crashed when the same lines were input one by one. (Which gave idle a chance to do different things with memory in between, and didn't define a function object.) Also note that the second attribute access (even to a previously OK attribute) could cause a crash, unless it had had a chance to clear things up first -- but then it raised a MemoryError, when I almost certainly wasn't yet out of RAM. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 10:19 Message: Logged In: YES user_id=142612 Some additional information and summary: My machine is a 3.0Hz Intel P4 with 1Gbyte memory, without overclocking. I use 2 antivirus (1 active) and 3 antispyware apps + firewall. The memory has been tested for 6 hours with Knoppix's memtest without any error, so my machine can be considered to be stable. The attached script can crash python 2.4.0 at least for me and jumjjewett. Do not run the script from IDLE, since it can hide the segfault. I usually run my scripts from SciTE (see: www.scintilla.org ). The bug can be reproduced on stock Python 2.4.0 (MSI installer). PyMeld is pure python (uses only the standard library), no C extension modules used. I did not test this bug with the latest CVS versions of Python 2.4. Is produces segfault under Linux. I'll try to narrow down this bug for specific regex patterns. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-22 09:51 Message: Logged In: YES user_id=6656 Well, I still can't make it crash. Can one of you provide a crashing driver script? Better still would be finding which regexp and which input is the problem. (Unless it's a memory-scribble random crasher type bug...) ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2005-02-22 08:07 Message: Logged In: YES user_id=142612 This bug is a segfault, a real crash using only the stock 2.4.0. It has been reproduced correctly by jimjjewett. It seems to be a regexp related bug. I've changed the category to pass this bug to a regexp expert. Thanks for any help. - Complex ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-19 20:56 Message: Logged In: YES user_id=149084 The restart in IDLE will occur if the subprocess is terminated or segfaults. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:55 Message: Logged In: YES user_id=764593 __gettattr__ alone can provoke the crash, if used several times, and on sub-melds. I can print both StreamURL1 and StreamURL2. If I ask it for p.StreamURL2.src and p.StreamURL1.value, it prints whichever one I ask for first, and then crashes on the second. I did get it to print both (not assign, just __getattr__) by first getting several other attributes from p.StreamURL1, including some that didn't exist, so that there was a raise AttributeError in between. Doing this a half dozen times, I provoked a MemoryError. """ >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2.src Traceback (most recent call last): File "", line 1, in -toplevel- p.StreamURL2.src File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 475, in __getattr__ start = self._findElementFromID(name) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 425, in _findElementFromID match = _findIDMatch(nodeID, subset) File "C:\Python24\Lib\site-packages\segfault240\PyMeld. py", line 282, in _findIDMatch match = re.search(thisRE, text) File "C:\Python24\lib\sre.py", line 134, in search return _compile(pattern, flags).search(string) MemoryError >>> """ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 14:36 Message: Logged In: YES user_id=764593 Partially reproduced on Windows XP. (Using the stock 2.4. 0 msi) Just loading it in IDLE and hitting F5 (run), it prints None, as though it had succeeded perfectly. Typing in the commands from index.py by hand, I can get it to give me the "encountered an error; Tell Microsoft?" box, but IDLE only restarts instead of actually crashing. There seems to a problem between the __getattr__ and the __setattr__ in PyMeld. """ >>> p=Meld(open('player.html','rb').read()) >>> p.StreamURL1.value 'mss://stream.url' >>> p.StreamURL2 >>> p.StreamURL2.src 'mms://stream.url' >>> v=Video() >>> v.stream 's' >>> p.StreamURL1.value=v.stream >>> p.StreamURL1.value >>> ================================ RESTART ================================ >>> """ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-11 09:57 Message: Logged In: YES user_id=6656 What do you do to make it crash? "python index.py"? It doesn't fail for me with CVS HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 From noreply at sourceforge.net Thu Feb 24 18:07:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 18:07:26 2005 Subject: [ python-Bugs-1024427 ] WinCVS doesn't recognize 2.4a3 Message-ID: Bugs item #1024427, was opened at 2004-09-08 10:54 Message generated for change (Comment added) made by jkuzeja You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 Category: None Group: 3rd Party Status: Closed Resolution: Invalid Priority: 7 Submitted By: David W. Thomas (davidwt) Assigned to: Martin v. L?wis (loewis) Summary: WinCVS doesn't recognize 2.4a3 Initial Comment: WinCVS does not recognize the alpha release of 2.4 after using the .msi installation of python. ---------------------------------------------------------------------- Comment By: Jim Kuzeja (jkuzeja) Date: 2005-02-24 12:07 Message: Logged In: YES user_id=351877 Just for completeness: In WinCVS, use Admin/Preferences, go to the WinCvs tab, click the browse button next to Python DLL, and look in the system32 subdirectory of the Windows directory for python24.dll. That worked for me - ymmv. -Jim ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 04:39 Message: Logged In: YES user_id=21627 This is not a bug in Python. WinCVS has python23.dll, python22.dll, python21.dll hard-coded, see common/PythonGlue.cpp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 From noreply at sourceforge.net Thu Feb 24 21:08:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 24 21:08:19 2005 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-14 22:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: pickle files should be opened in binary mode Initial Comment: pickle (and cPickle): At _each_ mention of the pickle file, the docs should say that it should be opened with 'wb' or 'rb' mode as appropriate, so that a pickle written on one OS can be read reliably on another. The example code at the end of the section should be updated to use the 'b' flag. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-24 21:08 Message: Logged In: YES user_id=21627 sjmachin, it seems pretty clear what to do now. Would you volunteer to come up with a patch yourself? ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-01-19 14:51 Message: Logged In: YES user_id=480138 Re Fred's question: Refer to thread starting at http://mail.python.org/pipermail/python-dev/2003- February/033362.html Looks like the story is like this: For pickle mode 1 or higher, always use binary mode for reading/writing. For pickle mode 0, either (a) read/write in text mode and if moving to another OS, do so in text mode i.e. convert the line endings where necessary or (b) as for pickle mode 1+, stick with binary throughout. Also should add a generalisation of Tim's comment re NotePad, e.g. something like """A file written with pickle mode 0 and file mode 'wb' will contain lone linefeeds as line terminators. This will cause it to "look funny" when viewed on Windows or MacOS as a text file by editors like Notepad that do not understand this format.""" ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 14:45 Message: Logged In: YES user_id=31435 Yes, binary mode should always be used, regardless of protocol. Else pickles aren't portable across boxes (in particular, Unix can't read a protocol 0 pickle produced on Windows if the latter was written to a text-mode file). "text mode" was a horrible name for protocol 0. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 06:09 Message: Logged In: YES user_id=3066 In response to irmin's comment: freopen() is only an option for real file objects; pickles are often stored or read from other sources. These other sources are usually binary to begin with, fortunately, though this issue probably deserves some real coverage in the documentation either way. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 06:06 Message: Logged In: YES user_id=3066 Is this true in all cases? Shouldn't files containing text pickles (protocol 0) be opened in text mode? (A problem, given that all protocols should be readable without prior knowledge of the protocol used to write the pickle.) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:07 Message: Logged In: YES user_id=129426 Can't the pickle code just freopen() the file itself, using binary mode? Or is this against Python's rule "explicit is better than implicit" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 From noreply at sourceforge.net Fri Feb 25 12:22:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 12:22:11 2005 Subject: [ python-Bugs-1123727 ] gensuitemodule.processfile fails Message-ID: Bugs item #1123727, was opened at 2005-02-16 07:17 Message generated for change (Comment added) made by jneb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: gensuitemodule.processfile fails Initial Comment: gensuitemodule.processfile fails for an application as trivial as Safari, while the same procedure works OK on version 2.3. On version 2.3: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') [lots of dialogs] On version 2.4, same machine: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 222, in processfile verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete creatorsignature, dummy = MacOS.GetCreatorAndType(fname) Error: (-43, 'File not found') I'm pretty conviced the application did not move in the 20 seconds between those two invocations :-) Any suggestions? - Jurjen ---------------------------------------------------------------------- >Comment By: Jurjen N.E. Bos (jneb) Date: 2005-02-25 11:22 Message: Logged In: YES user_id=446428 Yep, you're right. On both 2.3, and 2.4, I get: >>> import MacOS >>> print MacOS.GetCreatorAndType('/Applications/TextEdit.app') Traceback (most recent call last): File "", line 1, in ? Error: (-43, 'File not found') When will appscript be incorporated into the standard libraries? - Jurjen ---------------------------------------------------------------------- Comment By: has (hhas) Date: 2005-02-24 00:53 Message: Logged In: YES user_id=996627 I think the MacOS extension is broken. The gensuitemodule error you observe on Python 2.4 is probably being masked on Python 2.3 by other bugs that have since been cleaned up. e.g. The following errors OMM (OS10.2.8, Python 2.3.3): print MacOS.GetCreatorAndType('/Applications/TextEdit.app') --> MacOS.Error: (-43, 'File not found') Seems to work on non bundle-based applications, but not bundle-based ones. Maybe you could check this and file a new report on the MacOS extension if you can confirm it. has p.s. Note that gensuitemodule and friends are obsolete. See appscript: http://freespace.virgin.net/hamish.sanderson/appscript.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 From noreply at sourceforge.net Fri Feb 25 18:20:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 18:20:41 2005 Subject: [ python-Bugs-1123727 ] gensuitemodule.processfile fails Message-ID: Bugs item #1123727, was opened at 2005-02-16 07:17 Message generated for change (Comment added) made by hhas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: gensuitemodule.processfile fails Initial Comment: gensuitemodule.processfile fails for an application as trivial as Safari, while the same procedure works OK on version 2.3. On version 2.3: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') [lots of dialogs] On version 2.4, same machine: >>> from gensuitemodule import processfile; processfile('/ Applications/Safari.app') Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 222, in processfile verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete creatorsignature, dummy = MacOS.GetCreatorAndType(fname) Error: (-43, 'File not found') I'm pretty conviced the application did not move in the 20 seconds between those two invocations :-) Any suggestions? - Jurjen ---------------------------------------------------------------------- Comment By: has (hhas) Date: 2005-02-25 17:20 Message: Logged In: YES user_id=996627 > When will appscript be incorporated into the standard libraries? Dunno. It should be finished in the next few months. You'd need to ask Jack what the next entry point into the standard library would be. has ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2005-02-25 11:22 Message: Logged In: YES user_id=446428 Yep, you're right. On both 2.3, and 2.4, I get: >>> import MacOS >>> print MacOS.GetCreatorAndType('/Applications/TextEdit.app') Traceback (most recent call last): File "", line 1, in ? Error: (-43, 'File not found') When will appscript be incorporated into the standard libraries? - Jurjen ---------------------------------------------------------------------- Comment By: has (hhas) Date: 2005-02-24 00:53 Message: Logged In: YES user_id=996627 I think the MacOS extension is broken. The gensuitemodule error you observe on Python 2.4 is probably being masked on Python 2.3 by other bugs that have since been cleaned up. e.g. The following errors OMM (OS10.2.8, Python 2.3.3): print MacOS.GetCreatorAndType('/Applications/TextEdit.app') --> MacOS.Error: (-43, 'File not found') Seems to work on non bundle-based applications, but not bundle-based ones. Maybe you could check this and file a new report on the MacOS extension if you can confirm it. has p.s. Note that gensuitemodule and friends are obsolete. See appscript: http://freespace.virgin.net/hamish.sanderson/appscript.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123727&group_id=5470 From noreply at sourceforge.net Fri Feb 25 19:00:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 19:00:54 2005 Subject: [ python-Bugs-1151968 ] (XMLRPC) multitude of sockets ending up in TIME_WAIT Message-ID: Bugs item #1151968, was opened at 2005-02-25 19: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=1151968&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jonas Wid?n (jonsv322) Assigned to: Nobody/Anonymous (nobody) Summary: (XMLRPC) multitude of sockets ending up in TIME_WAIT Initial Comment: A problem with a multitude of sockets ending up in TIME_WAIT when stressing a system with XML-RPC calls. This can cause a Windows network to missbehave. A solution on Windows platform is to set the sockopt NOLINGER with parameters (1, 0) for the socket before the socket is closed. This vill cause that Windows will release the socket direct without going into TIME_WAIT. The solution in code: In httplib.py@somewhere: NOLINGER = struct.pack('HH', 1, 0) # Release the resource back to the system if socket closed In httplib.py@632: self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, NOLINGER) self.sock.close() # close it manually... there may be other refs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470 From noreply at sourceforge.net Fri Feb 25 21:13:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 21:13:48 2005 Subject: [ python-Bugs-1151968 ] (XMLRPC) multitude of sockets ending up in TIME_WAIT Message-ID: Bugs item #1151968, was opened at 2005-02-25 19:00 Message generated for change (Comment added) made by jonsv322 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jonas Wid?n (jonsv322) Assigned to: Nobody/Anonymous (nobody) Summary: (XMLRPC) multitude of sockets ending up in TIME_WAIT Initial Comment: A problem with a multitude of sockets ending up in TIME_WAIT when stressing a system with XML-RPC calls. This can cause a Windows network to missbehave. A solution on Windows platform is to set the sockopt NOLINGER with parameters (1, 0) for the socket before the socket is closed. This vill cause that Windows will release the socket direct without going into TIME_WAIT. The solution in code: In httplib.py@somewhere: NOLINGER = struct.pack('HH', 1, 0) # Release the resource back to the system if socket closed In httplib.py@632: self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, NOLINGER) self.sock.close() # close it manually... there may be other refs ---------------------------------------------------------------------- >Comment By: Jonas Wid?n (jonsv322) Date: 2005-02-25 21:13 Message: Logged In: YES user_id=352221 Read section, SO_LINGER at following address: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wspsetsockopt_2.asp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470 From noreply at sourceforge.net Fri Feb 25 21:53:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 25 21:53:15 2005 Subject: [ python-Bugs-1151968 ] (XMLRPC) multitude of sockets ending up in TIME_WAIT Message-ID: Bugs item #1151968, was opened at 2005-02-25 19:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jonas Wid?n (jonsv322) Assigned to: Nobody/Anonymous (nobody) Summary: (XMLRPC) multitude of sockets ending up in TIME_WAIT Initial Comment: A problem with a multitude of sockets ending up in TIME_WAIT when stressing a system with XML-RPC calls. This can cause a Windows network to missbehave. A solution on Windows platform is to set the sockopt NOLINGER with parameters (1, 0) for the socket before the socket is closed. This vill cause that Windows will release the socket direct without going into TIME_WAIT. The solution in code: In httplib.py@somewhere: NOLINGER = struct.pack('HH', 1, 0) # Release the resource back to the system if socket closed In httplib.py@632: self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, NOLINGER) self.sock.close() # close it manually... there may be other refs ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-02-25 21:53 Message: Logged In: YES user_id=21627 Why do you want to avoid the TIME_WAIT state, and why do you think it is a Python bug that it doesn't? See http://www.developerweb.net/sock-faq/detail.php?id=13 where Richard Stevens himself explains that SO_LINGER should *not* be used. It might be that SO_REUSEADDR is sufficient, see http://www.developerweb.net/sock-faq/detail.php?id=44 If you want xmlrpclib to use different socket options, you should subclass httplib.HTTP to redefine either connect() or close(), and you should subclass xmlrpclib.Transport to use your subclassed transport. ---------------------------------------------------------------------- Comment By: Jonas Wid?n (jonsv322) Date: 2005-02-25 21:13 Message: Logged In: YES user_id=352221 Read section, SO_LINGER at following address: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wspsetsockopt_2.asp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&group_id=5470 From noreply at sourceforge.net Sat Feb 26 08:24:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 08:24:24 2005 Subject: [ python-Feature Requests-1152248 ] Enhance file.readlines by making line separator selectable Message-ID: Feature Requests item #1152248, was opened at 2005-02-26 17:24 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=1152248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance file.readlines by making line separator selectable Initial Comment: There is no canonical way to iterate through a file on chunks *other* than whole lines without reading the whole file into memory. Allowing the separator to be specified as an argument to file.readlines and file.xreadlines would greatly simplify the task. See here for an example interface of the useful options: http://mail.python.org/pipermail/python-list/2005-February/268482.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 From noreply at sourceforge.net Sat Feb 26 08:38:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 08:38:33 2005 Subject: [ python-Feature Requests-1152248 ] Enhance file.readlines by making line separator selectable Message-ID: Feature Requests item #1152248, was opened at 2005-02-26 08:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance file.readlines by making line separator selectable Initial Comment: There is no canonical way to iterate through a file on chunks *other* than whole lines without reading the whole file into memory. Allowing the separator to be specified as an argument to file.readlines and file.xreadlines would greatly simplify the task. See here for an example interface of the useful options: http://mail.python.org/pipermail/python-list/2005-February/268482.html ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-26 08:38 Message: Logged In: YES user_id=1188172 I don't know whether (x)readlines is the right place, since you are _not_ operating on lines. What about (x)readchunks? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 From noreply at sourceforge.net Sat Feb 26 17:19:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 26 17:19:48 2005 Subject: [ python-Bugs-1152424 ] Dict docstring error Python-2.3.5 Message-ID: Bugs item #1152424, was opened at 2005-02-26 11: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=1152424&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Dict docstring error Python-2.3.5 Initial Comment: Minor error, epydoc reports the following: =========================================================================== In __builtin__.dict docstring: --------------------------------------------------------------------------- L3: Error: Improper paragraph indentation. L5: Error: Improper paragraph indentation. L7: Error: Improper paragraph indentation. L9: Error: Improper paragraph indentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152424&group_id=5470 From noreply at sourceforge.net Sun Feb 27 03:49:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 03:49:09 2005 Subject: [ python-Bugs-1152723 ] urllib2 dont respect debuglevel in httplib Message-ID: Bugs item #1152723, was opened at 2005-02-27 03:49 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=1152723&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: abbatini (abbatini) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 dont respect debuglevel in httplib Initial Comment: It is common habit to see http headers: >>> import httplib >>> httplib.HTTPConnection.debuglevel = 1 >>> import urllib >>> feeddata = urllib.urlopen('http://diveintomark.org/xml/atom.xml').read() but this dont work with import urllib2 with python 2.4 In rev 1.57 was intoduced code to AbstractHTTPHandler class that prevent above mentioned construction. Init method always set debuglevel=0 then do_open method always do: h.set_debuglevel(self._debuglevel) after instantiating HTTPConnection class. Regards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&group_id=5470 From noreply at sourceforge.net Sun Feb 27 03:57:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 03:57:58 2005 Subject: [ python-Bugs-1152723 ] urllib2 dont respect debuglevel in httplib Message-ID: Bugs item #1152723, was opened at 2005-02-27 03:49 Message generated for change (Comment added) made by abbatini You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: abbatini (abbatini) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 dont respect debuglevel in httplib Initial Comment: It is common habit to see http headers: >>> import httplib >>> httplib.HTTPConnection.debuglevel = 1 >>> import urllib >>> feeddata = urllib.urlopen('http://diveintomark.org/xml/atom.xml').read() but this dont work with import urllib2 with python 2.4 In rev 1.57 was intoduced code to AbstractHTTPHandler class that prevent above mentioned construction. Init method always set debuglevel=0 then do_open method always do: h.set_debuglevel(self._debuglevel) after instantiating HTTPConnection class. Regards ---------------------------------------------------------------------- >Comment By: abbatini (abbatini) Date: 2005-02-27 03:57 Message: Logged In: YES user_id=1227778 of course: # h.set_debuglevel(self._debuglevel) work very well, but i dont know reason this code was introduced, maybe forgotten code since development ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&group_id=5470 From noreply at sourceforge.net Sun Feb 27 04:10:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 04:10:51 2005 Subject: [ python-Bugs-1152726 ] Default class args get clobbered by prior instances. Message-ID: Bugs item #1152726, was opened at 2005-02-26 22: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=1152726&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Simon Drabble (sdrabble) Assigned to: Nobody/Anonymous (nobody) Summary: Default class args get clobbered by prior instances. Initial Comment: OS: SuSE Linux 9.2 kernel 2.6.4 Python: 2.3.3 Define a class where the __init__() method takes a default arg of list type. Instantiate this class, and append/ extend the value of its default arg. Instantiate the class again, and the value from the first instance will overwrite the second. The bug is known to exist in 2.3.3, but may exist in subsequent releases also. The attached file illuminates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152726&group_id=5470 From noreply at sourceforge.net Sun Feb 27 04:16:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 04:16:36 2005 Subject: [ python-Bugs-1152726 ] Default class args get clobbered by prior instances. Message-ID: Bugs item #1152726, was opened at 2005-02-26 22:10 Message generated for change (Settings changed) made by sdrabble You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152726&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 8 Submitted By: Simon Drabble (sdrabble) Assigned to: Nobody/Anonymous (nobody) Summary: Default class args get clobbered by prior instances. Initial Comment: OS: SuSE Linux 9.2 kernel 2.6.4 Python: 2.3.3 Define a class where the __init__() method takes a default arg of list type. Instantiate this class, and append/ extend the value of its default arg. Instantiate the class again, and the value from the first instance will overwrite the second. The bug is known to exist in 2.3.3, but may exist in subsequent releases also. The attached file illuminates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152726&group_id=5470 From noreply at sourceforge.net Sun Feb 27 05:33:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 05:33:47 2005 Subject: [ python-Bugs-1110242 ] gzip.GzipFile.flush() does not flush all internal buffers Message-ID: Bugs item #1110242, was opened at 2005-01-26 16:42 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Schnepper (dschnepper) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile.flush() does not flush all internal buffers Initial Comment: flush() is expected to output all pending data stored in internal buffers. gzip.GzipFile.flush() does perform a flush on its fileobj, but does not flush the state of its compressobj prior to the IO flush. This results in being able to use gzip.GzipFile to zip output to a socket and having the other side unzip it in sync with originators flush calls. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-02-26 23:33 Message: Logged In: YES user_id=1115903 This patch appears to fix the bug as described, and running the regression tests on Python 2.5a0 (CVS HEAD) plus this patch turns up no problems. Since the documentation says that a GzipFile "simulates most of the methods of a file object," I would expect GzipFile.flush() to act in the way that David described in the first paragraph of the bug report, and his patch seems to provide that as far as I can tell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470 From noreply at sourceforge.net Sun Feb 27 07:00:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 07:00:52 2005 Subject: [ python-Bugs-1152762 ] curses.textpad raises error Message-ID: Bugs item #1152762, was opened at 2005-02-27 19: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=1152762&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John McPherson (jrm21) Assigned to: Nobody/Anonymous (nobody) Summary: curses.textpad raises error Initial Comment: textpad seems to have a bug when you backspace from the start of a line. By default, stripspaces is on, so it tries to skip any spaces on the previous line. But if there are no spaces, it raises a curses error and makes the app quit. Reproduce by: $ python /usr/lib/python2.3/curses/textpad.py type "1234567890" into the textpad press backspace twice. The problem is _end_of_line() function doing "last = last + 1" I think a better way would be to start at the end of the line (last=self.maxx), and skip backwards while "last" is a space: while last > 0 and ascii.ascii(self.win.inch(y, last)) == ascii.SP: last -= 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152762&group_id=5470 From noreply at sourceforge.net Sun Feb 27 14:18:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 14:19:01 2005 Subject: [ python-Bugs-1152726 ] Default class args get clobbered by prior instances. Message-ID: Bugs item #1152726, was opened at 2005-02-26 22:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152726&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 8 Submitted By: Simon Drabble (sdrabble) Assigned to: Nobody/Anonymous (nobody) Summary: Default class args get clobbered by prior instances. Initial Comment: OS: SuSE Linux 9.2 kernel 2.6.4 Python: 2.3.3 Define a class where the __init__() method takes a default arg of list type. Instantiate this class, and append/ extend the value of its default arg. Instantiate the class again, and the value from the first instance will overwrite the second. The bug is known to exist in 2.3.3, but may exist in subsequent releases also. The attached file illuminates the problem. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-27 08:18 Message: Logged In: YES user_id=80475 Sorry, this is not a bug. It is part of how Python works. In general, do not use mutables for default values. Instead, write something like: def f(x, seq=None): if seq is None: seq = [] . . . There is a FAQ on the subject: http://www.python.org/doc/faq/general.html#why-are-default-values-shared-between-objects ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152726&group_id=5470 From noreply at sourceforge.net Sun Feb 27 20:32:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 20:32:22 2005 Subject: [ python-Bugs-673797 ] setting socket timeout crashes SSL? Message-ID: Bugs item #673797, was opened at 2003-01-23 19:58 Message generated for change (Comment added) made by pristine777 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673797&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: setting socket timeout crashes SSL? Initial Comment: First: bravo for compiling SSL support in the 2.3 binaries! I can connect fine to a secure web server using HTTPS. However, when I set a socket default timeout, I get errors: import socket socket.setdefaulttimeout(30.0) import urllib f = urllib.urlopen('https://members.tufts-health.com/memindex.html') print f.read() =================== Traceback (most recent call last): File "testssl.py", line 9, in ? f = urllib.urlopen('https://members.tufts-health.com/memindex.html') File "/usr/lib/python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/usr/lib/python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/usr/lib/python2.3/urllib.py", line 375, in open_https h.endheaders() File "/usr/lib/python2.3/httplib.py", line 695, in endheaders self._send_output() File "/usr/lib/python2.3/httplib.py", line 581, in _send_output self.send(msg) File "/usr/lib/python2.3/httplib.py", line 548, in send self.connect() File "/usr/lib/python2.3/httplib.py", line 945, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) socket.sslerror: (2, 'The operation did not complete (read)') =================== This is on Linux; similar behaviour on Win2K. ---------------------------------------------------------------------- Comment By: pristine777 (pristine777) Date: 2005-02-27 11:32 Message: Logged In: YES user_id=1228732 This bug has resurfaced in Python 2.4. The exact same code as in the original bug report gives the same error. I also tried using urllib2 and it gives the same result. I have tried this only on Windows (both XP professional SP2, and Windows Server 2003). I am unable to re-open this bug report so should I just file a new one? Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-03 13:43 Message: Logged In: YES user_id=33168 The patch was checked in, so I'm closing this bug. Please re-open if there are any problems. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-01-31 09:55 Message: Logged In: YES user_id=88162 This is fixed by patch 676472 so when that patch is checked in, this bug can be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673797&group_id=5470 From noreply at sourceforge.net Sun Feb 27 20:41:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 20:41:11 2005 Subject: [ python-Bugs-1153016 ] Setting socket timeout crashes SSL Message-ID: Bugs item #1153016, was opened at 2005-02-27 11: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=1153016&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pristine777 (pristine777) Assigned to: Nobody/Anonymous (nobody) Summary: Setting socket timeout crashes SSL Initial Comment: This bug was fixed in Python 2.3 but has resurfaced in Python 2.4 The original bug report can be found at: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=673797&group_id=5470 The method urlopen both in urllib and in urllib2 crashes if socket.setdefaulttimeout has been called. Below is a cut and paste when using the function in urllib. >>> import socket >>> socket.setdefaulttimeout(30.0) >>> import urllib >>> urllib.urlopen('https://members.tufts- health.com/memindex.html') Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 180, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 374, in open_https h.endheaders() File "C:\Python24\lib\httplib.py", line 794, in endheaders self._send_output() File "C:\Python24\lib\httplib.py", line 675, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 642, in send self.connect() File "C:\Python24\lib\httplib.py", line 1069, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "C:\Python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) IOError: [Errno socket error] (2, 'The operation did not complete (read)') Thanks a ton! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470 From noreply at sourceforge.net Sun Feb 27 21:16:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 21:16:59 2005 Subject: [ python-Bugs-1153027 ] http_error_302() crashes with 'HTTP/1.1 400 Bad Request Message-ID: Bugs item #1153027, was opened at 2005-02-27 12: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=1153027&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pristine777 (pristine777) Assigned to: Nobody/Anonymous (nobody) Summary: http_error_302() crashes with 'HTTP/1.1 400 Bad Request Initial Comment: I was able to get to a website by using both IE and FireFox but my Python code kept giving HTTP 400 Bad request error. To debug, I set set_http_debuglevel(1) as in the following code: hh = urllib2.HTTPHandler() hh.set_http_debuglevel(1) opener = urllib2.build_opener (hh,urllib2.HTTPCookieProcessor(self.cj)) The printed debug messages show that this crash happens when there is a space in the redirected location. Here's a cut-and-paste of the relevant debug messages (note the line starting with send that http_error_302 is sending): reply: 'HTTP/1.1 302 Moved Temporarily\r\n' header: Connection: close header: Date: Sun, 27 Feb 2005 19:52:51 GMT header: Server: Microsoft-IIS/6.0 <---other header data--> send: 'GET /myEmail/User?asOf=02/26/2005 11:38:12 PM& ddn=87cb51501730 <---remaining header data--> reply: 'HTTP/1.1 400 Bad Request\r\n' header: Content-Type: text/html header: Date: Sun, 27 Feb 2005 19:56:45 GMT header: Connection: close header: Content-Length: 20 To fix this, I first tried to encode the redirected location in the function http_error_302() in urllib2 using the methods urllib.quote and urllib.urlencode but to no avail (they encode other data as well). A temporary solution that works is to replace any space in the redirected URL by'%20'. Below is a snippet of the function http_error_302 in urllib2 with this suggested fix: def http_error_302(self, req, fp, code, msg, headers): # Some servers (incorrectly) return multiple Location headers # (so probably same goes for URI). Use first header. if 'location' in headers: newurl = headers.getheaders('location')[0] elif 'uri' in headers: newurl = headers.getheaders('uri')[0] else: return newurl=newurl.replace(' ','%20') # <<< TEMP FIX - inserting this line temporarily fixes this problem newurl = urlparse.urljoin(req.get_full_url(), newurl) <--- remainder of this function --> Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&group_id=5470 From noreply at sourceforge.net Sun Feb 27 22:55:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 27 22:56:01 2005 Subject: [ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro Message-ID: Bugs item #1153075, was opened at 2005-02-27 21: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=1153075&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 From noreply at sourceforge.net Mon Feb 28 02:09:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 02:10:00 2005 Subject: [ python-Bugs-1153163 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153163, was opened at 2005-02-27 20: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=1153163&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: HughSW (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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470 From noreply at sourceforge.net Mon Feb 28 02:23:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 02:23:15 2005 Subject: [ python-Bugs-1153171 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153171, was opened at 2005-02-27 20: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=1153171&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: HughSW (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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 From noreply at sourceforge.net Mon Feb 28 02:30:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 02:30:26 2005 Subject: [ python-Bugs-1153171 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153171, was opened at 2005-02-27 20:23 Message generated for change (Settings changed) made by hughsw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: HughSW (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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 From noreply at sourceforge.net Mon Feb 28 02:31:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 02:31:29 2005 Subject: [ python-Bugs-1153171 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153171, was opened at 2005-02-27 20:23 Message generated for change (Comment added) made by hughsw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Submitted By: HughSW (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: HughSW (hughsw) Date: 2005-02-27 20:31 Message: Logged In: YES user_id=1146279 Someone remove this accidental repost. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 From noreply at sourceforge.net Mon Feb 28 03:05:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 03:05:12 2005 Subject: [ python-Bugs-1153171 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153171, was opened at 2005-02-27 20:23 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: HughSW (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: HughSW (hughsw) Date: 2005-02-27 20:31 Message: Logged In: YES user_id=1146279 Someone remove this accidental repost. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153171&group_id=5470 From noreply at sourceforge.net Mon Feb 28 06:10:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 06:10:31 2005 Subject: [ python-Bugs-1153226 ] string interpolation breaks with %d and large float Message-ID: Bugs item #1153226, was opened at 2005-02-28 15: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=1153226&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Thorne (jerub) Assigned to: Nobody/Anonymous (nobody) Summary: string interpolation breaks with %d and large float Initial Comment: We have experienced a problem recently when wanting to render a large float as a string. Converting the float to an int/long manuall was required. '%d' % f throws an exception for all floats f, f >= 2**31 Expected output, shown with 'int()' and 'long()': >>> '%d %d' % (long(float(2**31)), int(float(2**31))) '2147483648 2147483648' Non-Working Example. >>> '%d' % float(2**31) Traceback (most recent call last): File "", line 1, in ? TypeError: int argument required Tested on: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) Python 2.4.1a0 (#2, Feb 9 2005, 22:42:24) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470 From noreply at sourceforge.net Mon Feb 28 07:09:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 07:09:21 2005 Subject: [ python-Bugs-1153163 ] reflected operator not used when operands have the same type Message-ID: Bugs item #1153163, was opened at 2005-02-27 20:09 Message generated for change (Comment added) made by hughsw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: HughSW (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: HughSW (hughsw) Date: 2005-02-28 01: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 Mon Feb 28 17:48:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 17:48:43 2005 Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly Message-ID: Bugs item #1153622, was opened at 2005-02-28 17: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=1153622&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: eval does not bind variables in lambda bodies correctly Initial Comment: eval() does not bind variables in lambda expressions correctly: >>>def f(g): return eval('lambda x: g(x)') >>>f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in NameError: global name 'g' is not defined The docs say this about eval(): # If both dictionaries are omitted, the expression is # executed in the environment where eval is called. and using plain local variables work as expected: >>>def h(d): return eval('d(10)') >>>h(lambda y: y * 2) 20 Also, if locals() is presented as the global dict to eval(), it works: >>>def f(g): return eval('lambda x: g(x)', locals(), locals()) >>>f(lambda y: y * 2)(17) 34 but this does not allow the expression to reference global variables of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 From noreply at sourceforge.net Mon Feb 28 19:57:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 19:57:37 2005 Subject: [ python-Feature Requests-1152248 ] Enhance file.readlines by making line separator selectable Message-ID: Feature Requests item #1152248, was opened at 2005-02-26 07:24 Message generated for change (Comment added) made by nessus42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance file.readlines by making line separator selectable Initial Comment: There is no canonical way to iterate through a file on chunks *other* than whole lines without reading the whole file into memory. Allowing the separator to be specified as an argument to file.readlines and file.xreadlines would greatly simplify the task. See here for an example interface of the useful options: http://mail.python.org/pipermail/python-list/2005-February/268482.html ---------------------------------------------------------------------- Comment By: Douglas Alan (nessus42) Date: 2005-02-28 18:57 Message: Logged In: YES user_id=401880 In reply to birkenfeld, I'm not sure why you don't want to call lines separated with an alternate line-separation string "lines", but if you want to call them something else, I should think they should be called "records" rather than "chunks". |>oug ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-26 07:38 Message: Logged In: YES user_id=1188172 I don't know whether (x)readlines is the right place, since you are _not_ operating on lines. What about (x)readchunks? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 From noreply at sourceforge.net Mon Feb 28 21:37:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 28 21:37:26 2005 Subject: [ python-Bugs-1153769 ] String interpolation needs PEP 237 update Message-ID: Bugs item #1153769, was opened at 2005-02-28 20:37 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=1153769&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: Nobody/Anonymous (nobody) Summary: String interpolation needs PEP 237 update Initial Comment: String interpolation in libstdtypes.tex doesn't yet document PEP 237 (integer unification) changes. Specifically that: %u %x %X and %o now do signed conversions and that %u is obsolescent. Also, I can't parse the sentence beginning "The length modifier" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153769&group_id=5470