From noreply at sourceforge.net Sat Jan 1 06:48:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 06:48:31 2005 Subject: [ python-Bugs-1091740 ] garbage collector still documented as optional Message-ID: Bugs item #1091740, was opened at 2004-12-27 10:38 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091740&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Raymond Hettinger (rhettinger) Summary: garbage collector still documented as optional Initial Comment: Section 3.2 of the library reference, first paragraph, says "The gc module is only available if the interpreter was built with the optional cyclic garbage detector" However according to Misc/NEWS, "Compiling out the cyclic garbage collector is no longer an option" as of Python 2.3 alpha 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091740&group_id=5470 From noreply at sourceforge.net Sat Jan 1 07:18:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 07:19:02 2005 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Sat Jan 1 07:27:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 07:27:42 2005 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:27 Message: Logged In: YES user_id=139309 I just played with a bit more. If I catch the MemoryError and try again, most of the time it will work (sometimes on the second try). These malloc faults seem to be some kind of temporary condition. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Sat Jan 1 10:13:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 10:13:20 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 14:30 Message generated for change (Comment added) made by aminusfu 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: 5 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: Robert Brewer (aminusfu) Date: 2005-01-01 09: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 Sat Jan 1 18:17:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 18:17:44 2005 Subject: [ python-Bugs-1092225 ] IDLE hangs due to subprocess Message-ID: Bugs item #1092225, was opened at 2004-12-28 10:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ZACK (kitanek) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs due to subprocess Initial Comment: IDLE GUI hangs after some time when launched in the default mode (i.e. with the subprocess). I have noticed that the subprocess generates fast continuous stream of system calls even if the GUI is not used and not visible (moved to another desktop). Example output from strace (strace -f idle): ... [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] select(4, [3], [], [], {0, 50000} [pid 5355] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) [pid 5355] write(7, "\0", 1 [pid 5356] <... select resumed> ) = 1 (in [6]) [pid 5355] <... write resumed> ) = 1 [pid 5356] futex(0x81c7250, FUTEX_WAIT, 2, NULL [pid 5355] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5356] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable) [pid 5355] <... futex resumed> ) = 0 [pid 5356] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5355] gettimeofday( [pid 5356] <... futex resumed> ) = 0 [pid 5355] <... gettimeofday resumed> {1104246902, 467914}, {4294967236, 0}) = 0 [pid 5356] read(6, [pid 5355] gettimeofday( [pid 5356] <... read resumed> "\0", 1) = 1 [pid 5355] <... gettimeofday resumed> {1104246902, 468040}, {4294967236, 0}) = 0 [pid 5356] select(7, [6], [], [], NULL [pid 5355] select(6, [5], [], [], {0, 50000} [pid 5357] <... select resumed> ) = 0 (Timeout) [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] select(0, NULL, NULL, NULL, {0, 50000} [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 ... If IDLE is launched without the subprocess (idle -n) than it seems to run just fine without the syscall storm: futex(0x83d1fa0, FUTEX_WAIT, 200, NULL ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-01 12:17 Message: Logged In: YES user_id=149084 The socket is polled by the GUI and the subprocess. What you are seeing is the normal delays and polls. Without the subprocess there is no socket and therefore no polling. Further information is needed. When IDLE "hangs", does the GUI become inactive? Can the subprocess be restarted? Is there any evidence (via ps etc.) that the system is running out of some resource? Does the problem occur if you send a continuous stream of characters to stdout? Is the interval to a "hang" always the same? ---------------------------------------------------------------------- Comment By: ZACK (kitanek) Date: 2004-12-28 10:38 Message: Logged In: YES user_id=1159448 Sorry, I forgot the system specs: Debian Linux, unstable branche (SID) Kernel 2.6.9-1-686 Python 2.3.4 (#2, Dec 3 2004, 13:53:17) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 glib-config --version = 1.2.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 From noreply at sourceforge.net Sat Jan 1 21:28:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 1 21:29:01 2005 Subject: [ python-Feature Requests-846560 ] Slicing infinity Message-ID: Feature Requests item #846560, was opened at 2003-11-21 13:02 Message generated for change (Comment added) made by apb_4 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Michael Hudson (mwh) Summary: Slicing infinity Initial Comment: It would be great to be able to use extended slices instead of range. Here's an example: >>> for i in [0:10:2]: ... print i ... 0 2 4 6 8 A more explicit (but longer) way to write this, could be: for i in infinity[0:10:2]: print i One could alternatively write something like: infinity = range(1000) (but this range is too small) or infinity = range(sys.maxint) (but this gives me a memory-error) or infinity = xrange(sys.maxint) (but xrange cannot be sliced) I've also tried experimenting with iterators and generators, but that would exclude slicing "in thin air" like: for i in [0:10:2]: print i ---------------------------------------------------------------------- Comment By: Adam (apb_4) Date: 2005-01-01 20:28 Message: Logged In: YES user_id=1188305 well u can use a range of 20,000,000 and probably some more although it takes a while. 2mil didn't take too long. ---------------------------------------------------------------------- Comment By: Alexander R?dseth (alexanro) Date: 2003-11-21 13:30 Message: Logged In: YES user_id=679374 Okay, thanks for the checkup! :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-21 13:25 Message: Logged In: YES user_id=6656 This is basically PEP 204: http://www.python.org/peps/pep-0204.html which has been rejected. I'm not aware of any compelling reasons to restart the discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 From noreply at sourceforge.net Sun Jan 2 00:01:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 00:01:10 2005 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Comment added) made by bacchusrx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- >Comment By: bacchusrx (bacchusrx) Date: 2005-01-01 18:01 Message: Logged In: YES user_id=646321 I've been able to replicate the problem reliably on both 10.3.5 and 10.3.7. I've attached two more examples to demonstrate: Try this: Do, "dd if=/dev/zero of=./data bs=1024 count=10240" and save server.pl wherever you put "data". Have three terminals open. In one, run "perl server.pl -s0.25". In another, run "top -ovsize" and in the third run "python example2.py". After about 100 iterations, python's vsize is +1GB (just about the value of cumulative_req in example2.py) and if left running will cause a malloc error at around 360 iterations with a vsize over 3.6GB (again, just about what cumulative_req reports). Mind you, we've only received ~512kbytes. server.pl differs from the netcat method in that it (defaults) to sending only 1492 bytes at a time (configurable with the -b switch) and sleeps for however many seconds specified with the -s switch. This guarantees enough iterations to raise the error each time around. When omittting the -s switch to server.pl, I don't get the error, but throughput is good enough that the loop in readFromSockUntil() only runs a few times. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:27 Message: Logged In: YES user_id=139309 I just played with a bit more. If I catch the MemoryError and try again, most of the time it will work (sometimes on the second try). These malloc faults seem to be some kind of temporary condition. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Sun Jan 2 01:29:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 01:30:12 2005 Subject: [ python-Feature Requests-985094 ] getattr(object, name) accepts only strings Message-ID: Feature Requests item #985094, was opened at 2004-07-05 01:21 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=985094&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: getattr(object,name) accepts only strings Initial Comment: getattr(object,name) function accepts only strings. This behavior prohibits some interesting usage of callables as names in database column and field references. For example: Someone references a database field: value=record.field_name Programmatically, when name is the name of the field: value=getattr(record,field_name) Calculated fields could be implemented by passing a callable as a field name: def fn(record): return '%s (%s)'%(record.name,record.number) value=getattr(record,fn) The database backend checks if the name is callable and then call the name with the record. But this cannot be implemented in the simple way if getattr checks if the name is a string or not. This is an unneccessary check in getattr, setattr and delattr, since prevents interesting solutions. Temporary workaround: value=record.__getattr__(fn) There can be many unneccessary type checks and limitations in core and library functions. They should be removed to allow free usage. ---------------------------------------------------------------------- >Comment By: Viktor Ferenczi (complex) Date: 2005-01-02 01:29 Message: Logged In: YES user_id=142612 Thanks for your comment. I know about property, of course. I had to change an old application where reimplementing everything with properties could be dificult. The problem has been solved for now. I use SQLObject (www.sqlobject.org) for new applications, whereever possible. Usage of other Object-Relational mappings (or even ZODB) are under consideration. - Viktor ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-12-23 23:55 Message: Logged In: YES user_id=4771 This is in part due to historical reasons. I guess you know about "property"? This is exactly what database people usually call calculated fields. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=985094&group_id=5470 From noreply at sourceforge.net Sun Jan 2 01:33:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 01:33:16 2005 Subject: [ python-Bugs-711268 ] A large block of commands after an " if" cannot be Message-ID: Bugs item #711268, was opened at 2003-03-28 04:47 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: A large block of commands after an "if" cannot be Initial Comment: A Generated Python script Contains the code: if 1: file = bugreport.vim ... long list of commands .... Executing this code with: exec cmds in globals(), globals() Results in the error: SystemError: com_backpatch: offset too large Looking into the code for com_backpatch() it appears that the code is more than what can be jumped over. Possible solutions: 1. When there is too much code, use another jump statement that allows for a larger offset. 2. Always use a jump statement with a large offset 3. When "if 1" is used, don't generate a jump statement (not a real fix, but works for the situation where I ran into the bug). It looks like this bug exists in all versions of Python. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-01-01 18:33 Message: Logged In: YES user_id=2772 Please see my (unsuitable for inclusion) patch at http://mail.python.org/pipermail/python-list/2004-November/249827.html I think that message suggests some steps that might result in an acceptable patch. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 10:10 Message: Logged In: YES user_id=752496 Also happens in 2.4. I'm reopening the bug, in group 2.4. ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2004-12-27 10:04 Message: Logged In: YES user_id=57665 It appears between Python 2.2 and 2.3 the efficiency of the produced bytecode was improved. You now need to repeat the command 10923 times to produce the error. Thus the problem remains, it's just further away. You can reproduce the problem with this program: cmds = "if 1:\n" for i in xrange(1, 10923): cmds = cmds + " a = 'a'\n" exec cmds in globals(), globals() I verified with Python 2.3.3, don't have a newer version right now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-26 13:11 Message: Logged In: YES user_id=357491 I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in CVS using 8000 lines. Closing as out of date. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 09:00 Message: Logged In: YES user_id=752496 Can not reproduce the problem in Py2.3.4 using the method posted by vimboss. It's already fixed? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 09:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-03-28 14:03 Message: Logged In: YES user_id=57665 I can reproduce the problem with this text: if 1: a = "a" Repeat the assignment 7282 times. Feed this text to "exec". With 7281 assignments you do not get the error. Looks like 9 bytes are produced per assignment. Good luck fixing this! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 13:18 Message: Logged In: YES user_id=6380 Hm, the 32-bit argument doesn't work because of what backpatch does. It would require a totally different approach to allow backpatching a larer offset, or we'd always have to reserve 4 bytes for the offset. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 13:13 Message: Logged In: YES user_id=6380 Just curious. How big was the block of code? Also, I wonder if the error message is bogus; opcode arguments can now be 32 bits AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 From noreply at sourceforge.net Sun Jan 2 03:22:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 03:22:12 2005 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 21:22 Message: Logged In: YES user_id=139309 Ok. I've tracked it down. realloc(...) on Darwin doesn't actually resize memory unless it *has* to. For shrinking an allocation, it does not have to, therefore realloc(...) with a smaller size is a no-op. It seems that this may be a misunderstanding by Python. The man page for realloc(...) does not say that it will EVER free memory, EXCEPT in the case where it has to allocate a larger region. I'll attach an example that demonstrates this outside of Python. ---------------------------------------------------------------------- Comment By: bacchusrx (bacchusrx) Date: 2005-01-01 18:01 Message: Logged In: YES user_id=646321 I've been able to replicate the problem reliably on both 10.3.5 and 10.3.7. I've attached two more examples to demonstrate: Try this: Do, "dd if=/dev/zero of=./data bs=1024 count=10240" and save server.pl wherever you put "data". Have three terminals open. In one, run "perl server.pl -s0.25". In another, run "top -ovsize" and in the third run "python example2.py". After about 100 iterations, python's vsize is +1GB (just about the value of cumulative_req in example2.py) and if left running will cause a malloc error at around 360 iterations with a vsize over 3.6GB (again, just about what cumulative_req reports). Mind you, we've only received ~512kbytes. server.pl differs from the netcat method in that it (defaults) to sending only 1492 bytes at a time (configurable with the -b switch) and sleeps for however many seconds specified with the -s switch. This guarantees enough iterations to raise the error each time around. When omittting the -s switch to server.pl, I don't get the error, but throughput is good enough that the loop in readFromSockUntil() only runs a few times. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:27 Message: Logged In: YES user_id=139309 I just played with a bit more. If I catch the MemoryError and try again, most of the time it will work (sometimes on the second try). These malloc faults seem to be some kind of temporary condition. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Sun Jan 2 03:23:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 03:23:56 2005 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 21:23 Message: Logged In: YES user_id=139309 #include #define NUM_ALLOCATIONS 100000 #define ALLOC_SIZE 10485760 #define ALLOC_RESIZE 1492 int main(int argc, char **argv) { /* exiting will free all this leaked memory */ for (i = 0; i < NUM_ALLOCATIONS; i++) { void *orig_ptr, *new_ptr; size_t new_size, orig_size; orig_ptr = malloc(ALLOC_SIZE); orig_size = malloc_size(orig_ptr); if (orig_ptr == NULL) { printf("failure to malloc %d\n", i); abort(); } new_ptr = realloc(orig_ptr, ALLOC_RESIZE); new_size = malloc_size(new_ptr); printf("resized %d[%p] -> %d[%p]\n", orig_size, orig_ptr, new_size, new_ptr); if (new_ptr == NULL) { printf("failure to realloc %d\n", i); abort(); } } return 0; } ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 21:22 Message: Logged In: YES user_id=139309 Ok. I've tracked it down. realloc(...) on Darwin doesn't actually resize memory unless it *has* to. For shrinking an allocation, it does not have to, therefore realloc(...) with a smaller size is a no-op. It seems that this may be a misunderstanding by Python. The man page for realloc(...) does not say that it will EVER free memory, EXCEPT in the case where it has to allocate a larger region. I'll attach an example that demonstrates this outside of Python. ---------------------------------------------------------------------- Comment By: bacchusrx (bacchusrx) Date: 2005-01-01 18:01 Message: Logged In: YES user_id=646321 I've been able to replicate the problem reliably on both 10.3.5 and 10.3.7. I've attached two more examples to demonstrate: Try this: Do, "dd if=/dev/zero of=./data bs=1024 count=10240" and save server.pl wherever you put "data". Have three terminals open. In one, run "perl server.pl -s0.25". In another, run "top -ovsize" and in the third run "python example2.py". After about 100 iterations, python's vsize is +1GB (just about the value of cumulative_req in example2.py) and if left running will cause a malloc error at around 360 iterations with a vsize over 3.6GB (again, just about what cumulative_req reports). Mind you, we've only received ~512kbytes. server.pl differs from the netcat method in that it (defaults) to sending only 1492 bytes at a time (configurable with the -b switch) and sleeps for however many seconds specified with the -s switch. This guarantees enough iterations to raise the error each time around. When omittting the -s switch to server.pl, I don't get the error, but throughput is good enough that the loop in readFromSockUntil() only runs a few times. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:27 Message: Logged In: YES user_id=139309 I just played with a bit more. If I catch the MemoryError and try again, most of the time it will work (sometimes on the second try). These malloc faults seem to be some kind of temporary condition. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Sun Jan 2 03:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 03:25:31 2005 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 21:25 Message: Logged In: YES user_id=139309 that code paste is missing an "int i" at the beginning of main.. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 21:23 Message: Logged In: YES user_id=139309 #include #define NUM_ALLOCATIONS 100000 #define ALLOC_SIZE 10485760 #define ALLOC_RESIZE 1492 int main(int argc, char **argv) { /* exiting will free all this leaked memory */ for (i = 0; i < NUM_ALLOCATIONS; i++) { void *orig_ptr, *new_ptr; size_t new_size, orig_size; orig_ptr = malloc(ALLOC_SIZE); orig_size = malloc_size(orig_ptr); if (orig_ptr == NULL) { printf("failure to malloc %d\n", i); abort(); } new_ptr = realloc(orig_ptr, ALLOC_RESIZE); new_size = malloc_size(new_ptr); printf("resized %d[%p] -> %d[%p]\n", orig_size, orig_ptr, new_size, new_ptr); if (new_ptr == NULL) { printf("failure to realloc %d\n", i); abort(); } } return 0; } ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 21:22 Message: Logged In: YES user_id=139309 Ok. I've tracked it down. realloc(...) on Darwin doesn't actually resize memory unless it *has* to. For shrinking an allocation, it does not have to, therefore realloc(...) with a smaller size is a no-op. It seems that this may be a misunderstanding by Python. The man page for realloc(...) does not say that it will EVER free memory, EXCEPT in the case where it has to allocate a larger region. I'll attach an example that demonstrates this outside of Python. ---------------------------------------------------------------------- Comment By: bacchusrx (bacchusrx) Date: 2005-01-01 18:01 Message: Logged In: YES user_id=646321 I've been able to replicate the problem reliably on both 10.3.5 and 10.3.7. I've attached two more examples to demonstrate: Try this: Do, "dd if=/dev/zero of=./data bs=1024 count=10240" and save server.pl wherever you put "data". Have three terminals open. In one, run "perl server.pl -s0.25". In another, run "top -ovsize" and in the third run "python example2.py". After about 100 iterations, python's vsize is +1GB (just about the value of cumulative_req in example2.py) and if left running will cause a malloc error at around 360 iterations with a vsize over 3.6GB (again, just about what cumulative_req reports). Mind you, we've only received ~512kbytes. server.pl differs from the netcat method in that it (defaults) to sending only 1492 bytes at a time (configurable with the -b switch) and sleeps for however many seconds specified with the -s switch. This guarantees enough iterations to raise the error each time around. When omittting the -s switch to server.pl, I don't get the error, but throughput is good enough that the loop in readFromSockUntil() only runs a few times. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:27 Message: Logged In: YES user_id=139309 I just played with a bit more. If I catch the MemoryError and try again, most of the time it will work (sometimes on the second try). These malloc faults seem to be some kind of temporary condition. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 01:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Sun Jan 2 03:40:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 03:40:06 2005 Subject: [ python-Feature Requests-711268 ] A large block of commands after an " if" cannot be Message-ID: Feature Requests item #711268, was opened at 2003-03-28 05:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=711268&group_id=5470 >Category: Parser/Compiler >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: A large block of commands after an "if" cannot be Initial Comment: A Generated Python script Contains the code: if 1: file = bugreport.vim ... long list of commands .... Executing this code with: exec cmds in globals(), globals() Results in the error: SystemError: com_backpatch: offset too large Looking into the code for com_backpatch() it appears that the code is more than what can be jumped over. Possible solutions: 1. When there is too much code, use another jump statement that allows for a larger offset. 2. Always use a jump statement with a large offset 3. When "if 1" is used, don't generate a jump statement (not a real fix, but works for the situation where I ran into the bug). It looks like this bug exists in all versions of Python. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-01 21:40 Message: Logged In: YES user_id=80475 Re-classifying this as a feature request for CPython implementation to be expanded to handle larger relative jumps. The current behavior of raising a SystemError is correct, non-buggy behavior. One solution is to introduce a new bytecode for indirect jumps based on an entry into the constants table. Whenever the distance is too large to backpatch a JUMP_FORWARD, that opcode can be replaced with JUMP_INDIRECT and given an offset into the constant table. This solution is easy to implement. (Reminder, the peepholer should skip any code containing the new opcode.) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-01-01 19:33 Message: Logged In: YES user_id=2772 Please see my (unsuitable for inclusion) patch at http://mail.python.org/pipermail/python-list/2004-November/249827.html I think that message suggests some steps that might result in an acceptable patch. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 11:10 Message: Logged In: YES user_id=752496 Also happens in 2.4. I'm reopening the bug, in group 2.4. ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2004-12-27 11:04 Message: Logged In: YES user_id=57665 It appears between Python 2.2 and 2.3 the efficiency of the produced bytecode was improved. You now need to repeat the command 10923 times to produce the error. Thus the problem remains, it's just further away. You can reproduce the problem with this program: cmds = "if 1:\n" for i in xrange(1, 10923): cmds = cmds + " a = 'a'\n" exec cmds in globals(), globals() I verified with Python 2.3.3, don't have a newer version right now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-26 14:11 Message: Logged In: YES user_id=357491 I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in CVS using 8000 lines. Closing as out of date. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 10:00 Message: Logged In: YES user_id=752496 Can not reproduce the problem in Py2.3.4 using the method posted by vimboss. It's already fixed? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 10:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-03-28 15:03 Message: Logged In: YES user_id=57665 I can reproduce the problem with this text: if 1: a = "a" Repeat the assignment 7282 times. Feed this text to "exec". With 7281 assignments you do not get the error. Looks like 9 bytes are produced per assignment. Good luck fixing this! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 14:18 Message: Logged In: YES user_id=6380 Hm, the 32-bit argument doesn't work because of what backpatch does. It would require a totally different approach to allow backpatching a larer offset, or we'd always have to reserve 4 bytes for the offset. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 14:13 Message: Logged In: YES user_id=6380 Just curious. How big was the block of code? Also, I wonder if the error message is bogus; opcode arguments can now be 32 bits AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=711268&group_id=5470 From noreply at sourceforge.net Sun Jan 2 19:34:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 2 19:34:48 2005 Subject: [ python-Feature Requests-1092962 ] Make Generators Pickle-able Message-ID: Feature Requests item #1092962, was opened at 2004-12-29 13:52 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayson Vantuyl (jaysonvantuyl) Assigned to: Nobody/Anonymous (nobody) Summary: Make Generators Pickle-able Initial Comment: Would it be possible to make generators pickle-able? I mean, currently the internal state is saved in some way. Would it be possible to make pickle handle them? Put another way, if generators had a __getnewargs__ function that returned some data (say a tuple of module name, function name, locals/globals dicts and some code dependent location data) and then allow: generator.__new__(statedata) to reconstruct it (or something more elegant). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-02 10:34 Message: Logged In: YES user_id=341410 In a practical sense I believe this kind of thing is possible (doing a little spelunking in some generators reveals gen.gi_frame, which looks to be the stackframe for the generator). Why it isn't done could have something to do with executing on arbitrary stack frames. In your random-number-generator case, using old-style iterators via classes can do what you want them to do now (that is, won't have to wait until Python 2.5 to make it in, which is at least 1.5 years away). class g: def __init__(self, state=None): if state is None: #generate some default state else: #process the state to validate and internalize it. def __iter__(self): return self def next(self): state = self.state ret = #some function on the current internal state self.state = #some function on the current internal state return ret Heck, you don't even need pickle hooks, because pickle will pickle your iterator's __dict__ attribute. Alternatively, you can use Christian Tismer's Stackless Python, which has generator pickling. ---------------------------------------------------------------------- Comment By: Jayson Vantuyl (jaysonvantuyl) Date: 2004-12-30 10:37 Message: Logged In: YES user_id=626872 I'm not talking about pickling functions. Which, by the way, is not entirely accurate. See the following: >>> from pickle import dumps,loads >>> loads(dumps(dumps)) >>> As you see, we don't pickle the function code, just a reference to it. I propose doing the same with generators, but including the function namespace and frame info in the pickle to allow it to continue execution after unpickling. Furthermore, this is nothing more than what the interpreter already does internally. When a generator yields, all of its state is neatly stashed away. I just would like pickle to be able to get at it, store it, and then later recover it--without dealing with any actual code objects, just the state. As for security, what I am talking about is nothing more or less secure than pickling classes. When we pickle a class, we don't pickle the methods on it. Rather, we pickle the information to reconstruct the class (__getstate__, __getnewargs__, __reduce__). There is a security concern in that modified pickles could be used to put bogus data into the unpickled classes (i.e. a password stored as an attribute on a class could be replaced). What I'm asking for is nothing more than pickling a form of the frozen frame object (or something akin to it) for the generator. Put another way, when the generator isn't running, something stores the entire state of its execution. I'm not sure what it is, but I'd be willing to be it consists of little more than a few dicts (namespaces), some scoping info, and some sort of instruction pointer. By pickling the generator, I propose nothing more radical than pickling a class. The generator is still instantiated from the some code as before (just as a class or function reference is) and it still can/will act on that information (just as a class does). No actual code is pickled. What this does allow is the use of generators for efficent handling of a class. Specifically, I'm writing an application that uses a seeded pseudo-random number generator. The idea is to transmit the state of the generator over the network so that the client/server can deterministically make the same random choices without communicating the complex state that results from that. I have a choice of the following: def randfunc(seed,num,otherstate): # Costly Setup # Iteration to appropriate number otherside.sendPickle( (seed,num,otherstate,) ) l = [ randfunc(123,i,...) for i in range(5) ] Versus def randGen(seed): # Costly Setup # yield in a simple loop r = randGen(123) otherside.sendPickle(r) l = [ r() for i in range(5) ] I think you can see which one is more efficient in terms of both simplicity of expression and ease of coding. Of course, the standard answer to this is to implement a randgen class that contains all of the state. This complicates the code a great deal, since a generator can't be used. What is problematic is that generators are like black holes. Once information goes into them, it won't come back out. There's not a good way to use them for anything more than runtime. This rules out things like process migration, pickling of any structure involving generator data, and generally using them like any other language component. Using them for counters, prngs, prime number generators, OGR sieves, and anything that needs to be used to durably generate a sequence is impossible if that data needs to be persisted. No one would think about implementing a new pickle without the ability to represent classes and function references, generators shouldn't be second class control structures. FYI, Stackless Python already does this, but it may be easier for them due to the way they've modified frame handling. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 06:16 Message: Logged In: YES user_id=21627 Moving into the feature requests tracker. I don't think this is possible (or should be done if it were possible). Pickle has traditionally abstained from pickling functions, so IMO it should not picke generators, either. If this was enabled by default, it would open up yet another security hole. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 From noreply at sourceforge.net Mon Jan 3 14:09:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 14:09:20 2005 Subject: [ python-Bugs-1094960 ] marshal.dumps('hello', 0) "Access violation" Message-ID: Bugs item #1094960, was opened at 2005-01-03 14:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1094960&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Brophy (mbrophy) Assigned to: Nobody/Anonymous (nobody) Summary: marshal.dumps('hello',0) "Access violation" Initial Comment: When attempting to generated marshaled data in <2.4 format, I get a crash in python.exe. With a windows XP installation of Python2.4 from "http://www.python.org/ftp/python/2.4/python-2.4.msi" C:\Python24>python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import marshal >>> marshal.dumps('hello',0) Windows popup: """ python.exe has encountered a problem and needs to close. We are sorry for the inconvenience. """ 'Debug' shows: "Unhandled exception in python.exe (PYTHON24.DLL): 0xC0000005: Access Violation" C:\Python24> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1094960&group_id=5470 From noreply at sourceforge.net Mon Jan 3 15:37:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 15:38:06 2005 Subject: [ python-Bugs-1094960 ] marshal.dumps('hello', 0) "Access violation" Message-ID: Bugs item #1094960, was opened at 2005-01-03 22:09 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1094960&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Brophy (mbrophy) Assigned to: Nobody/Anonymous (nobody) Summary: marshal.dumps('hello',0) "Access violation" Initial Comment: When attempting to generated marshaled data in <2.4 format, I get a crash in python.exe. With a windows XP installation of Python2.4 from "http://www.python.org/ftp/python/2.4/python-2.4.msi" C:\Python24>python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import marshal >>> marshal.dumps('hello',0) Windows popup: """ python.exe has encountered a problem and needs to close. We are sorry for the inconvenience. """ 'Debug' shows: "Unhandled exception in python.exe (PYTHON24.DLL): 0xC0000005: Access Violation" C:\Python24> ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-03 23:37 Message: Logged In: YES user_id=671362 I think this has been fixed in CVS. See: - http://mail.python.org/pipermail/python-dev/2004- December/050481.html - http://mail.python.org/pipermail/python-checkins/2004- December/044312.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1094960&group_id=5470 From noreply at sourceforge.net Mon Jan 3 15:45:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 15:46:16 2005 Subject: [ python-Bugs-1094960 ] marshal.dumps('hello', 0) "Access violation" Message-ID: Bugs item #1094960, was opened at 2005-01-03 08:09 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1094960&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mark Brophy (mbrophy) Assigned to: Nobody/Anonymous (nobody) Summary: marshal.dumps('hello',0) "Access violation" Initial Comment: When attempting to generated marshaled data in <2.4 format, I get a crash in python.exe. With a windows XP installation of Python2.4 from "http://www.python.org/ftp/python/2.4/python-2.4.msi" C:\Python24>python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import marshal >>> marshal.dumps('hello',0) Windows popup: """ python.exe has encountered a problem and needs to close. We are sorry for the inconvenience. """ 'Debug' shows: "Unhandled exception in python.exe (PYTHON24.DLL): 0xC0000005: Access Violation" C:\Python24> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-03 09:45 Message: Logged In: YES user_id=80475 This was reported once already and fixed for Py2.4.1. Thanks. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-03 09:37 Message: Logged In: YES user_id=671362 I think this has been fixed in CVS. See: - http://mail.python.org/pipermail/python-dev/2004- December/050481.html - http://mail.python.org/pipermail/python-checkins/2004- December/044312.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1094960&group_id=5470 From noreply at sourceforge.net Mon Jan 3 20:54:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 20:54:21 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: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Raymond Hettinger (rhettinger) 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-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 Tue Jan 4 00:02:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:02:41 2005 Subject: [ python-Bugs-1095328 ] General FAW - incorrect "most stable version" Message-ID: Bugs item #1095328, was opened at 2005-01-03 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=1095328&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: General FAW - incorrect "most stable version" Initial Comment: http://www.python.org/doc/faq/general.html#how- stable-is-python States that the most stable version is 2.3.3. This should be 2.4.0. Modifying (or checking) this FAQ entry should probably be added to the list of things to be done when a new version is released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:07:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:07:12 2005 Subject: [ python-Bugs-1095328 ] General FAW - incorrect "most stable version" Message-ID: Bugs item #1095328, was opened at 2005-01-03 18:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: A.M. Kuchling (akuchling) Summary: General FAW - incorrect "most stable version" Initial Comment: http://www.python.org/doc/faq/general.html#how- stable-is-python States that the most stable version is 2.3.3. This should be 2.4.0. Modifying (or checking) this FAQ entry should probably be added to the list of things to be done when a new version is released. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-03 18:07 Message: Logged In: YES user_id=80475 Andrew, can you fix this and then assign to Anthony for inclusion on his checklist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:08:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:08:50 2005 Subject: [ python-Bugs-1095328 ] General FAQ - incorrect "most stable version" Message-ID: Bugs item #1095328, was opened at 2005-01-03 23:02 Message generated for change (Settings changed) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: A.M. Kuchling (akuchling) >Summary: General FAQ - incorrect "most stable version" Initial Comment: http://www.python.org/doc/faq/general.html#how- stable-is-python States that the most stable version is 2.3.3. This should be 2.4.0. Modifying (or checking) this FAQ entry should probably be added to the list of things to be done when a new version is released. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-03 23:07 Message: Logged In: YES user_id=80475 Andrew, can you fix this and then assign to Anthony for inclusion on his checklist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095328&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:16:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:16:50 2005 Subject: [ python-Bugs-1095342 ] Python FAQ: list.sort() out of date Message-ID: Bugs item #1095342, was opened at 2005-01-03 23: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=1095342&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Python FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:17:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:17:30 2005 Subject: [ python-Bugs-1095342 ] General FAQ: list.sort() out of date Message-ID: Bugs item #1095342, was opened at 2005-01-03 23:16 Message generated for change (Settings changed) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) >Summary: General FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:21:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:21:52 2005 Subject: [ python-Bugs-1095342 ] General FAQ: list.sort() out of date Message-ID: Bugs item #1095342, was opened at 2005-01-03 23:16 Message generated for change (Comment added) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: General FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... ---------------------------------------------------------------------- >Comment By: Tim Delaney (tcdelaney) Date: 2005-01-03 23:21 Message: Logged In: YES user_id=603121 Do we want to also reference the 2.3 and earlier idiom? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 From noreply at sourceforge.net Tue Jan 4 00:29:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 00:29:57 2005 Subject: [ python-Bugs-1095342 ] General FAQ: list.sort() out of date Message-ID: Bugs item #1095342, was opened at 2005-01-03 18:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: A.M. Kuchling (akuchling) Summary: General FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2005-01-03 18:21 Message: Logged In: YES user_id=603121 Do we want to also reference the 2.3 and earlier idiom? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 From noreply at sourceforge.net Tue Jan 4 01:28:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 01:28:36 2005 Subject: [ python-Bugs-1095342 ] General FAQ: list.sort() out of date Message-ID: Bugs item #1095342, was opened at 2005-01-03 23:16 Message generated for change (Comment added) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: A.M. Kuchling (akuchling) Summary: General FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... ---------------------------------------------------------------------- >Comment By: Tim Delaney (tcdelaney) Date: 2005-01-04 00:28 Message: Logged In: YES user_id=603121 Updated text: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from a passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... Versions of Python prior to 2.4 need to use the following idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2005-01-03 23:21 Message: Logged In: YES user_id=603121 Do we want to also reference the 2.3 and earlier idiom? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 From noreply at sourceforge.net Tue Jan 4 15:53:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 15:53:53 2005 Subject: [ python-Bugs-1095789 ] Bug In Python Message-ID: Bugs item #1095789, was opened at 2005-01-04 14:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: JastheAce (jayse24) Assigned to: Nobody/Anonymous (nobody) Summary: Bug In Python Initial Comment: We are trying to convert a string value of "4.02" into a interger value multipled by 100. Eg: Int(float("4.02")*100) I think this should return 402 but returns 401 If i replace "4.02" with "4.04, it should return 404 and it does Every other number from 4.02 returns an incorrect value. 4.02 4.06 4.10 4.14 etc etc Can someone help this is driving me mad Cheers JastheAce ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095789&group_id=5470 From noreply at sourceforge.net Tue Jan 4 16:02:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:02:26 2005 Subject: [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-01 19:37 Message generated for change (Comment added) made by corvus 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: John Speno (corvus) Date: 2005-01-04 10: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-25 23: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 12: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-02 21:42 Message: Logged In: YES user_id=899035 I'm using Win98SE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 13: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 Jan 4 16:15:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:15:12 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 16: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=1095802&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095802&group_id=5470 From noreply at sourceforge.net Tue Jan 4 16:18:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:18:29 2005 Subject: [ python-Bugs-992185 ] test_macostools fails when running from source Message-ID: Bugs item #992185, was opened at 2004-07-16 10:47 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992185&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_macostools fails when running from source Initial Comment: Test_macos fails when running from source, and possibly only when running from source the first time. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 16:18 Message: Logged In: YES user_id=45365 This was fixed a while ago by someone else (Brett?), by simply not doing this test if sys.prefix doesn't exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992185&group_id=5470 From noreply at sourceforge.net Tue Jan 4 16:27:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:27:44 2005 Subject: [ python-Bugs-1076490 ] Sate/Save typo in Mac/scripts/BuildApplication.py Message-ID: Bugs item #1076490, was opened at 2004-12-01 05:26 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076490&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neil Mayhew (neil_mayhew) Assigned to: Jack Jansen (jackjansen) Summary: Sate/Save typo in Mac/scripts/BuildApplication.py Initial Comment: MacPython-OS9 2.3.3, on Mac OS 9.1 Patch attached ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 16:27 Message: Logged In: YES user_id=45365 Fixed in 1.10.12.1, will be in MacPython 2.3.5 when it is released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076490&group_id=5470 From noreply at sourceforge.net Tue Jan 4 16:40:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:40:44 2005 Subject: [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-01 19:37 Message generated for change (Comment added) made by corvus 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: John Speno (corvus) Date: 2005-01-04 10: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 10: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-25 23: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 12: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-02 21:42 Message: Logged In: YES user_id=899035 I'm using Win98SE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 13: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 Jan 4 16:42:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:42:41 2005 Subject: [ python-Bugs-1095821 ] The doc for DictProxy is missing Message-ID: Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 From noreply at sourceforge.net Tue Jan 4 16:43:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 16:43:05 2005 Subject: [ python-Bugs-1095822 ] Apple-installed Python fails to build extensions Message-ID: Bugs item #1095822, was opened at 2005-01-04 16: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=1095822&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Apple-installed Python fails to build extensions Initial Comment: Apple-installed Python 2.3 (on Mac OS X 10.3) can no longer build extension modules after a newer framework build has been installed. This happens because it will build extensions with "-framework Python", which will actually link against the newer framework (be it 2.3.X or 2.4 or later) that is in /Library in stead of against it's own framework in /System/Library. After over a year of debating multiple solutions the Pythonmac-SIG consensus is that linking extensions with "-undefined dynamic_lookup" in stead of against the framework is the best solution. All of 2.5a0, 2.4.1 and 2.3.5 will detect the fact that they are being run on a machine that has an Apple-installed python that needs to be patched, and apply that patch. A standalone patch installer will also be made available. In addition, 2.5a0, 2.4.1 and 2.3.5 themselves will also use the -undefined dynamic_lookup method of linking when running on 10.3 or later (unless the user has specifically set MACOSX_DEPLOYMENT_TARGET to 10.2 or earlier). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095822&group_id=5470 From noreply at sourceforge.net Tue Jan 4 17:03:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 17:03:52 2005 Subject: [ python-Bugs-963494 ] packman upgrade issue Message-ID: Bugs item #963494, was opened at 2004-05-31 11:39 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: packman upgrade issue Initial Comment: When you upgrade a package using packman the installer doesn't remove the old version before installing the new version. The end result is that old files might interfere with the correct operation of the upgraded package. I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1. Some extension modules have moved between those two releases. When upgrading using PackMan the old extension modules still exists, and cause problems when you try to use the package. Three possible solutions: 1) Remove the existing package directory before installing the upgrade 2) Add pre/post install/upgrade scripts 3) Use a real package database ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 17:03 Message: Logged In: YES user_id=45365 All of these are difficult. But I was just wondering whether we could implement something simple: uninstall packages. For example, a package "PyObjC-uninstall" (normallly hidden) would somehow contain enough info to eradicate any known PyObjC installation. It's "installed" status would be true if PyObjC is *not* installed, false if it is. PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and when the user installed either of these they would first "install" PyObjC- uninstall, which would erase any previous installation. An uninstall package would probably consist of a list of files and dirs that would need to be removed. The package would be flagged as "installed" if any of these exist. There's probably packages that need something more complex (like editing config files or whatever), but I think this scheme would handle most common cases. "installing" an uninstall package, possibly as a result of a dependency, should probably put up a warning dialog first. Does this sound workable? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 15:14 Message: Logged In: YES user_id=45365 I'm moving this to the feature requests category: it requires major surgery, and it could be argued that this functionality belongs more in distutils than in Package Manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 From noreply at sourceforge.net Tue Jan 4 17:34:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 17:34:27 2005 Subject: [ python-Bugs-963494 ] packman upgrade issue Message-ID: Bugs item #963494, was opened at 2004-05-31 11:39 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: packman upgrade issue Initial Comment: When you upgrade a package using packman the installer doesn't remove the old version before installing the new version. The end result is that old files might interfere with the correct operation of the upgraded package. I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1. Some extension modules have moved between those two releases. When upgrading using PackMan the old extension modules still exists, and cause problems when you try to use the package. Three possible solutions: 1) Remove the existing package directory before installing the upgrade 2) Add pre/post install/upgrade scripts 3) Use a real package database ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-01-04 17:34 Message: Logged In: YES user_id=580910 That might work. It does require that packman installs dependencies before installing the package itself. Another problem is smart GUI's. One useful feature for a PackMan GUI would be a listing of missing dependencies (e.g. you've installed _tkinter and somehow didn't install AquaTk, it would be nice if PackMan said that AquaTk is missing). Such a feature would have to know about uninstall packages, otherwise it would complain that 'foo-uninstall' is missing after you've installed 'foo'. Another solution (at least for PyObjC) is making sure that every package uses the 'extra_path' feature of distutils, add that value to the packman database, and remove $extra_path before installing a package. The extra_path key in the database could be optional: only add it when the previous version must be uninstalled before installing a new version. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 17:03 Message: Logged In: YES user_id=45365 All of these are difficult. But I was just wondering whether we could implement something simple: uninstall packages. For example, a package "PyObjC-uninstall" (normallly hidden) would somehow contain enough info to eradicate any known PyObjC installation. It's "installed" status would be true if PyObjC is *not* installed, false if it is. PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and when the user installed either of these they would first "install" PyObjC- uninstall, which would erase any previous installation. An uninstall package would probably consist of a list of files and dirs that would need to be removed. The package would be flagged as "installed" if any of these exist. There's probably packages that need something more complex (like editing config files or whatever), but I think this scheme would handle most common cases. "installing" an uninstall package, possibly as a result of a dependency, should probably put up a warning dialog first. Does this sound workable? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 15:14 Message: Logged In: YES user_id=45365 I'm moving this to the feature requests category: it requires major surgery, and it could be argued that this functionality belongs more in distutils than in Package Manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 From noreply at sourceforge.net Tue Jan 4 20:48:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 20:48:41 2005 Subject: [ python-Bugs-1095789 ] Bug In Python Message-ID: Bugs item #1095789, was opened at 2005-01-04 09:53 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: JastheAce (jayse24) Assigned to: Nobody/Anonymous (nobody) Summary: Bug In Python Initial Comment: We are trying to convert a string value of "4.02" into a interger value multipled by 100. Eg: Int(float("4.02")*100) I think this should return 402 but returns 401 If i replace "4.02" with "4.04, it should return 404 and it does Every other number from 4.02 returns an incorrect value. 4.02 4.06 4.10 4.14 etc etc Can someone help this is driving me mad Cheers JastheAce ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-04 14:48 Message: Logged In: YES user_id=80475 This is just one of the many joys of floating point arithmetic. See Appendix B in the tutorial for a hint about what is going on. To get the results you want, run round(x,0) before applying int(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095789&group_id=5470 From noreply at sourceforge.net Tue Jan 4 21:48:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 21:48:30 2005 Subject: [ python-Bugs-963494 ] packman upgrade issue Message-ID: Bugs item #963494, was opened at 2004-05-31 11:39 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: packman upgrade issue Initial Comment: When you upgrade a package using packman the installer doesn't remove the old version before installing the new version. The end result is that old files might interfere with the correct operation of the upgraded package. I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1. Some extension modules have moved between those two releases. When upgrading using PackMan the old extension modules still exists, and cause problems when you try to use the package. Three possible solutions: 1) Remove the existing package directory before installing the upgrade 2) Add pre/post install/upgrade scripts 3) Use a real package database ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 21:48 Message: Logged In: YES user_id=45365 I don't like the extra_path idea: it's meant for something else really. I think I'll just go for it and try the uninstaller trick. Don't know whether I'll have it in place before additions build 3, though, we'll see. As to the other issue (missing dependencies and such): I want to solve that differently, eventually. Currently there's only one test (installed) per package that's supposed to be as cheap as possible. I want to have at least one more (consistency) and maybe even two (consistency and full selfcheck). But that'll have to wait. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-01-04 17:34 Message: Logged In: YES user_id=580910 That might work. It does require that packman installs dependencies before installing the package itself. Another problem is smart GUI's. One useful feature for a PackMan GUI would be a listing of missing dependencies (e.g. you've installed _tkinter and somehow didn't install AquaTk, it would be nice if PackMan said that AquaTk is missing). Such a feature would have to know about uninstall packages, otherwise it would complain that 'foo-uninstall' is missing after you've installed 'foo'. Another solution (at least for PyObjC) is making sure that every package uses the 'extra_path' feature of distutils, add that value to the packman database, and remove $extra_path before installing a package. The extra_path key in the database could be optional: only add it when the previous version must be uninstalled before installing a new version. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-01-04 17:03 Message: Logged In: YES user_id=45365 All of these are difficult. But I was just wondering whether we could implement something simple: uninstall packages. For example, a package "PyObjC-uninstall" (normallly hidden) would somehow contain enough info to eradicate any known PyObjC installation. It's "installed" status would be true if PyObjC is *not* installed, false if it is. PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and when the user installed either of these they would first "install" PyObjC- uninstall, which would erase any previous installation. An uninstall package would probably consist of a list of files and dirs that would need to be removed. The package would be flagged as "installed" if any of these exist. There's probably packages that need something more complex (like editing config files or whatever), but I think this scheme would handle most common cases. "installing" an uninstall package, possibly as a result of a dependency, should probably put up a warning dialog first. Does this sound workable? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 15:14 Message: Logged In: YES user_id=45365 I'm moving this to the feature requests category: it requires major surgery, and it could be argued that this functionality belongs more in distutils than in Package Manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470 From noreply at sourceforge.net Wed Jan 5 06:26:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 06:26:59 2005 Subject: [ python-Bugs-1096244 ] time.tzset() not built on Solaris Message-ID: Bugs item #1096244, was opened at 2005-01-05 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=1096244&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory Bond (gnbond) Assigned to: Nobody/Anonymous (nobody) Summary: time.tzset() not built on Solaris Initial Comment: The time.tzset() function is not included in Solaris builds, because the code in configure.in that checks for the existence of tzset() relies on struct tm having a tm_zone member - which Solaris does not have (at least not up to 2.8). The attached patch to configure.in allows Solaris to detect the existence of tzset() and Python builds OK, and the resulting time.tzset() function seems to work just fine. diff -u configure.in.DIST configure.in --- configure.in.DIST 2005-01-05 16:25:24.830001000 +1100 +++ configure.in 2005-01-05 16:25:38.227000000 +1100 @@ -2912,10 +2912,6 @@ tzset(); if (localtime(&groundhogday)->tm_hour != 11) exit(1); - if (strcmp(localtime(&groundhogday)->tm_zone, "AEDT")) - exit(1); - if (strcmp(localtime(&midyear)->tm_zone, "AEST")) - exit(1); exit(0); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1096244&group_id=5470 From noreply at sourceforge.net Wed Jan 5 10:18:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 10:19:00 2005 Subject: [ python-Bugs-1096310 ] sys.__stdout__ doco isn't discouraging enough Message-ID: Bugs item #1096310, was opened at 2005-01-05 10: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=1096310&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: sys.__stdout__ doco isn't discouraging enough Initial Comment: sys.__stdout__ is quite often abused (two independent sightings on c.l.py yesterday): people use it to restore stdout instead of saving the previous stdout. The real intended use for __stdout__ isn't all that clear (I keep wondering myself why it's there in the first place; its use case must be quite obscure), but more importantly I think the sys docs should contain a warning that __stdout__ is *not* suitable to restore sys.stdout after redirection. I'd produce a patch if I knew how to better describe what sys.__stdout__ was *for*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1096310&group_id=5470 From noreply at sourceforge.net Wed Jan 5 11:29:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 11:30:03 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 15:37 Message generated for change (Comment added) made by saravanand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: saravanand (saravanand) Date: 2005-01-05 15:59 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-24 08:05 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Wed Jan 5 11:54:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 11:54:18 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 15:37 Message generated for change (Comment added) made by saravanand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: saravanand (saravanand) Date: 2005-01-05 16:24 Message: Logged In: YES user_id=1181691 I tried the following workaround which is working (causes no handle leaks) Workaround is to change threading.semaphore to Windows Extension module APIs win32event.CreateMutex(), win32event.WaitForSingleObject and win32event.ReleaseMutex () After this change, there are no handle leaks. So, my questions are: 1) Is this workaround OK or are there any other issues regarding the win32api usage ? 2) you suggested to create minimal python wrappers for C++ code and call C++ from python (instead of C++ thread callbacks). So I would like to know, in general, whether it is a bad idea for c++ threads to callback into Python. If yes, what are the issues (apart from the handle leak mentioned before). If no, I would like to live with the above workaround. Thanks in advance ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 15:59 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-24 08:05 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Wed Jan 5 14:19:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 14:19:17 2005 Subject: [ python-Feature Requests-1073198 ] Extension to optparse: options with facultative value Message-ID: Feature Requests item #1073198, was opened at 2004-11-25 09:18 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: pollastri (pollastri) Assigned to: Greg Ward (gward) Summary: Extension to optparse: options with facultative value Initial Comment: When parsing command line options, I found very useful to have an option with a facultative value, able to do the following: 1-tell to me if the option was or was not seen on the command line, return the value None if the option was not seen; 2-if the option only was specified, return a default value. 3-if the option with a value was specified on the command line, return the specified value; A way to reach this goal can be the addition of a new value for the options actions in module optparse, it may be something like "store_with_default". ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-01-05 08:19 Message: Logged In: YES user_id=14422 I don't know what "facultative" means, but what you want is optional option arguments. Don't worry, I want that feature too, and have even started implementing it on a branch of the Optik source repository. See http://sourceforge.net/tracker/?func=detail&aid=1050431&group_id=38019&atid=421100 for a similar feature request. I'm leaving this open, since I haven't finished anything or merged it into the Python CVS. It could be a few months before there's any action here, and it certainly won't happen before Optik 1.6 / Python 2.5. Might require Optik 2.0, in which case I'm not certain when it'll get into Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 From noreply at sourceforge.net Wed Jan 5 14:20:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 14:20:55 2005 Subject: [ python-Feature Requests-1089955 ] optparse .error() should print options list Message-ID: Feature Requests item #1089955, was opened at 2004-12-22 13:53 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1089955&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Greg Ward (gward) Summary: optparse .error() should print options list Initial Comment: Why doesn't optparse.OptionParser.error() print the list of correct options along with the error message and usage? This is what the user needs to know whenever there's an error. One can override this in a subclass, but it's frustrating to have to do it every time. To do this, change the first line in OptionParser.error() from: self.print_usage(sys.stderr) to: self.print_help(sys.stderr) print >>sys.stderr ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-01-05 08:20 Message: Logged In: YES user_id=14422 Because very few conventional Unix programs act this way: $ -z ls: invalid option -- z Try `ls --help' for more information. $ tar -a tar: invalid option -- a Try `tar --help' for more information. $ cp -z cp: invalid option -- z Try `cp --help' for more information. Note the pattern. (Hmmm: perhaps Optik should throw in a "try --help" if there's a help option in the current parser.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1089955&group_id=5470 From noreply at sourceforge.net Wed Jan 5 15:46:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 15:46:26 2005 Subject: [ python-Bugs-1071597 ] configure problem on HP-UX 11.11 Message-ID: Bugs item #1071597, was opened at 2004-11-23 10:30 Message generated for change (Comment added) made by harripasanen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem on HP-UX 11.11 Initial Comment: Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ Using gcc 3.3.3 to build on HP-UX 11.11, the configure out of the box is a bit off, resulting in a failed build, due to missing thread symbols: /usr/ccs/bin/ld: Unsatisfied symbols: PyThread_acquire_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_exit_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_allocate_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_free_lock (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_start_new_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_release_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_get_thread_ident (first referenced in libpython2.4.a(import.o)) (code) PyThread__init_thread (first referenced in libpython2.4.a(thread.o)) (code) collect2: ld returned 1 exit status A workaround is to manually edit pyconfig.h, adding #define _POSIX_THREADS (The reason it is not picked up is that unistd.h on HP-UX has this comment: /************************************************************************ * The following defines are specified in the standard, but are not yet * implemented: * * _POSIX_THREADS can't be defined until all * features are implemented ) The implementation seems however to be sufficiently complete to permit compiling and running Python with _POSIX_THREADS. While I'm editing pyconfig.h, I also comment out _POSIX_C_SOURCE definition, as it will result in lots of compilation warnings, of the style: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Python-2.4c1/Include -DPy_BUILD_CORE -o Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c In file included from ../Python-2.4c1/Include/Python.h:8, from ../Python-2.4c1/Objects/frameobject.c:4: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition ------------ So, to recapitulate: After configure, add #define _POSIX_THREADS and comment out #define _POSIX_C_SOURCE 200112L That will give you a Python working rather well, with "make test" producing: 251 tests OK. 1 test failed: test_pty 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on hp-ux11: test_tcl ---------------------------------------------------------------------- >Comment By: Harri Pasanen (harripasanen) Date: 2005-01-05 14:46 Message: Logged In: YES user_id=77088 _POSIX_C_SOURCE appears to come from the gcc driver, along with a few other macros. If I add "-v" to compilation, the output expands to: Reading specs from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/specs Configured with: /scratch/zack/pkgbuild/3.3.1/hpux-11/gcc-3.3.3/configure --enable-languages=c,c++ --enable-threads=posix --disable-nls --with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as --prefix=/usr/local Thread model: posix gcc version 3.3.3 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/cc1 -quiet -v -I. -I./Include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 -D_REENTRANT -D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L -DNDEBUG -DPy_BUILD_CORE Modules/python.c -quiet -dumpbase python.c -auxbase-strip Modules/python.o -g -O3 -Wall -Wstrict-prototypes -version -fno-strict-aliasing -o /var/tmp//ccLnAhZ0.s GNU C version 3.3.3 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 3.3.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/hppa2.0w-hp-hpux11.11/include" #include "..." search starts here: #include <...> search starts here: . Include /usr/local/include /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/include /usr/include End of search list. In file included from Include/Python.h:8, from Modules/python.c:3: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition /usr/local/bin/as --traditional-format -o Modules/python.o /var/tmp//ccLnAhZ0.s ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-23 23:50 Message: Logged In: YES user_id=21627 Can you find out why gcc says that "_POSIX_C_SOURCE" is defined on the command line? On the command line you provide, it isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 From noreply at sourceforge.net Thu Jan 6 08:19:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 08:19:17 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 02:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:19 Message: Logged In: YES user_id=357491 What does Semaphore have to do with _DummyThread and currentThread? And as for win32api, that is not part of the Python stdlib and thus I have no way of commenting on that. For C++ threads to call into Python code, I would not say that is bad specifically. You were just trying to get thread info for non-Python threads and that was leading to _DummyThread instances to be created as designed and you just didn't want that. Calling Python code is fine, just don't expect it to know about your C++ threads as much as you seem to want it to. And please leave this bug closed. If free to submit a patch to change semantics, but that does not affect this bug report. ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 02:54 Message: Logged In: YES user_id=1181691 I tried the following workaround which is working (causes no handle leaks) Workaround is to change threading.semaphore to Windows Extension module APIs win32event.CreateMutex(), win32event.WaitForSingleObject and win32event.ReleaseMutex () After this change, there are no handle leaks. So, my questions are: 1) Is this workaround OK or are there any other issues regarding the win32api usage ? 2) you suggested to create minimal python wrappers for C++ code and call C++ from python (instead of C++ thread callbacks). So I would like to know, in general, whether it is a bad idea for c++ threads to callback into Python. If yes, what are the issues (apart from the handle leak mentioned before). If no, I would like to live with the above workaround. Thanks in advance ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 02:29 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-23 18:35 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Thu Jan 6 08:21:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 08:21:23 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: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) 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-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 Thu Jan 6 10:59:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 10:59:36 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 16:14 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095802&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) 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: Jack Jansen (jackjansen) Date: 2005-01-06 10: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-06 08: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 Thu Jan 6 12:01:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 12:01:29 2005 Subject: [ python-Bugs-1071597 ] configure problem on HP-UX 11.11 Message-ID: Bugs item #1071597, was opened at 2004-11-23 10:30 Message generated for change (Comment added) made by harripasanen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem on HP-UX 11.11 Initial Comment: Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ Using gcc 3.3.3 to build on HP-UX 11.11, the configure out of the box is a bit off, resulting in a failed build, due to missing thread symbols: /usr/ccs/bin/ld: Unsatisfied symbols: PyThread_acquire_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_exit_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_allocate_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_free_lock (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_start_new_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_release_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_get_thread_ident (first referenced in libpython2.4.a(import.o)) (code) PyThread__init_thread (first referenced in libpython2.4.a(thread.o)) (code) collect2: ld returned 1 exit status A workaround is to manually edit pyconfig.h, adding #define _POSIX_THREADS (The reason it is not picked up is that unistd.h on HP-UX has this comment: /************************************************************************ * The following defines are specified in the standard, but are not yet * implemented: * * _POSIX_THREADS can't be defined until all * features are implemented ) The implementation seems however to be sufficiently complete to permit compiling and running Python with _POSIX_THREADS. While I'm editing pyconfig.h, I also comment out _POSIX_C_SOURCE definition, as it will result in lots of compilation warnings, of the style: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Python-2.4c1/Include -DPy_BUILD_CORE -o Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c In file included from ../Python-2.4c1/Include/Python.h:8, from ../Python-2.4c1/Objects/frameobject.c:4: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition ------------ So, to recapitulate: After configure, add #define _POSIX_THREADS and comment out #define _POSIX_C_SOURCE 200112L That will give you a Python working rather well, with "make test" producing: 251 tests OK. 1 test failed: test_pty 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on hp-ux11: test_tcl ---------------------------------------------------------------------- >Comment By: Harri Pasanen (harripasanen) Date: 2005-01-06 11:01 Message: Logged In: YES user_id=77088 Note that the _POSIX_C_SOURCE is also defined for gcc 3.4.3 on HP-UX 11.23 (Itanium). I don't know if it defined for all the gcc platforms, as it would only show up if the definition in pyconfig.h is different from what the gcc driver uses. ---------------------------------------------------------------------- Comment By: Harri Pasanen (harripasanen) Date: 2005-01-05 14:46 Message: Logged In: YES user_id=77088 _POSIX_C_SOURCE appears to come from the gcc driver, along with a few other macros. If I add "-v" to compilation, the output expands to: Reading specs from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/specs Configured with: /scratch/zack/pkgbuild/3.3.1/hpux-11/gcc-3.3.3/configure --enable-languages=c,c++ --enable-threads=posix --disable-nls --with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as --prefix=/usr/local Thread model: posix gcc version 3.3.3 /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/cc1 -quiet -v -I. -I./Include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 -D_REENTRANT -D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L -DNDEBUG -DPy_BUILD_CORE Modules/python.c -quiet -dumpbase python.c -auxbase-strip Modules/python.o -g -O3 -Wall -Wstrict-prototypes -version -fno-strict-aliasing -o /var/tmp//ccLnAhZ0.s GNU C version 3.3.3 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 3.3.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/hppa2.0w-hp-hpux11.11/include" #include "..." search starts here: #include <...> search starts here: . Include /usr/local/include /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.3/include /usr/include End of search list. In file included from Include/Python.h:8, from Modules/python.c:3: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition /usr/local/bin/as --traditional-format -o Modules/python.o /var/tmp//ccLnAhZ0.s ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-23 23:50 Message: Logged In: YES user_id=21627 Can you find out why gcc says that "_POSIX_C_SOURCE" is defined on the command line? On the command line you provide, it isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 From noreply at sourceforge.net Thu Jan 6 15:39:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 15:39:24 2005 Subject: [ python-Bugs-1097229 ] Example needed in os.stat() Message-ID: Bugs item #1097229, was opened at 2005-01-06 11:39 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=1097229&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Example needed in os.stat() Initial Comment: As the repr() of an os.stat() object is *exactly* equal to a tuple, it's not clear at first in the documentation how to use its attributes: >>> import os >>> statinfo = os.stat('somefile.txt') >>> statinfo (33188, 422511L, 769L, 1, 1032, 100, 926L, 1105022698, 1105022732, 1105022732) >>> statinfo.st_size 926L >>> So I propose to put this example in the stat docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097229&group_id=5470 From noreply at sourceforge.net Thu Jan 6 18:16:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 18:16:22 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 05:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-06 12:16 Message: Logged In: YES user_id=31435 Presumably, by changing threading.Semaphore to stop using any code from threading.py, then threading.currentThread() never gets called and so a _DummyThread is never created then. I expect the reason a _DummyThread causes Event leaks is just that Thread.__init__ always ends up allocating a Python lock (Thread.__block), which allocates a Windows Event under the covers. It *could* be that Thread.__block is never actually used for dummy threads, in which case we could avoid allocating it in that case (or could get rid of it right way in _DummyThread.__init__). The dummy thread would still clog the _active dict, but wouldn't leak Events then. It's certainly true that Python has no way to know when a thread it didn't start goes away. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 02:19 Message: Logged In: YES user_id=357491 What does Semaphore have to do with _DummyThread and currentThread? And as for win32api, that is not part of the Python stdlib and thus I have no way of commenting on that. For C++ threads to call into Python code, I would not say that is bad specifically. You were just trying to get thread info for non-Python threads and that was leading to _DummyThread instances to be created as designed and you just didn't want that. Calling Python code is fine, just don't expect it to know about your C++ threads as much as you seem to want it to. And please leave this bug closed. If free to submit a patch to change semantics, but that does not affect this bug report. ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 05:54 Message: Logged In: YES user_id=1181691 I tried the following workaround which is working (causes no handle leaks) Workaround is to change threading.semaphore to Windows Extension module APIs win32event.CreateMutex(), win32event.WaitForSingleObject and win32event.ReleaseMutex () After this change, there are no handle leaks. So, my questions are: 1) Is this workaround OK or are there any other issues regarding the win32api usage ? 2) you suggested to create minimal python wrappers for C++ code and call C++ from python (instead of C++ thread callbacks). So I would like to know, in general, whether it is a bad idea for c++ threads to callback into Python. If yes, what are the issues (apart from the handle leak mentioned before). If no, I would like to live with the above workaround. Thanks in advance ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 05:29 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-23 21:35 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Thu Jan 6 21:13:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 21:14:02 2005 Subject: [ python-Bugs-1097229 ] Example needed in os.stat() Message-ID: Bugs item #1097229, was opened at 2005-01-06 15:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097229&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) >Assigned to: Facundo Batista (facundobatista) Summary: Example needed in os.stat() Initial Comment: As the repr() of an os.stat() object is *exactly* equal to a tuple, it's not clear at first in the documentation how to use its attributes: >>> import os >>> statinfo = os.stat('somefile.txt') >>> statinfo (33188, 422511L, 769L, 1, 1032, 100, 926L, 1105022698, 1105022732, 1105022732) >>> statinfo.st_size 926L >>> So I propose to put this example in the stat docs. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-06 21:13 Message: Logged In: YES user_id=21627 Sure, go ahead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097229&group_id=5470 From noreply at sourceforge.net Thu Jan 6 21:28:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 21:28:17 2005 Subject: [ python-Bugs-1085069 ] gethostbyaddr on redhat for multiple hostnames Message-ID: Bugs item #1085069, was opened at 2004-12-14 13:02 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085069&group_id=5470 Category: None >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dave Kirby (davekirby) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr on redhat for multiple hostnames Initial Comment: When running socket.gethostbyaddr against a host with multiple hostnames assigned to it, the behaviour does not work as advertised under Red Hat linux (tested with Fedora Core 2 and Red Hat 8 - other versions of Linux have not been tested). calling socket.gethostbyaddr from Windows or Mac OS X against a test machine set up with multiple hosts gives the correct result: >>> socket.gethostbyaddr('1.2.3.4') ('testhost2', ['testhost7', 'testhost', 'testhost1', 'testhost3', 'testhost4', 'testhost6', 'testhost5'], ['1.2.3.4']) >>> (The real IP address and hostnames have been changed for security). running the same thing from Linux only gives a single hostname, and the alias list is empty. Repeated calls to the same function cycles through the hostnames (or picks them at random): >>> socket.gethostbyaddr('1.2.3.4') ('testhost', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost1', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost3', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost4', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost6', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost5', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost2', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost7', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost', [], ['1.2.3.4']) This behaviour has been seen with Python 2.2.1, 2.3.3 and 2.4-RC2. This is probably a bug in the underlying C function. According to the Linux man page, the POSIX gethostbyaddr has been superceded by getipnodebyaddr. This behaviour should at least be documented, and if possible fixed by using the new function. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-06 21:28 Message: Logged In: YES user_id=21627 This is indeed likely a bug in the underlying C library (or a misconfiguration of the system, see /etc/hosts). As Python exposes the function more-or-less as-is, I'm closing this as a third-party bug. It is true that gethostbyaddr was superceded by getipnodebyaddr at some point. Meanwhile, this, in turn, was superceded by getaddrinfo/getnameinfo, which Python exposes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085069&group_id=5470 From noreply at sourceforge.net Thu Jan 6 21:31:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 21:31:31 2005 Subject: [ python-Bugs-1082874 ] Unable to see Python binary Message-ID: Bugs item #1082874, was opened at 2004-12-10 13:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Prabal Rakshit (prabal_rakshit) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Python binary Initial Comment: After extracting the Python-2.3.3.tar we could get the appropriate folder structure. We then executed the configure script. Therafter when we execute the make command the Python binary is not created in /usr/local/bin. Any pointers?? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-06 21:31 Message: Logged In: YES user_id=21627 Most likely, "make install" was missing. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2004-12-13 16:45 Message: Logged In: YES user_id=11365 Are you running "make install" after "make" ? You could try explicitly giving an installation prefix: ./configure --prefix=/usr/local Otherwise you can look for newly created files like this: find /usr -mmin -5 Hope this helps. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2004-12-10 22:19 Message: Logged In: YES user_id=49843 The 'make install' target will copy the built binary to '/usr/local/bin'. Did you try 'make install' yet? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 From noreply at sourceforge.net Thu Jan 6 21:35:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 6 21:35:41 2005 Subject: [ python-Bugs-1078245 ] Python2.4: building '_socket' extension fails with `INET_ADD Message-ID: Bugs item #1078245, was opened at 2004-12-03 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.4: building '_socket' extension fails with `INET_ADD Initial Comment: HI! I'm trying to build Python2.4 on a rather old Debian machine. Building _socket fails (see below) although I tried to use configure --disable-ipv6 I've added #define INET_ADDRSTRLEN 16 to Modules/socketmodule.h which made it work. There were no problems compiling Python2.2 on the very same machine. Ciao, Michael. ------------------------------ snip ------------------------------ building '_socket' extension gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/tmp/Python-2.4/./Include -I/user/W3311/local/include -I/usr/local/include -I/tmp/Python-2.4/Include -I/tmp/Python-2.4 -c /tmp/Python-2.4/Modules/socketmodule.c -o build/t emp.linux-i686-2.4/socketmodule.o /tmp/Python-2.4/Modules/socketmodule.c: In function `socket_inet_ntop': /tmp/Python-2.4/Modules/socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use this function) /tmp/Python-2.4/Modules/socketmodule.c:3350: (Each undeclared identifier is reported only once /tmp/Python-2.4/Modules/socketmodule.c:3350: for each function it appears in.) /tmp/Python-2.4/Modules/socketmodule.c:3350: size of array `ip' has non-integer type ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-06 21:35 Message: Logged In: YES user_id=21627 There are already a few attempts to define ADDRSTRLEN if it is missing. Maybe we should just merge them into one, and define it if it is not defined, independent of the system. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-13 14:19 Message: Logged In: YES user_id=29957 How old a debian release is this? It sounds like it's a just a broken system header, and I'm not entirely convinced that adding this to the already-large collection of #ifdefs in socketmodule is a path to happiness. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470 From noreply at sourceforge.net Fri Jan 7 01:45:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 01:45:33 2005 Subject: [ python-Bugs-1083177 ] Change in signal function in the signal module Message-ID: Bugs item #1083177, was opened at 2004-12-10 15:58 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) >Assigned to: A.M. Kuchling (akuchling) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-13 08:16 Message: Logged In: YES user_id=29957 This is a deliberate change - "errors should not pass silently". I agree that it should get better visibility. Perhaps an entry in amk's what's new document in the section on Porting to 2.4 would be appropriate. AMK? (I've added a comment to the document as a reminder) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:32 Message: Logged In: YES user_id=80475 On WinME, I appropriately get an AttributeError consistently for Py2.2, Py2.3, and Py2.4. Anthony, you've made the most recent updates to the signalmodule. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 From noreply at sourceforge.net Fri Jan 7 01:51:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 01:51:40 2005 Subject: [ python-Bugs-1091740 ] garbage collector still documented as optional Message-ID: Bugs item #1091740, was opened at 2004-12-27 10:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091740&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: garbage collector still documented as optional Initial Comment: Section 3.2 of the library reference, first paragraph, says "The gc module is only available if the interpreter was built with the optional cyclic garbage detector" However according to Misc/NEWS, "Compiling out the cyclic garbage collector is no longer an option" as of Python 2.3 alpha 1. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 19:51 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091740&group_id=5470 From noreply at sourceforge.net Fri Jan 7 01:54:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 01:54:50 2005 Subject: [ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the terminal mode. Message-ID: Bugs item #1088077, was opened at 2004-12-19 16:24 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470 Category: Python Library >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] tty needs a way to restore the terminal mode. Initial Comment: tty provides a nice, simple interface for setting the terminal to raw or cbreak modes. However, it doesn't provide a way to put the terminal back in the mode it was in before that change. Every responsible application should leave the terminal in the mode it found it in - unless the application is called sttty, of course. tty needs a "setsane" function. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2004-12-19 16:28 Message: Logged In: YES user_id=93910 The patch to add the setsane method is in patch #1088078. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:04:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:05:03 2005 Subject: [ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs Message-ID: Bugs item #1093389, was opened at 2004-12-30 13:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joe Hildebrand (hildjj) >Assigned to: Mark Hammond (mhammond) Summary: mapitags.PROP_TAG() doesn't account for new longs Initial Comment: Test case: >>> from win32com.mapi.mapitags import * >>> PROP_TAG(PT_LONG, 0x8041) 2151743491L Should be: -2143223805L or, alternately, the rest of the mapi interfaces should know about unsigned ints. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:13:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:13:39 2005 Subject: [ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html Message-ID: Bugs item #1071094, was opened at 2004-11-22 11:15 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marc-Antoine Parent (maparent) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some latex reject the pdfinfo macro while generating html Initial Comment: I was building the documentation on OSX. I use the latest LaTeX 2004 from Wierda's teTeX. There is a pdfinfo command in Doc/ texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my version of latex. edited log follows: TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python -2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat -- iconserver ../icons --favicon ../icons/pyfav.png --address "See About this document... for information on suggesting changes." --up-link ../index.html --up- title "Python Documentation Index" --global-module-index "../ modindex.html" --dvips-safe --dir html/api api/api.tex +++ TEXINPUTS=/.../Python-2.4c1/ Doc/api:/.../Python-2.4c1/Doc/ commontex:/.../Python-2.4c1/Doc/ paper-letter:/.../Python-2.4c1/Doc/ texinputs: +++ latex api *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. The relevant lines from the transcript are: ------------------------------------------------------------------------ +++ latex api This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3) output format initialized to DVI entering extended mode (/.../Python-2.4c1/Doc/api/api.tex LaTeX2e <2003/12/01> Babel and hyphenation patterns for american, french, german, ngerman, nohyphenation, loaded. (/.../Python-2.4c1/Doc/texinputs/manual.cls Document Class: manual 1998/03/03 Document class (Python manual) (/.../Python-2.4c1/Doc/texinputs/pypaper.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty) Using Times instead of Computer Modern. ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/ fancybox.sty Style option: `fancybox' v1.3 <2000/09/19> (tvz) ) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls Document Class: report 2004/02/16 v1.4f Standard LaTeX document class (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo)) (/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty) Using fancier footers than usual. (/.../Python-2.4c1/Doc/texinputs/fncychap.sty) Using fancy chapter headings. (/.../Python-2.4c1/Doc/texinputs/python.sty (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty))) (/.../Python-2.4c1/Doc/commontex/boilerplate.tex (/.../Python-2.4c1/Doc/commontex/patchlevel.tex)) Writing index file api.idx No file api.aux. (/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd) pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. { \def \{, } \pdfinfo { /Author (\@author ) /Title (\@title ) } } l.12 \maketitle No pages of output. Transcript written on api.log. *** Session transcript and error messages are in /.../Python -2.4c1/Doc/html/api/api.how. *** Exited with status 1. make: *** [html/api/api.html] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:15:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:16:05 2005 Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth Message-ID: Bugs item #1016563, was opened at 2004-08-26 02:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Christoph Mussenbrock (mussenbrock) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 bug in proxy auth Initial Comment: in urllib2.py: line 502 should be: ... user_pass = base64.encodestring('%s:%s' % (unquote (user), unquote(password))).strip() the '.strip()' is missing in the current version ("2.1"). this makes an additonal '\n' at the end of user_pass. So there will be an empty line in the http header, which is buggy. (see also line 645, where the .strip() is right in place!). Best regards, Christoph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:19:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:19:51 2005 Subject: [ python-Bugs-989337 ] test_descr fails on win2k Message-ID: Bugs item #989337, was opened at 2004-07-12 06:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_descr fails on win2k Initial Comment: >>> from test import test_descr >>> test_descr.verbose = 1 >>> test_descr.test_main() Testing weakref segfault... Testing SF bug 551412 ... Testing SF bug 570483... Testing list operations... checking a+b checking b in a checking b in a checking a[b] checking a[b:c] checking a+=b checking a*=b checking len(a) checking a*b checking b*a checking a[b]=c checking a[b:c]=d Testing dict operations... checking cmp(a,b) checking b in a checking b in a checking a[b] checking len(a) checking a[b]=c Testing dict constructor ... Testing dir() ... Testing int operations... checking a & b checking a ^ b checking a >> b checking a - b checking a ** b checking a + b checking divmod(a, b) checking a << b checking a * b checking a / b checking cmp(a, b) checking a | b checking a % b checking int(a) checking - a checking ~ a checking float(a) checking hex(a) checking + a checking long(a) checking abs(a) checking oct(a) Testing long operations... checking a & b checking a ^ b checking a >> b checking a - b checking a ** b checking a + b checking divmod(a, b) checking a << b checking a * b checking a / b checking cmp(a, b) checking a | b checking a % b checking int(a) checking - a checking ~ a checking float(a) checking hex(a) checking + a checking long(a) checking abs(a) checking oct(a) Testing float operations... checking a >= b checking a - b checking a > b checking a ** b checking a < b checking a != b checking a + b checking a <= b checking divmod(a, b) checking a * b checking a / b checking a == b checking a % b checking int(a) checking - a checking float(a) checking + a checking long(a) checking abs(a) Testing complex operations... checking a - b checking a ** b checking a != b checking a + b checking divmod(a, b) checking a * b checking a / b checking a == b checking a % b checking - a checking + a checking abs(a) Testing spamlist operations... checking a+b checking b in a checking b in a checking a[b] checking a[b:c] checking a+=b checking a*=b checking len(a) checking a*b checking b*a checking a[b]=c checking a[b:c]=d Testing spamdict operations... checking cmp(a,b) checking b in a checking b in a checking a[b] checking len(a) checking repr(a) checking a[b]=c Testing Python subclass of dict... pydict stress test ... Testing Python subclass of list... Testing __metaclass__... Testing Python subclass of module... Testing multiple inheritance... Testing error messages for MRO disagreement... Testing multiple inheritance special cases... Testing ex5 from C3 switch discussion... Testing MRO monotonicity... Testing consistentcy with EPG... Testing object class... Testing __slots__... Testing __dict__ and __weakref__ in __slots__... Testing class attribute propagation... Testing errors... Testing class methods... Testing C-based class methods... Testing static methods... Testing C-based static methods... Testing classic classes... Testing computed attributes... Testing __new__ slot override... Testing mro() and overriding it... Testing operator overloading... Testing methods... Testing special operators... Traceback (most recent call last): File "", line 1, in -toplevel- test_descr.test_main() File "C:\apps\Python24\lib\test\test_descr.py", line 4024, in test_main specials() File "C:\apps\Python24\lib\test\test_descr.py", line 1875, in specials print Letter('w') PicklingError: Can't pickle : attribute lookup test.test_descr.Letter failed >>> This is Python 2.4a1 on win2k pro ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 20:19 Message: Logged In: YES user_id=80475 Do you still have a problem with this in Py2.4 final ? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-10-17 11:00 Message: Logged In: YES user_id=358087 Still here in Python-2.4b1 ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-19 00:09 Message: Logged In: YES user_id=358087 Sorry, forgot that I've upgraded to winXP the other day. This *is* winXP pro SP1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-18 14:46 Message: Logged In: YES user_id=80475 I cannot reproduce this on either WinME or WinXP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:25:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:25:36 2005 Subject: [ python-Bugs-991708 ] test_imp failure Message-ID: Bugs item #991708, was opened at 2004-07-15 11:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991708&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: test_imp failure Initial Comment: With threads disabled under fedore core 1 uname -r 2.4.22-1.2188.nptlsmp ./python -E -tt ./Lib/test/regrtest.py -vv test_imp test_imp test test_imp failed -- expected imp.lock_held() to be True 1 test failed: test_imp Looks shallow. :) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 20:25 Message: Logged In: YES user_id=80475 This was fixed by Brett on 12/4/04. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991708&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:27:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:27:11 2005 Subject: [ python-Bugs-971238 ] test_timeout failure on trunk Message-ID: Bugs item #971238, was opened at 2004-06-11 11:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971238&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout failure on trunk Initial Comment: On current-CVS trunk, Fedora Core 2: testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (13.3079) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 36.437s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (13.3079) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 20:27 Message: Logged In: YES user_id=80475 Anthony, is this still a valid report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971238&group_id=5470 From noreply at sourceforge.net Fri Jan 7 02:37:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 02:37:24 2005 Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 07:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stuart Bishop (zenzen) Assigned to: A.M. Kuchling (akuchling) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 20:37 Message: Logged In: YES user_id=80475 Andrew, are you still working on this one? ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-18 18:43 Message: Logged In: YES user_id=1000470 The file pointer (fp) is None (inside urllib) from httplib. This appears to be caused by a BadStatusLine exception in getreply() (line1016 httplib). This sets self.file to self._conn.sock.makefile('rb', 0) then does a self.close() which sets self.file to None. Being new to this peice of code, I'm not sure whether it's urllib assuming the file isn't going to be closed, or the BadStatusLine exception clearing the file. Certainly it looks like the error -1 is not being trapped by open_http() in urllib upon calling h.getreply() and assuming that the file still exists even in an error condition? It maybe a coincidence but it appears to occur more when a web browser on the same machine is refreshing. Regards Rob ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-17 17:24 Message: Logged In: YES user_id=1000470 """ This comment is program to reproduce the problem. Sorry it's not an attachment - as a relative Sourceforge newbie I have no idea how to attach to an existing bug. More notes available via email if required - including all local variables for each function from post mortem. As said before, seems to be fp = None. Although the exception is caused by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside open_http() This is repeatable, but you may have to run this more than once. (Apologies to noaa.gov). *** PLEASE: Run only where absolutely necessary for reproduction of bug!!! *** """ """ Attribute Error test case - Python 2.3 """ import urllib url = "http://adds.aviationweather.noaa.gov/metars/index.php" params = urllib.urlencode({ "station_ids" : "KJFK", "hoursStr" : "most recent only", "std_trans" : "standard", "chk_metars" : "on", "submit":"Submit"}) print "test" for i in range(1, 1000): x = urllib.urlopen(url, params) string = x.read() print i """ Local variables for middle level routine... classURLopener open_http(self, url, data=None) args ('User-agent', 'Python-urllib/1.15') auth None data 'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub mit=Submit&chk_metars=on' errcode -1 errmsg '' fp None h headers None host 'adds.aviationweather.noaa.gov' httplib realhost 'adds.aviationweather.noaa.gov' selector '/metars/index.php' self url '//adds.aviationweather.noaa.gov/metars/index.php' user_passwd None """ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 22:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-16 23:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 08:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 00:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply at sourceforge.net Fri Jan 7 03:34:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 03:34:47 2005 Subject: [ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header Message-ID: Bugs item #1097597, was opened at 2005-01-06 18: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=1097597&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Schachter (razmatazz) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer sends wrong Content-Length header Initial Comment: On Microsoft Windows, text files use \r\n for newline. The SimpleHTTPServer class's "send_head()" method opens files with "r" or "rb" mode depending on the MIME type. Files opened in "r" mode will have \r\n -> \n translation performed automatically, so the stream of bytes sent to the client will be smaller than the size of the file on disk. Unfortunately, the send_head() method sets the Content-Length header using the file size on disk, without compensating for the \r\n -> \n translation. I remedied this on my copy thusly: if mode == "r": content = f.read() contentLength = str(len(content)) f.seek(0) else: contentLength = str(os.fstat(f.fileno())[6]) self.send_header("Content-Length", contentLength) This may not be as inefficient as it seems: the entire file was going to be read in anyway for the newline translation. Hmmm. The code could be slightly simpler: if mode == "r": contentLength = len(f.read()) f.seek(0) else: contentLength = os.fstat(f.fileno())[6] self.send_header("Content-Length", str(contentLength)) The documentation for SimpleHTTPServer in Python 2.3.4 for Windows says: A 'Content-type:' with the guessed content type is output, and then a blank line, signifying end of headers, and then the contents of the file. The file is always opened in binary mode. Actually, after Content-type, the Content-Length header is sent. It would probably be nice if "Content-Length" was "Content-length" or if "Content-type" was "Content-Type", for consistency. The latter is probably best, per RFC 2016. By the way, clients weren't caching the files I sent. I added another line after the Content-Length handling: self.send_header("Expires", "Fri, 31 Dec 2100 12:00:00 GMT") This is egregiously wrong in the general case and just fine in my case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 From noreply at sourceforge.net Fri Jan 7 03:51:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 03:51:27 2005 Subject: [ python-Bugs-1097229 ] Example needed in os.stat() Message-ID: Bugs item #1097229, was opened at 2005-01-06 11:39 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097229&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Facundo Batista (facundobatista) Summary: Example needed in os.stat() Initial Comment: As the repr() of an os.stat() object is *exactly* equal to a tuple, it's not clear at first in the documentation how to use its attributes: >>> import os >>> statinfo = os.stat('somefile.txt') >>> statinfo (33188, 422511L, 769L, 1, 1032, 100, 926L, 1105022698, 1105022732, 1105022732) >>> statinfo.st_size 926L >>> So I propose to put this example in the stat docs. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-06 23:51 Message: Logged In: YES user_id=752496 Changed the docs, commited to CVS. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-06 17:13 Message: Logged In: YES user_id=21627 Sure, go ahead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097229&group_id=5470 From noreply at sourceforge.net Fri Jan 7 04:36:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 04:37:06 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 02:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-06 19:36 Message: Logged In: YES user_id=357491 Ah, I didn't notice that Semaphore uses a Condition lock which uses an RLock which calls currentThread before and gets a lock from thread.allocate_lock which probably uses an Event on Windows. I also noticed that if __debug__ is set than the _note method uses it as well. It looks like Thread.__block can't be called for a _DummyThread since the only places self.__block is used is in Thread.__stop (which is called in Thread.__bootstrap which is called by Thread.start which will raise an AssertionError since Thread.__started will be set to True thanks to _DummyThread.__init__) and in Thread.join which is overridden in _DummyThread. So it looks like deleting the key should be safe in _DummyThread.__init__. Probably wouldn't hurt to delete self.__stderr while we are at it since it never gets used either and thus is basically a ref leak. Sound good to you, Tim? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-06 09:16 Message: Logged In: YES user_id=31435 Presumably, by changing threading.Semaphore to stop using any code from threading.py, then threading.currentThread() never gets called and so a _DummyThread is never created then. I expect the reason a _DummyThread causes Event leaks is just that Thread.__init__ always ends up allocating a Python lock (Thread.__block), which allocates a Windows Event under the covers. It *could* be that Thread.__block is never actually used for dummy threads, in which case we could avoid allocating it in that case (or could get rid of it right way in _DummyThread.__init__). The dummy thread would still clog the _active dict, but wouldn't leak Events then. It's certainly true that Python has no way to know when a thread it didn't start goes away. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:19 Message: Logged In: YES user_id=357491 What does Semaphore have to do with _DummyThread and currentThread? And as for win32api, that is not part of the Python stdlib and thus I have no way of commenting on that. For C++ threads to call into Python code, I would not say that is bad specifically. You were just trying to get thread info for non-Python threads and that was leading to _DummyThread instances to be created as designed and you just didn't want that. Calling Python code is fine, just don't expect it to know about your C++ threads as much as you seem to want it to. And please leave this bug closed. If free to submit a patch to change semantics, but that does not affect this bug report. ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 02:54 Message: Logged In: YES user_id=1181691 I tried the following workaround which is working (causes no handle leaks) Workaround is to change threading.semaphore to Windows Extension module APIs win32event.CreateMutex(), win32event.WaitForSingleObject and win32event.ReleaseMutex () After this change, there are no handle leaks. So, my questions are: 1) Is this workaround OK or are there any other issues regarding the win32api usage ? 2) you suggested to create minimal python wrappers for C++ code and call C++ from python (instead of C++ thread callbacks). So I would like to know, in general, whether it is a bad idea for c++ threads to callback into Python. If yes, what are the issues (apart from the handle leak mentioned before). If no, I would like to live with the above workaround. Thanks in advance ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 02:29 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-23 18:35 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Fri Jan 7 05:15:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 05:15:57 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 05:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-06 23:15 Message: Logged In: YES user_id=31435 Right, thread.allocate_lock() does allocate an Event on Windows. On other platforms it allocates other kinds of limited resource (one way or another, it has to grab some kind of locking object from the operating system, and the supply of those is typically finite). Looking it over, I agree Thread.__block won't be used by a dummy thread. I also note that the use of "assert False" in _DummyThread.join() is plain bizarre. It's a user error to try to join a dummy thread, not an internal invariant we believe *cannot* occur. Guido misused (IMO) `assert` in several places in this module, but its use in join() is way over the edge. Anyway, ya, I think it would be good to change this. I don't really understand the point to nuking Thread.__stderr -- typically, sys.stderr is a single object over the life of a program, and doesn't go away until the program ends. That is, I doubt the reference is keeping anything alive that would have gone away otherwise. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 22:36 Message: Logged In: YES user_id=357491 Ah, I didn't notice that Semaphore uses a Condition lock which uses an RLock which calls currentThread before and gets a lock from thread.allocate_lock which probably uses an Event on Windows. I also noticed that if __debug__ is set than the _note method uses it as well. It looks like Thread.__block can't be called for a _DummyThread since the only places self.__block is used is in Thread.__stop (which is called in Thread.__bootstrap which is called by Thread.start which will raise an AssertionError since Thread.__started will be set to True thanks to _DummyThread.__init__) and in Thread.join which is overridden in _DummyThread. So it looks like deleting the key should be safe in _DummyThread.__init__. Probably wouldn't hurt to delete self.__stderr while we are at it since it never gets used either and thus is basically a ref leak. Sound good to you, Tim? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-06 12:16 Message: Logged In: YES user_id=31435 Presumably, by changing threading.Semaphore to stop using any code from threading.py, then threading.currentThread() never gets called and so a _DummyThread is never created then. I expect the reason a _DummyThread causes Event leaks is just that Thread.__init__ always ends up allocating a Python lock (Thread.__block), which allocates a Windows Event under the covers. It *could* be that Thread.__block is never actually used for dummy threads, in which case we could avoid allocating it in that case (or could get rid of it right way in _DummyThread.__init__). The dummy thread would still clog the _active dict, but wouldn't leak Events then. It's certainly true that Python has no way to know when a thread it didn't start goes away. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 02:19 Message: Logged In: YES user_id=357491 What does Semaphore have to do with _DummyThread and currentThread? And as for win32api, that is not part of the Python stdlib and thus I have no way of commenting on that. For C++ threads to call into Python code, I would not say that is bad specifically. You were just trying to get thread info for non-Python threads and that was leading to _DummyThread instances to be created as designed and you just didn't want that. Calling Python code is fine, just don't expect it to know about your C++ threads as much as you seem to want it to. And please leave this bug closed. If free to submit a patch to change semantics, but that does not affect this bug report. ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 05:54 Message: Logged In: YES user_id=1181691 I tried the following workaround which is working (causes no handle leaks) Workaround is to change threading.semaphore to Windows Extension module APIs win32event.CreateMutex(), win32event.WaitForSingleObject and win32event.ReleaseMutex () After this change, there are no handle leaks. So, my questions are: 1) Is this workaround OK or are there any other issues regarding the win32api usage ? 2) you suggested to create minimal python wrappers for C++ code and call C++ from python (instead of C++ thread callbacks). So I would like to know, in general, whether it is a bad idea for c++ threads to callback into Python. If yes, what are the issues (apart from the handle leak mentioned before). If no, I would like to live with the above workaround. Thanks in advance ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 05:29 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-23 21:35 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Fri Jan 7 07:54:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 07:54:54 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 rhettinger 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: 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 Jan 7 13:39:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 13:39:46 2005 Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 08:52 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stuart Bishop (zenzen) Assigned to: A.M. Kuchling (akuchling) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 07:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 20:37 Message: Logged In: YES user_id=80475 Andrew, are you still working on this one? ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-18 18:43 Message: Logged In: YES user_id=1000470 The file pointer (fp) is None (inside urllib) from httplib. This appears to be caused by a BadStatusLine exception in getreply() (line1016 httplib). This sets self.file to self._conn.sock.makefile('rb', 0) then does a self.close() which sets self.file to None. Being new to this peice of code, I'm not sure whether it's urllib assuming the file isn't going to be closed, or the BadStatusLine exception clearing the file. Certainly it looks like the error -1 is not being trapped by open_http() in urllib upon calling h.getreply() and assuming that the file still exists even in an error condition? It maybe a coincidence but it appears to occur more when a web browser on the same machine is refreshing. Regards Rob ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-17 17:24 Message: Logged In: YES user_id=1000470 """ This comment is program to reproduce the problem. Sorry it's not an attachment - as a relative Sourceforge newbie I have no idea how to attach to an existing bug. More notes available via email if required - including all local variables for each function from post mortem. As said before, seems to be fp = None. Although the exception is caused by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside open_http() This is repeatable, but you may have to run this more than once. (Apologies to noaa.gov). *** PLEASE: Run only where absolutely necessary for reproduction of bug!!! *** """ """ Attribute Error test case - Python 2.3 """ import urllib url = "http://adds.aviationweather.noaa.gov/metars/index.php" params = urllib.urlencode({ "station_ids" : "KJFK", "hoursStr" : "most recent only", "std_trans" : "standard", "chk_metars" : "on", "submit":"Submit"}) print "test" for i in range(1, 1000): x = urllib.urlopen(url, params) string = x.read() print i """ Local variables for middle level routine... classURLopener open_http(self, url, data=None) args ('User-agent', 'Python-urllib/1.15') auth None data 'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub mit=Submit&chk_metars=on' errcode -1 errmsg '' fp None h headers None host 'adds.aviationweather.noaa.gov' httplib realhost 'adds.aviationweather.noaa.gov' selector '/metars/index.php' self url '//adds.aviationweather.noaa.gov/metars/index.php' user_passwd None """ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 00:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 09:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply at sourceforge.net Fri Jan 7 13:39:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 13:40:15 2005 Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 08:52 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stuart Bishop (zenzen) >Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 07:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 07:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-06 20:37 Message: Logged In: YES user_id=80475 Andrew, are you still working on this one? ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-18 18:43 Message: Logged In: YES user_id=1000470 The file pointer (fp) is None (inside urllib) from httplib. This appears to be caused by a BadStatusLine exception in getreply() (line1016 httplib). This sets self.file to self._conn.sock.makefile('rb', 0) then does a self.close() which sets self.file to None. Being new to this peice of code, I'm not sure whether it's urllib assuming the file isn't going to be closed, or the BadStatusLine exception clearing the file. Certainly it looks like the error -1 is not being trapped by open_http() in urllib upon calling h.getreply() and assuming that the file still exists even in an error condition? It maybe a coincidence but it appears to occur more when a web browser on the same machine is refreshing. Regards Rob ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-17 17:24 Message: Logged In: YES user_id=1000470 """ This comment is program to reproduce the problem. Sorry it's not an attachment - as a relative Sourceforge newbie I have no idea how to attach to an existing bug. More notes available via email if required - including all local variables for each function from post mortem. As said before, seems to be fp = None. Although the exception is caused by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside open_http() This is repeatable, but you may have to run this more than once. (Apologies to noaa.gov). *** PLEASE: Run only where absolutely necessary for reproduction of bug!!! *** """ """ Attribute Error test case - Python 2.3 """ import urllib url = "http://adds.aviationweather.noaa.gov/metars/index.php" params = urllib.urlencode({ "station_ids" : "KJFK", "hoursStr" : "most recent only", "std_trans" : "standard", "chk_metars" : "on", "submit":"Submit"}) print "test" for i in range(1, 1000): x = urllib.urlopen(url, params) string = x.read() print i """ Local variables for middle level routine... classURLopener open_http(self, url, data=None) args ('User-agent', 'Python-urllib/1.15') auth None data 'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub mit=Submit&chk_metars=on' errcode -1 errmsg '' fp None h headers None host 'adds.aviationweather.noaa.gov' httplib realhost 'adds.aviationweather.noaa.gov' selector '/metars/index.php' self url '//adds.aviationweather.noaa.gov/metars/index.php' user_passwd None """ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 00:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 09:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply at sourceforge.net Fri Jan 7 13:49:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 13:49:37 2005 Subject: [ python-Bugs-1097834 ] urllib2 doesn't handle urls without a scheme Message-ID: Bugs item #1097834, was opened at 2005-01-07 13: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=1097834&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without a scheme Initial Comment: Unlike urllib, urllib2 does not handle "/path/to/file" style urls (without a scheme) as "file:" urls. I'm not sure whether this is a bug per se, but if this behaviour is by design then urllib2 should get a pathname2url() method that changes a pathname to a "file:"-prefixed url. urllib.pathname2url() does not prefix the url, but that's fine because urllib.urlopen() treats urls without schemes as file: urls. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097834&group_id=5470 From noreply at sourceforge.net Fri Jan 7 15:35:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 15:36:02 2005 Subject: [ python-Bugs-1083177 ] Change in signal function in the signal module Message-ID: Bugs item #1083177, was opened at 2004-12-10 15:58 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 >Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: A.M. Kuchling (akuchling) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 09:35 Message: Logged In: YES user_id=11375 Change now described in "What's New". ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-13 08:16 Message: Logged In: YES user_id=29957 This is a deliberate change - "errors should not pass silently". I agree that it should get better visibility. Perhaps an entry in amk's what's new document in the section on Porting to 2.4 would be appropriate. AMK? (I've added a comment to the document as a reminder) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:32 Message: Logged In: YES user_id=80475 On WinME, I appropriately get an AttributeError consistently for Py2.2, Py2.3, and Py2.4. Anthony, you've made the most recent updates to the signalmodule. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 From noreply at sourceforge.net Fri Jan 7 17:33:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 17:33:24 2005 Subject: [ python-Bugs-989337 ] test_descr fails on win2k Message-ID: Bugs item #989337, was opened at 2004-07-12 20:07 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_descr fails on win2k Initial Comment: >>> from test import test_descr >>> test_descr.verbose = 1 >>> test_descr.test_main() Testing weakref segfault... Testing SF bug 551412 ... Testing SF bug 570483... Testing list operations... checking a+b checking b in a checking b in a checking a[b] checking a[b:c] checking a+=b checking a*=b checking len(a) checking a*b checking b*a checking a[b]=c checking a[b:c]=d Testing dict operations... checking cmp(a,b) checking b in a checking b in a checking a[b] checking len(a) checking a[b]=c Testing dict constructor ... Testing dir() ... Testing int operations... checking a & b checking a ^ b checking a >> b checking a - b checking a ** b checking a + b checking divmod(a, b) checking a << b checking a * b checking a / b checking cmp(a, b) checking a | b checking a % b checking int(a) checking - a checking ~ a checking float(a) checking hex(a) checking + a checking long(a) checking abs(a) checking oct(a) Testing long operations... checking a & b checking a ^ b checking a >> b checking a - b checking a ** b checking a + b checking divmod(a, b) checking a << b checking a * b checking a / b checking cmp(a, b) checking a | b checking a % b checking int(a) checking - a checking ~ a checking float(a) checking hex(a) checking + a checking long(a) checking abs(a) checking oct(a) Testing float operations... checking a >= b checking a - b checking a > b checking a ** b checking a < b checking a != b checking a + b checking a <= b checking divmod(a, b) checking a * b checking a / b checking a == b checking a % b checking int(a) checking - a checking float(a) checking + a checking long(a) checking abs(a) Testing complex operations... checking a - b checking a ** b checking a != b checking a + b checking divmod(a, b) checking a * b checking a / b checking a == b checking a % b checking - a checking + a checking abs(a) Testing spamlist operations... checking a+b checking b in a checking b in a checking a[b] checking a[b:c] checking a+=b checking a*=b checking len(a) checking a*b checking b*a checking a[b]=c checking a[b:c]=d Testing spamdict operations... checking cmp(a,b) checking b in a checking b in a checking a[b] checking len(a) checking repr(a) checking a[b]=c Testing Python subclass of dict... pydict stress test ... Testing Python subclass of list... Testing __metaclass__... Testing Python subclass of module... Testing multiple inheritance... Testing error messages for MRO disagreement... Testing multiple inheritance special cases... Testing ex5 from C3 switch discussion... Testing MRO monotonicity... Testing consistentcy with EPG... Testing object class... Testing __slots__... Testing __dict__ and __weakref__ in __slots__... Testing class attribute propagation... Testing errors... Testing class methods... Testing C-based class methods... Testing static methods... Testing C-based static methods... Testing classic classes... Testing computed attributes... Testing __new__ slot override... Testing mro() and overriding it... Testing operator overloading... Testing methods... Testing special operators... Traceback (most recent call last): File "", line 1, in -toplevel- test_descr.test_main() File "C:\apps\Python24\lib\test\test_descr.py", line 4024, in test_main specials() File "C:\apps\Python24\lib\test\test_descr.py", line 1875, in specials print Letter('w') PicklingError: Can't pickle : attribute lookup test.test_descr.Letter failed >>> This is Python 2.4a1 on win2k pro ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-08 01:33 Message: Logged In: YES user_id=671362 Yes, I have(2.4, 2.4.1a0, 2.5a0). Much shorter way is : >>> from test.test_descr import specials >>> specials() Several things I noticed: - You need to run it from IDLE, not from the command line. - (Probably)OS independent. (I confirmed with both Windows and Linux) - error message is printed to the console, saying s.t. like: Cannot pickle: (16, ('CALL', ('stdout', 'write', ('w',), {}))) - This message comes from idlelib.rpc.SocketIO::putmessage Does this help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-07 10:19 Message: Logged In: YES user_id=80475 Do you still have a problem with this in Py2.4 final ? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-10-18 01:00 Message: Logged In: YES user_id=358087 Still here in Python-2.4b1 ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-19 14:09 Message: Logged In: YES user_id=358087 Sorry, forgot that I've upgraded to winXP the other day. This *is* winXP pro SP1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 04:46 Message: Logged In: YES user_id=80475 I cannot reproduce this on either WinME or WinXP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470 From noreply at sourceforge.net Fri Jan 7 21:28:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 7 21:28:53 2005 Subject: [ python-Bugs-1098134 ] getsource and getsourcelines in the inspect module Message-ID: Bugs item #1098134, was opened at 2005-01-07 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098134&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: getsource and getsourcelines in the inspect module Initial Comment: import inspect class Hi: def oneliner1(): pass def oneliner2(): pass h = Hi() print inspect.getsourcelines(h.oneliner1) print "+++" + inspect.getsource(h.oneliner1) + "+++" Tested on Python 2.3.4. Both the getsource* functions takes the body of onliner1() and oneliner2() in the call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098134&group_id=5470 From noreply at sourceforge.net Sat Jan 8 03:47:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 03:47:41 2005 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 02:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-07 18:47 Message: Logged In: YES user_id=357491 OK, rev. 1.46 for 2.5 has the fix (now this bug is closed). I can backport to 2.4 and 2.3, but it technically changes the interface and it is not a huge issue so I am not going to bother to backport unless people really feel it is necessary. As for the assert use, yeah, that is odd. =) But that whole module could use a rewrite. Probably a good thing to do for Python 3. The reason I suggested the self.__stderr deletion is because there is a chance that someone set sys.stderr to a file or some other object and not to sys._stderr. Thought it would be a more thorough fix, but not a big thing to me; just happened to notice it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-06 20:15 Message: Logged In: YES user_id=31435 Right, thread.allocate_lock() does allocate an Event on Windows. On other platforms it allocates other kinds of limited resource (one way or another, it has to grab some kind of locking object from the operating system, and the supply of those is typically finite). Looking it over, I agree Thread.__block won't be used by a dummy thread. I also note that the use of "assert False" in _DummyThread.join() is plain bizarre. It's a user error to try to join a dummy thread, not an internal invariant we believe *cannot* occur. Guido misused (IMO) `assert` in several places in this module, but its use in join() is way over the edge. Anyway, ya, I think it would be good to change this. I don't really understand the point to nuking Thread.__stderr -- typically, sys.stderr is a single object over the life of a program, and doesn't go away until the program ends. That is, I doubt the reference is keeping anything alive that would have gone away otherwise. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 19:36 Message: Logged In: YES user_id=357491 Ah, I didn't notice that Semaphore uses a Condition lock which uses an RLock which calls currentThread before and gets a lock from thread.allocate_lock which probably uses an Event on Windows. I also noticed that if __debug__ is set than the _note method uses it as well. It looks like Thread.__block can't be called for a _DummyThread since the only places self.__block is used is in Thread.__stop (which is called in Thread.__bootstrap which is called by Thread.start which will raise an AssertionError since Thread.__started will be set to True thanks to _DummyThread.__init__) and in Thread.join which is overridden in _DummyThread. So it looks like deleting the key should be safe in _DummyThread.__init__. Probably wouldn't hurt to delete self.__stderr while we are at it since it never gets used either and thus is basically a ref leak. Sound good to you, Tim? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-06 09:16 Message: Logged In: YES user_id=31435 Presumably, by changing threading.Semaphore to stop using any code from threading.py, then threading.currentThread() never gets called and so a _DummyThread is never created then. I expect the reason a _DummyThread causes Event leaks is just that Thread.__init__ always ends up allocating a Python lock (Thread.__block), which allocates a Windows Event under the covers. It *could* be that Thread.__block is never actually used for dummy threads, in which case we could avoid allocating it in that case (or could get rid of it right way in _DummyThread.__init__). The dummy thread would still clog the _active dict, but wouldn't leak Events then. It's certainly true that Python has no way to know when a thread it didn't start goes away. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-01-05 23:19 Message: Logged In: YES user_id=357491 What does Semaphore have to do with _DummyThread and currentThread? And as for win32api, that is not part of the Python stdlib and thus I have no way of commenting on that. For C++ threads to call into Python code, I would not say that is bad specifically. You were just trying to get thread info for non-Python threads and that was leading to _DummyThread instances to be created as designed and you just didn't want that. Calling Python code is fine, just don't expect it to know about your C++ threads as much as you seem to want it to. And please leave this bug closed. If free to submit a patch to change semantics, but that does not affect this bug report. ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 02:54 Message: Logged In: YES user_id=1181691 I tried the following workaround which is working (causes no handle leaks) Workaround is to change threading.semaphore to Windows Extension module APIs win32event.CreateMutex(), win32event.WaitForSingleObject and win32event.ReleaseMutex () After this change, there are no handle leaks. So, my questions are: 1) Is this workaround OK or are there any other issues regarding the win32api usage ? 2) you suggested to create minimal python wrappers for C++ code and call C++ from python (instead of C++ thread callbacks). So I would like to know, in general, whether it is a bad idea for c++ threads to callback into Python. If yes, what are the issues (apart from the handle leak mentioned before). If no, I would like to live with the above workaround. Thanks in advance ---------------------------------------------------------------------- Comment By: saravanand (saravanand) Date: 2005-01-05 02:29 Message: Logged In: YES user_id=1181691 asdfas ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-23 18:35 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Sat Jan 8 06:19:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 06:19:24 2005 Subject: [ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter() Message-ID: Bugs item #639611, was opened at 2002-11-17 06:38 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 3 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Guido van Rossum (gvanrossum) Summary: crash (SEGV) in Py_EndInterpreter() Initial Comment: I experience a 80% reproducable SIGSEGV in a multithreaded app I wrote using different embedded sub interpreters in its threads. I have a C++ class (PClass) which encapsulates the sub-interpreters somehow - it creates a new one in its constructor and deletes it in the destructor (see below). When 2 objects of this class are destroyed at nearly the same time thus resulting in subsequent calls to Py_EndInterpreter() (but for the different threads), I get the following SIGSEGV in most cases: > gdb application core.31889 [...] Program terminated with signal 11, Segmentation fault. [...] Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 169 _PyObject_GC_UNTRACK(op); (gdb) bt #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 #1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at Python/pystate.c:190 #2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at Python/pystate.c:77 #3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at Python/pythonrun.c:381 #4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123 When the 2nd object is destroyed some seconds later, everything seems to be fine. It only crashes when the 2 objects are deleted within a short period of time. I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built Python-2.2.2 with the same result. :-( Here's a very short snippet of the python related code in my class: // Constructor, initializes Python sub-interpreter PClass::PClass() { PyEval_AcquireLock(); py_state=Py_NewInterpreter(); PyEval_SaveThread(); } // destructor, kills the Python sub-interpreter PClass::~PClass() { PyEval_RestoreThread(py_state); Py_EndInterpreter(py_state); py_state=NULL; PyEval_ReleaseLock(); // release lock } // thread code, runs Python function void PClass::run() { PyEval_RestoreThread(py_state); PyObject_CallFunction(...) PyEval_SaveThread(); } ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-08 02:19 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:10 Message: Logged In: YES user_id=6380 No time for this now, lowering priority. If someone has a patch, feel free to submit to SF. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 18:35 Message: Logged In: YES user_id=31435 Guido should look at it -- subinterpreters were his idea <wink>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 10:19 Message: Logged In: YES user_id=33168 Tim, it was suggested you see this. Is this documented somewhere? What should be done? ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-21 06:31 Message: Logged In: YES user_id=115179 I think it should be documented and additional check performed before killing thread state or interpereter. Leave it open - Tim Peters should see this. ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-21 03:09 Message: Logged In: YES user_id=633130 Ok, after cleaning up my exception handling a little bit (especially preventing exceptions to be triggered from outside after run() has finished) I can't reproduce the problems any more. So the bug is worked around for me. I leave it open if you consider this to be a real bug which has to be fixed. If you don't fix it and an user must always call PyErr_Clear() before Py_EndInterpreter() this should be documented IMHO. TIA! ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-20 05:12 Message: Logged In: YES user_id=633130 It really seems to have some connection with my exception handling. I'm investigating further. Please stand by... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-18 11:00 Message: Logged In: YES user_id=115179 I have found it (perhaps), while an python exception is pending and PyEval_RestoreThread is called, my Python anwalys bumps. After adding PyErr_Clear or PyErr_Print just before this call makes python happy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 From noreply at sourceforge.net Sat Jan 8 06:23:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 06:24:04 2005 Subject: [ python-Bugs-640553 ] Misuse of /usr/local/in setup.py Message-ID: Bugs item #640553, was opened at 2002-11-19 05:04 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Misuse of /usr/local/in setup.py Initial Comment: I cannot guarantee that this has not been reported before, as the search facility doesn't appear sufficiently powerful to determine that, and I do not have time to read a hundred bug reports. setup.py forces the use of /usr/local, which is wrong on more counts than I can describe. Not merely need it not exist, it could easily contain the wrong versions of libraries and headers. The following change should be reversed: *** setup.py.org Mon Nov 18 19:57:09 2002 --- setup.py Mon Nov 18 19:57:23 2002 *************** *** 197,207 **** return platform def detect_modules(self): - # Ensure that /usr/local is always used - if '/usr/local/lib' not in self.compiler.library_dirs: - self.compiler.library_dirs.insert(0, '/usr/local/lib') - if '/usr/local/include' not in self.compiler.include_dirs: - self.compiler.include_dirs.insert(0, '/usr/local/include' ) try: have_unicode = unicode --- 197,202 ---- ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-08 02:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm1) Date: 2002-11-19 14:44 Message: Logged In: YES user_id=652073 Well, that's an odd interpretation, but it isn't a great matter. However, I do feel that the "gotcha" should be documented. For example, the following perfectly reasonable use will fail horribly on many systems: A user version of a shareable library is in /usr/local/lib, which is a mountable filing system, and a system version in /usr/lib, which isn't - the former may be a symlink, or may be the testing version. Python is built using the standard mechanism, and is then used for system scripts. If those are then ever run when /usr/local is not mounted, they will fail horribly. Incidentally, we got caught by that one by making /usr mountable on one version of IRIX. It was actually SGI themselves who had missed the "gotcha", but we had the problem :-( Do what you will with this - I have resolved the issue here. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-19 14:38 Message: Logged In: YES user_id=44345 Some compilers complain if -I/usr/local/include is on the command line because it changes the compiler's notion of include file search order. The case -L/usr/local/lib may be similar. If this was an ideal world, I think we would ask the compiler if it searches /usr/local by default. If so, don't add the -I/-L flags. Maybe there's an autoconf macro floating around that can do this? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 14:05 Message: Logged In: YES user_id=21627 If /usr/local/lib causes a build failure, then the requirements are not absolutely standard, by (our) definition: We require /usr/local/lib to provide any libraries that are not normally on the system. Absence of /usr/local/lib is not a problem, nor are missing libraries a problem. If accessing /usr/local/lib alone causes catastrophic failures, it can't be a standard system. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm1) Date: 2002-11-19 09:29 Message: Logged In: YES user_id=652073 No, that's not the issue. The build was absolutely out of the box, and the requirements were absolutely standard. But, for reasons that are irrelevant, -L/usr/local/lib caused failure. The point was that I had not specified it, it was not specified anywhere in the configuration or any of the Makefiles, and it wasn't even in Modules/Setup! So I could not understand where it was being set. I discovered that setup.py is invoked by default, and that did the job but didn't leave a record in any configuration or building file. GOTCHA! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-19 07:00 Message: Logged In: YES user_id=6656 It's not added if it doesn't exist in the HEAD branch. Wrt the other complaint, I think setup.py is only intended to be a convenience. If you have even vaguely complex building requirements, edit Modules/Setup instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&group_id=5470 From noreply at sourceforge.net Sat Jan 8 09:52:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 09:52:57 2005 Subject: [ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter() Message-ID: Bugs item #639611, was opened at 2002-11-17 10:38 Message generated for change (Comment added) made by yoda_gh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open >Resolution: Works For Me Priority: 3 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Guido van Rossum (gvanrossum) Summary: crash (SEGV) in Py_EndInterpreter() Initial Comment: I experience a 80% reproducable SIGSEGV in a multithreaded app I wrote using different embedded sub interpreters in its threads. I have a C++ class (PClass) which encapsulates the sub-interpreters somehow - it creates a new one in its constructor and deletes it in the destructor (see below). When 2 objects of this class are destroyed at nearly the same time thus resulting in subsequent calls to Py_EndInterpreter() (but for the different threads), I get the following SIGSEGV in most cases: > gdb application core.31889 [...] Program terminated with signal 11, Segmentation fault. [...] Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 169 _PyObject_GC_UNTRACK(op); (gdb) bt #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 #1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at Python/pystate.c:190 #2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at Python/pystate.c:77 #3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at Python/pythonrun.c:381 #4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123 When the 2nd object is destroyed some seconds later, everything seems to be fine. It only crashes when the 2 objects are deleted within a short period of time. I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built Python-2.2.2 with the same result. :-( Here's a very short snippet of the python related code in my class: // Constructor, initializes Python sub-interpreter PClass::PClass() { PyEval_AcquireLock(); py_state=Py_NewInterpreter(); PyEval_SaveThread(); } // destructor, kills the Python sub-interpreter PClass::~PClass() { PyEval_RestoreThread(py_state); Py_EndInterpreter(py_state); py_state=NULL; PyEval_ReleaseLock(); // release lock } // thread code, runs Python function void PClass::run() { PyEval_RestoreThread(py_state); PyObject_CallFunction(...) PyEval_SaveThread(); } ---------------------------------------------------------------------- >Comment By: Gernot Hillier (yoda_gh) Date: 2005-01-08 09:52 Message: Logged In: YES user_id=633130 Hmm, I'm quite sorry, but I changed my application quite thoroughly in the meantime and never ever experienced any problem again - and the application is widely used in the meantime. I also can't really remember what I've changed in the "workaround" of 2002-11-21 07:09. I could try to find these details if someone is really interested in my old archives, but if not, I'll consider this as fixed/"works for me" now. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-08 06:19 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 22:10 Message: Logged In: YES user_id=6380 No time for this now, lowering priority. If someone has a patch, feel free to submit to SF. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 22:35 Message: Logged In: YES user_id=31435 Guido should look at it -- subinterpreters were his idea <wink>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 14:19 Message: Logged In: YES user_id=33168 Tim, it was suggested you see this. Is this documented somewhere? What should be done? ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-21 10:31 Message: Logged In: YES user_id=115179 I think it should be documented and additional check performed before killing thread state or interpereter. Leave it open - Tim Peters should see this. ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-21 07:09 Message: Logged In: YES user_id=633130 Ok, after cleaning up my exception handling a little bit (especially preventing exceptions to be triggered from outside after run() has finished) I can't reproduce the problems any more. So the bug is worked around for me. I leave it open if you consider this to be a real bug which has to be fixed. If you don't fix it and an user must always call PyErr_Clear() before Py_EndInterpreter() this should be documented IMHO. TIA! ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-20 09:12 Message: Logged In: YES user_id=633130 It really seems to have some connection with my exception handling. I'm investigating further. Please stand by... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-18 15:00 Message: Logged In: YES user_id=115179 I have found it (perhaps), while an python exception is pending and PyEval_RestoreThread is called, my Python anwalys bumps. After adding PyErr_Clear or PyErr_Print just before this call makes python happy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 From noreply at sourceforge.net Sat Jan 8 12:09:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 12:09:54 2005 Subject: [ python-Bugs-1098134 ] getsource and getsourcelines in the inspect module Message-ID: Bugs item #1098134, was opened at 2005-01-07 21:28 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098134&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: getsource and getsourcelines in the inspect module Initial Comment: import inspect class Hi: def oneliner1(): pass def oneliner2(): pass h = Hi() print inspect.getsourcelines(h.oneliner1) print "+++" + inspect.getsource(h.oneliner1) + "+++" Tested on Python 2.3.4. Both the getsource* functions takes the body of onliner1() and oneliner2() in the call. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 12:09 Message: Logged In: YES user_id=469548 This is fixed in Python 2.5 and the upcoming 2.4.1 by patch 1011890. Thanks for the report, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098134&group_id=5470 From noreply at sourceforge.net Sat Jan 8 12:11:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 12:11:17 2005 Subject: [ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter() Message-ID: Bugs item #639611, was opened at 2002-11-17 10:38 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Guido van Rossum (gvanrossum) Summary: crash (SEGV) in Py_EndInterpreter() Initial Comment: I experience a 80% reproducable SIGSEGV in a multithreaded app I wrote using different embedded sub interpreters in its threads. I have a C++ class (PClass) which encapsulates the sub-interpreters somehow - it creates a new one in its constructor and deletes it in the destructor (see below). When 2 objects of this class are destroyed at nearly the same time thus resulting in subsequent calls to Py_EndInterpreter() (but for the different threads), I get the following SIGSEGV in most cases: > gdb application core.31889 [...] Program terminated with signal 11, Segmentation fault. [...] Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 169 _PyObject_GC_UNTRACK(op); (gdb) bt #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 #1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at Python/pystate.c:190 #2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at Python/pystate.c:77 #3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at Python/pythonrun.c:381 #4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123 When the 2nd object is destroyed some seconds later, everything seems to be fine. It only crashes when the 2 objects are deleted within a short period of time. I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built Python-2.2.2 with the same result. :-( Here's a very short snippet of the python related code in my class: // Constructor, initializes Python sub-interpreter PClass::PClass() { PyEval_AcquireLock(); py_state=Py_NewInterpreter(); PyEval_SaveThread(); } // destructor, kills the Python sub-interpreter PClass::~PClass() { PyEval_RestoreThread(py_state); Py_EndInterpreter(py_state); py_state=NULL; PyEval_ReleaseLock(); // release lock } // thread code, runs Python function void PClass::run() { PyEval_RestoreThread(py_state); PyObject_CallFunction(...) PyEval_SaveThread(); } ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2005-01-08 09:52 Message: Logged In: YES user_id=633130 Hmm, I'm quite sorry, but I changed my application quite thoroughly in the meantime and never ever experienced any problem again - and the application is widely used in the meantime. I also can't really remember what I've changed in the "workaround" of 2002-11-21 07:09. I could try to find these details if someone is really interested in my old archives, but if not, I'll consider this as fixed/"works for me" now. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-08 06:19 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 22:10 Message: Logged In: YES user_id=6380 No time for this now, lowering priority. If someone has a patch, feel free to submit to SF. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 22:35 Message: Logged In: YES user_id=31435 Guido should look at it -- subinterpreters were his idea <wink>. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 14:19 Message: Logged In: YES user_id=33168 Tim, it was suggested you see this. Is this documented somewhere? What should be done? ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-21 10:31 Message: Logged In: YES user_id=115179 I think it should be documented and additional check performed before killing thread state or interpereter. Leave it open - Tim Peters should see this. ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-21 07:09 Message: Logged In: YES user_id=633130 Ok, after cleaning up my exception handling a little bit (especially preventing exceptions to be triggered from outside after run() has finished) I can't reproduce the problems any more. So the bug is worked around for me. I leave it open if you consider this to be a real bug which has to be fixed. If you don't fix it and an user must always call PyErr_Clear() before Py_EndInterpreter() this should be documented IMHO. TIA! ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-20 09:12 Message: Logged In: YES user_id=633130 It really seems to have some connection with my exception handling. I'm investigating further. Please stand by... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-18 15:00 Message: Logged In: YES user_id=115179 I have found it (perhaps), while an python exception is pending and PyEval_RestoreThread is called, my Python anwalys bumps. After adding PyErr_Clear or PyErr_Print just before this call makes python happy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 From noreply at sourceforge.net Sat Jan 8 13:32:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 13:32:55 2005 Subject: [ python-Bugs-1048878 ] shutil.copytree copies stat of files, but not of dirs Message-ID: Bugs item #1048878, was opened at 2004-10-18 00:12 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048878&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Waldmann (thomaswaldmann) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: shutil.copytree copies stat of files, but not of dirs Initial Comment: Caring for stat of files, but modifying stat of dirs is maybe not what's expected from that function. I discovered that when implementing a new function in MoinMoin when it changed directory modes from -rw-rw---- to -rw-------. It is easy to fix: $ diff -u shutil.py shutil.py-tw --- shutil.py 2004-10-17 23:19:25.000000000 +0200 +++ shutil.py-tw 2004-10-18 00:01:57.000000000 +0200 @@ -109,6 +109,7 @@ """ names = os.listdir(src) os.mkdir(dst) + copystat(src, dst) errors = [] for name in names: srcname = os.path.join(src, name) Maybe it is even better to do that copystat after the for loop (and thus, after the recursive calls modifying the timestamp of the directory) and before the if statement, so it may even conserve the dir timestamp (I didn't test that). It happens in 2.3.4 as well as in 2.4 beta 1. Strictly taken, it is not a bug, as the docs say nothing about what it does to directories. But well, maybe just the docs need to be changed as well. :) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:32 Message: Logged In: YES user_id=469548 Fixed by applying patch #1094015. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048878&group_id=5470 From noreply at sourceforge.net Sat Jan 8 13:33:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 13:33:23 2005 Subject: [ python-Bugs-975763 ] shutil.copytree uses os.mkdir instead of os.mkdirs Message-ID: Bugs item #975763, was opened at 2004-06-19 08:35 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975763&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Brett Cannon (bcannon) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: shutil.copytree uses os.mkdir instead of os.mkdirs Initial Comment: shutil.copytree uses os.mkdir instead of os.mkdirs for creating the new destination directory. Any reason why it doesn't use os.mkdirs? If there is the docs should be made more specific in stating that it will not create intermediate directories for the destination. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:33 Message: Logged In: YES user_id=469548 Fixed by applying patch #1094015. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975763&group_id=5470 From noreply at sourceforge.net Sat Jan 8 13:41:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 13:41:21 2005 Subject: [ python-Bugs-1095342 ] General FAQ: list.sort() out of date Message-ID: Bugs item #1095342, was opened at 2005-01-04 00:16 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: General FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:41 Message: Logged In: YES user_id=469548 Fixed in rev 1.22 of general.ht. Thanks for the new text! ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2005-01-04 01:28 Message: Logged In: YES user_id=603121 Updated text: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from a passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... Versions of Python prior to 2.4 need to use the following idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2005-01-04 00:21 Message: Logged In: YES user_id=603121 Do we want to also reference the 2.3 and earlier idiom? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 From noreply at sourceforge.net Sat Jan 8 15:22:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 15:23:06 2005 Subject: [ python-Bugs-756982 ] mailbox should use email not rfc822 Message-ID: Bugs item #756982, was opened at 2003-06-19 04:19 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Open >Resolution: None Priority: 5 Submitted By: Ben Leslie (benno37) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox should use email not rfc822 Initial Comment: The mailbox module uses the rfc822 module as its default factory for creating message objects. The rfc822 documentation claims that its use is deprecated. The mailbox module should probably use the new email module as its default factory. Of course this has backward compatibility issues, in which case it should at least be mentioned in the mailbox documentation that it uses the deprecated rfc822 module, and provide an example of how to use the email module instead. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 15:22 Message: Logged In: YES user_id=469548 So, with the plans to seriously start working deprecating rfc822, should we use the email module as the default factory now? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-20 23:48 Message: Logged In: YES user_id=12800 I've added some sample code to the mailbox documentation that explain how to use the email package with the mailbox module. We can't change the default for backward compatibility reasons, as you point out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 From noreply at sourceforge.net Sat Jan 8 16:06:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 16:06:56 2005 Subject: [ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite Message-ID: Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 From noreply at sourceforge.net Sat Jan 8 16:34:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 16:34:51 2005 Subject: [ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite Message-ID: Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by ludootje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. ---------------------------------------------------------------------- >Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 From noreply at sourceforge.net Sat Jan 8 16:49:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 16:49:07 2005 Subject: [ python-Bugs-756982 ] mailbox should use email not rfc822 Message-ID: Bugs item #756982, was opened at 2003-06-18 22:19 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Leslie (benno37) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox should use email not rfc822 Initial Comment: The mailbox module uses the rfc822 module as its default factory for creating message objects. The rfc822 documentation claims that its use is deprecated. The mailbox module should probably use the new email module as its default factory. Of course this has backward compatibility issues, in which case it should at least be mentioned in the mailbox documentation that it uses the deprecated rfc822 module, and provide an example of how to use the email module instead. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-01-08 10:49 Message: Logged In: YES user_id=12800 It's a good question. I'd like to say yes so that we can start adding deprecation warnings to rfc822 for Python 2.5. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 09:22 Message: Logged In: YES user_id=469548 So, with the plans to seriously start working deprecating rfc822, should we use the email module as the default factory now? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-20 17:48 Message: Logged In: YES user_id=12800 I've added some sample code to the mailbox documentation that explain how to use the email package with the mailbox module. We can't change the default for backward compatibility reasons, as you point out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 From noreply at sourceforge.net Sat Jan 8 18:06:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 18:06:46 2005 Subject: [ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite Message-ID: Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by ludootje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. ---------------------------------------------------------------------- >Comment By: Ludootje (ludootje) Date: 2005-01-08 18:06 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: "Previously, there were only 256 possible ordinals for script characters and texts were typically bound to a code page which mapped the ordinals to script characters." I'm not sure if I totally "get" this sentence, but if I do, adding a comma after "characters" (the first occurence of it) would make it more clear or readable, IMHO. This would lead to: "Previously, there were only 256 possible ordinals for script characters, and texts were typically bound to a code page which mapped the ordinals to script characters." Just a thought. ---------------------------------------------------------------------- Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 From noreply at sourceforge.net Sat Jan 8 18:16:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 18:16:05 2005 Subject: [ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite Message-ID: Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by ludootje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. ---------------------------------------------------------------------- >Comment By: Ludootje (ludootje) Date: 2005-01-08 18:16 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: The small "u" in front of the quote indicates that an Unicode string is supposed to be created. Isn't it "a Unicode", instead of "an Unicode"? I wasn't too sure of this one, but Googling for both brings up much more results for "a Unicode", and, more importantly, the results are from more "official" entities (like unicode.org, for example). ---------------------------------------------------------------------- Comment By: Ludootje (ludootje) Date: 2005-01-08 18:06 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: "Previously, there were only 256 possible ordinals for script characters and texts were typically bound to a code page which mapped the ordinals to script characters." I'm not sure if I totally "get" this sentence, but if I do, adding a comma after "characters" (the first occurence of it) would make it more clear or readable, IMHO. This would lead to: "Previously, there were only 256 possible ordinals for script characters, and texts were typically bound to a code page which mapped the ordinals to script characters." Just a thought. ---------------------------------------------------------------------- Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 From noreply at sourceforge.net Sat Jan 8 21:24:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 21:24:21 2005 Subject: [ python-Bugs-1098618 ] socket.setdefaulttimeout() breaks smtplib.starttls() Message-ID: Bugs item #1098618, was opened at 2005-01-08 14: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=1098618&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: socket.setdefaulttimeout() breaks smtplib.starttls() Initial Comment: If you use socket.setdefaulttimeout() to set a socket timeout, and then do smtplib.starttls(), no data is read after TLS is started. Here's a session that's as you'd expect: >>> import smtplib >>> s=smtplib.SMTP("smtp.example.com") >>> s.set_debuglevel(1) >>> s.helo() send: 'helo mint-julep.mondoinfo.com\r\n' reply: '250 smtpout-1.example.net\r\n' reply: retcode (250); Msg: smtpout-1.example.net (250, 'smtpout-1.example.net') >>> s.starttls() send: 'STARTTLS\r\n' reply: '220 Ready to start TLS\r\n' reply: retcode (220); Msg: Ready to start TLS (220, 'Ready to start TLS') >>> s.ehlo() send: 'ehlo mint-julep.mondoinfo.com\r\n' reply: '250-smtpout-1.example.net\r\n' reply: '250-PIPELINING\r\n' reply: '250-SIZE 32768000\r\n' reply: '250-VRFY\r\n' reply: '250-ETRN\r\n' reply: '250-AUTH LOGIN PLAIN DIGEST-MD5\r\n' reply: '250-AUTH=LOGIN PLAIN DIGEST-MD5\r\n' reply: '250 8BITMIME\r\n' reply: retcode (250); Msg: smtpout-1.example.net PIPELINING SIZE 32768000 VRFY ETRN AUTH LOGIN PLAIN DIGEST-MD5 AUTH=LOGIN PLAIN DIGEST-MD5 8BITMIME (250, 'smtpout-1.example.net\nPIPELINING\nSIZE 32768000\nVRFY\nETRN\nAUTH LOGIN PLAIN DIGEST- MD5\nAUTH=LOGIN PLAIN DIGEST-MD5\n8BITMIME') >>> s.quit() send: 'quit\r\n' reply: '221 Bye\r\n' reply: retcode (221); Msg: Bye But if I set a socket timeout, I get this: >>> import socket >>> socket.setdefaulttimeout(30) >>> s=smtplib.SMTP("smtp.example.com") >>> s.set_debuglevel(1) >>> s.helo() send: 'helo mint-julep.mondoinfo.com\r\n' reply: '250 smtpout-1.example.net\r\n' reply: retcode (250); Msg: smtpout-1.example.net (250, 'smtpout-1.example.net') >>> s.starttls() send: 'STARTTLS\r\n' reply: '220 Ready to start TLS\r\n' reply: retcode (220); Msg: Ready to start TLS (220, 'Ready to start TLS') >>> s.ehlo() send: 'ehlo mint-julep.mondoinfo.com\r\n' ^CTraceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/smtplib.py", line 391, in ehlo (code,msg)=self.getreply() File "/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/smtplib.py", line 345, in getreply line = self.file.readline() File "/Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/smtplib.py", line 160, in readline chr = self.sslobj.read(1) KeyboardInterrupt (I waited ten or fifteen seconds before typing the control-c.) If I set the socket timeout back to None, it works correctly: >>> socket.setdefaulttimeout(None) >>> s=smtplib.SMTP("smtp.example.com") >>> s.helo() (250, 'smtpout-2.example.net') >>> s.starttls() (220, 'Ready to start TLS') >>> s.ehlo() (250, 'smtpout-2.example.net\nPIPELINING\nSIZE 32768000\nVRFY\nETRN\nAUTH LOGIN PLAIN DIGEST- MD5\nAUTH=LOGIN PLAIN DIGEST-MD5\n8BITMIME') >>> s.quit() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098618&group_id=5470 From noreply at sourceforge.net Sat Jan 8 23:41:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 8 23:41:25 2005 Subject: [ python-Bugs-1096310 ] sys.__stdout__ doco isn't discouraging enough Message-ID: Bugs item #1096310, was opened at 2005-01-05 04:18 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1096310&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: sys.__stdout__ doco isn't discouraging enough Initial Comment: sys.__stdout__ is quite often abused (two independent sightings on c.l.py yesterday): people use it to restore stdout instead of saving the previous stdout. The real intended use for __stdout__ isn't all that clear (I keep wondering myself why it's there in the first place; its use case must be quite obscure), but more importantly I think the sys docs should contain a warning that __stdout__ is *not* suitable to restore sys.stdout after redirection. I'd produce a patch if I knew how to better describe what sys.__stdout__ was *for*. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-08 17:41 Message: Logged In: YES user_id=149084 In IDLE it's useful for debugging: print>>sys.__stderr__, "!!!BOO!!!" will print a message to the console no matter what the redirection status is. So that's a use in addition to the two given in the sys module docs. Agreed that its bad practice to use them to restore redirection, but that IMO belongs in a tutorial, not the reference docs.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1096310&group_id=5470 From noreply at sourceforge.net Sun Jan 9 01:16:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 01:16:22 2005 Subject: [ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite Message-ID: Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ludootje (ludootje) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:16 Message: Logged In: YES user_id=469548 I checked in fixes for the problems you reported: 1. Fixed as you suggested. 2. Fixed as you suggested. 3. Split up the two into separate sentences. 4. It's "a Unicode" string. 'a' vs. 'an' is about pronunciation (e.g.: an MRI). So, fixed as you suggested. I'll close this bug now, but feel free to reopen it if you find anymore problems with the tutorial. ---------------------------------------------------------------------- Comment By: Ludootje (ludootje) Date: 2005-01-08 18:16 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: The small "u" in front of the quote indicates that an Unicode string is supposed to be created. Isn't it "a Unicode", instead of "an Unicode"? I wasn't too sure of this one, but Googling for both brings up much more results for "a Unicode", and, more importantly, the results are from more "official" entities (like unicode.org, for example). ---------------------------------------------------------------------- Comment By: Ludootje (ludootje) Date: 2005-01-08 18:06 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: "Previously, there were only 256 possible ordinals for script characters and texts were typically bound to a code page which mapped the ordinals to script characters." I'm not sure if I totally "get" this sentence, but if I do, adding a comma after "characters" (the first occurence of it) would make it more clear or readable, IMHO. This would lead to: "Previously, there were only 256 possible ordinals for script characters, and texts were typically bound to a code page which mapped the ordinals to script characters." Just a thought. ---------------------------------------------------------------------- Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 From noreply at sourceforge.net Sun Jan 9 01:18:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 01:19:09 2005 Subject: [ python-Bugs-1081879 ] Pydoc can't find browser (bug+solution!) Message-ID: Bugs item #1081879, was opened at 2004-12-09 06:14 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470 >Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stewart Midwinter (midtoad) Assigned to: Nobody/Anonymous (nobody) Summary: Pydoc can't find browser (bug+solution!) Initial Comment: I've got Python 2.3 installed on Mandrake Linux 10.1 with KDE 3.2 running. When I run "pydoc -g" and search on any term, if I try to display the relevant documentation, pydoc throws an exception: Traceback (most recent call last): File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/usr/lib/python2.3/pydoc.py", line 1970, in open webbrowser.open(url) File "/usr/lib/python2.3/webbrowser.py", line 43, in open get().open(url, new, autoraise) File "/usr/lib/python2.3/webbrowser.py", line 38, in get raise Error("could not locate runnable browser") Error: could not locate runnable browser I did some research and found that the problem is that KDE sets the BROWSER environment variable to an unexpected value: BROWSER='kfmclient openProfile webbrowsing' The solution would be to test for this strange setting. I patched webbrowser.py on my system in an inelegant fashion by simply inserting the following code at the top of the file, just after the 'import' statements: #patch for KDE mangling of BROWSER environment variable #per: http://mail.python.org/pipermail/tutor/2004-September/032060.html if os.environ.has_key("BROWSER") and \ os.environ["BROWSER"]=='kfmclient openProfile webbrowsing': os.environ["BROWSER"] = 'konqueror' # set it to konqueror ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470 From noreply at sourceforge.net Sun Jan 9 01:40:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 01:40:12 2005 Subject: [ python-Bugs-1010196 ] xml.dom documentation omits hasAttribute, hasAttributeNS Message-ID: Bugs item #1010196, was opened at 2004-08-16 20:12 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010196&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: xml.dom documentation omits hasAttribute, hasAttributeNS Initial Comment: http://www.python.org/doc/2.3.4/lib/dom-element- objects.html does not mention hasAttribute() and hasAttributeNS(), which are DOM L2 Core methods present on Element objects. They should be mentioned not just for completeness, but also so that people are not tempted to use getAttribute() and getAttributeNS() to test for attribute existence. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:40 Message: Logged In: YES user_id=469548 Fixed by applying patch #1051321. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-21 10:40 Message: Logged In: YES user_id=371366 OK, submitted as patch # 1051321 https://sourceforge.net/tracker/index.php?func=detail&aid=1051321&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:29 Message: Logged In: YES user_id=80475 Can you draft a patch? For the LaTeX markup, just mimic the surrounding text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010196&group_id=5470 From noreply at sourceforge.net Sun Jan 9 01:40:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 01:40:37 2005 Subject: [ python-Bugs-1013525 ] xml.dom documentation omits createDocument, ...DocumentType Message-ID: Bugs item #1013525, was opened at 2004-08-21 22:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013525&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: xml.dom documentation omits createDocument, ...DocumentType Initial Comment: http://www.python.org/doc/2.3.4/lib/dom- implementation-objects.html mentions that DOM L2 Core methods exist on DomImplementation objects to create Document and DocumentType objects, but does not say what the methods are, nor does it adequately document the one method that is documented: hasFeature(). The documentation should be updated to say what hasFeature does with its arguments and what it returns. Documentation for the createDocument() and createDocumentType() methods should be added to this page as well. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:40 Message: Logged In: YES user_id=469548 Fixed by applying patch 1051321. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013525&group_id=5470 From noreply at sourceforge.net Sun Jan 9 01:43:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 01:43:08 2005 Subject: [ python-Bugs-991805 ] Documentation of DOMImplmentation lacking Message-ID: Bugs item #991805, was opened at 2004-07-15 20:37 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Documentation of DOMImplmentation lacking Initial Comment: The documentation for DOMImplementation is lacking. While I realize that there are several possible DOMImplementations, the default one seems to have no documentation. If it is documented, a cross reference needs to be made on the minidom documentation (Section 13.7), where DOMImplementation.createDocument is referenced. I want to know what the arguments are supposed to be. Examples are great, but they don't replace documentation. p.s. Barry made me do it. :) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:43 Message: Logged In: YES user_id=469548 This should be fixed by patch #1051321. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470 From noreply at sourceforge.net Sun Jan 9 02:08:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 02:08:53 2005 Subject: [ python-Bugs-886619 ] wrong documentation for popen2 Message-ID: Bugs item #886619, was opened at 2004-01-29 01:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886619&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Serge Winitzki (winitzki) Assigned to: Nobody/Anonymous (nobody) Summary: wrong documentation for popen2 Initial Comment: the python 2.3.3 library documentation for popen2 says: ( file:///usr/share/doc/python2.3/html/lib/module-popen2.html) popen2( cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects (child_stdout, child_stdin). however, the actual behavior of python 2.3.3 is to return (child_stdin, child_stdout) - in the reverse order. I haven't checked with popen3 and popen4. thanks. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:08 Message: Logged In: YES user_id=469548 This has either been fixed in Python 2.4, or you're confusing popen2.popen2 with os.popen2, which does return the file objects in the order you describe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886619&group_id=5470 From noreply at sourceforge.net Sun Jan 9 02:27:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 02:27:27 2005 Subject: [ python-Bugs-489256 ] Lib/profile.doc should be updated Message-ID: Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 From noreply at sourceforge.net Sun Jan 9 02:41:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 02:41:28 2005 Subject: [ python-Bugs-1017546 ] test_inspect.py fails to clean up upon failure Message-ID: Bugs item #1017546, was opened at 2004-08-27 14:20 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael (ms_) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect.py fails to clean up upon failure Initial Comment: When test_inspect.py encounters a failure in the code it's testing it fails to clean up its temporary files upon exit. This causes spurious errors for other tests when debugging. eg: force a test to fail by changing test_inspect.py such that this: test(inspect.getsource(mod2.wrapped) == sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Is replaced with: test(inspect.getsource(mod2.wrapped) != sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Clearly this should only cause test_inspect.py to fail, however: # ./python Lib/test/regrtest.py test_inspect test_posixpath test_inspect test test_inspect failed -- inspect.getsource(mod.wrapped) test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/home/michaels/Python/Cvs/python/dist/src/Lib/test/test_posixpath.py", line 148, in test_islink os.symlink(test_support.TESTFN + "1", test_support.TESTFN + "2") OSError: [Errno 17] File exists 2 tests failed: test_inspect test_posixpath In this example the reason why test_posixpath failed is due to the temporary files left behind by the failed test_inspect. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:41 Message: Logged In: YES user_id=469548 The new test_inspect no longer writes temporary files, so I'm closing this bug. ---------------------------------------------------------------------- Comment By: Michael (ms_) Date: 2004-08-27 14:27 Message: Logged In: YES user_id=994316 Patch against current Anon CVS can be found here: * http://www.python.org/sf/1017550 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 From noreply at sourceforge.net Sun Jan 9 02:50:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 02:50:33 2005 Subject: [ python-Bugs-769569 ] weird/buggy inspect.getsource behavious Message-ID: Bugs item #769569, was opened at 2003-07-11 12:42 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: weird/buggy inspect.getsource behavious Initial Comment: Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python 2.2.3 (correction for lambda keyword), I run the following code """ import inspect a = [ None, lambda x: x>1 and x<0, None] print "Ok",inspect.getsource(a[1]) if 1: a = [ None, lambda x: x>1 and x<0, None] print "Ko",inspect.getsource(a[1]) """ Two weird behaviours occurs 1. The line "print "Ok",inspect.getsource(a[1])" prints Ok lambda x: x>1 and x<0, None] It prints a superfluous line. 2. The line "print "Ko",inspect.getsource(a[1])" raises an exception Ko Traceback (most recent call last): File "bug-inspect.py", line 13, in ? print "Ko",inspect.getsource(a[1]) File "/usr/lib/python2.2/inspect.py", line 523, in getsource lines, lnum = getsourcelines(object) File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines else: return getblock(lines[lnum:]), lnum + 1 File "/usr/lib/python2.2/inspect.py", line 498, in getblock tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater) File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize tokenize_loop(readline, tokeneater) File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop for token_info in generate_tokens(readline): File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens raise TokenError, ("EOF in multi-line statement", (lnum, 0)) tokenize.TokenError: ('EOF in multi-line statement', (7, 0)) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:50 Message: Logged In: YES user_id=469548 Since patch #1011890 has been checked in, and problem 2 is unreproducable, I'm closing this. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2004-08-19 03:14 Message: Logged In: YES user_id=329382 http://www.python.org/sf/1011890 fixes problem 1. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-15 14:57 Message: Logged In: YES user_id=469548 I can't reproduce problem 2 on today's CVS, but http://python.org/sf/1006219 fixes problem 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 From noreply at sourceforge.net Sun Jan 9 03:17:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 03:17:41 2005 Subject: [ python-Bugs-769569 ] weird/buggy inspect.getsource behavious Message-ID: Bugs item #769569, was opened at 2003-07-11 12:42 Message generated for change (Comment added) made by percivall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: weird/buggy inspect.getsource behavious Initial Comment: Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python 2.2.3 (correction for lambda keyword), I run the following code """ import inspect a = [ None, lambda x: x>1 and x<0, None] print "Ok",inspect.getsource(a[1]) if 1: a = [ None, lambda x: x>1 and x<0, None] print "Ko",inspect.getsource(a[1]) """ Two weird behaviours occurs 1. The line "print "Ok",inspect.getsource(a[1])" prints Ok lambda x: x>1 and x<0, None] It prints a superfluous line. 2. The line "print "Ko",inspect.getsource(a[1])" raises an exception Ko Traceback (most recent call last): File "bug-inspect.py", line 13, in ? print "Ko",inspect.getsource(a[1]) File "/usr/lib/python2.2/inspect.py", line 523, in getsource lines, lnum = getsourcelines(object) File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines else: return getblock(lines[lnum:]), lnum + 1 File "/usr/lib/python2.2/inspect.py", line 498, in getblock tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater) File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize tokenize_loop(readline, tokeneater) File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop for token_info in generate_tokens(readline): File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens raise TokenError, ("EOF in multi-line statement", (lnum, 0)) tokenize.TokenError: ('EOF in multi-line statement', (7, 0)) ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-09 03:17 Message: Logged In: YES user_id=329382 Bug 2 is reproducable in Python 2.4, but not in CVS head, which stands to reason, since the latest patch to BlockFinder was meant to deal with these issues. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:50 Message: Logged In: YES user_id=469548 Since patch #1011890 has been checked in, and problem 2 is unreproducable, I'm closing this. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2004-08-19 03:14 Message: Logged In: YES user_id=329382 http://www.python.org/sf/1011890 fixes problem 1. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-15 14:57 Message: Logged In: YES user_id=469548 I can't reproduce problem 2 on today's CVS, but http://python.org/sf/1006219 fixes problem 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 From noreply at sourceforge.net Sun Jan 9 03:23:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 03:23:51 2005 Subject: [ python-Bugs-769569 ] weird/buggy inspect.getsource behavious Message-ID: Bugs item #769569, was opened at 2003-07-11 12:42 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: weird/buggy inspect.getsource behavious Initial Comment: Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python 2.2.3 (correction for lambda keyword), I run the following code """ import inspect a = [ None, lambda x: x>1 and x<0, None] print "Ok",inspect.getsource(a[1]) if 1: a = [ None, lambda x: x>1 and x<0, None] print "Ko",inspect.getsource(a[1]) """ Two weird behaviours occurs 1. The line "print "Ok",inspect.getsource(a[1])" prints Ok lambda x: x>1 and x<0, None] It prints a superfluous line. 2. The line "print "Ko",inspect.getsource(a[1])" raises an exception Ko Traceback (most recent call last): File "bug-inspect.py", line 13, in ? print "Ko",inspect.getsource(a[1]) File "/usr/lib/python2.2/inspect.py", line 523, in getsource lines, lnum = getsourcelines(object) File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines else: return getblock(lines[lnum:]), lnum + 1 File "/usr/lib/python2.2/inspect.py", line 498, in getblock tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater) File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize tokenize_loop(readline, tokeneater) File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop for token_info in generate_tokens(readline): File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens raise TokenError, ("EOF in multi-line statement", (lnum, 0)) tokenize.TokenError: ('EOF in multi-line statement', (7, 0)) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 03:23 Message: Logged In: YES user_id=469548 Hmm, I couldn't and can't reproduce problem 2 under Python 2.4(.0). But this should be moot, as your BlockFinder patch will be in 2.4.1. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-09 03:17 Message: Logged In: YES user_id=329382 Bug 2 is reproducable in Python 2.4, but not in CVS head, which stands to reason, since the latest patch to BlockFinder was meant to deal with these issues. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:50 Message: Logged In: YES user_id=469548 Since patch #1011890 has been checked in, and problem 2 is unreproducable, I'm closing this. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2004-08-19 03:14 Message: Logged In: YES user_id=329382 http://www.python.org/sf/1011890 fixes problem 1. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-15 14:57 Message: Logged In: YES user_id=469548 I can't reproduce problem 2 on today's CVS, but http://python.org/sf/1006219 fixes problem 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 From noreply at sourceforge.net Sun Jan 9 03:26:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 03:26:05 2005 Subject: [ python-Bugs-489256 ] Lib/profile.doc should be updated Message-ID: Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 From noreply at sourceforge.net Sun Jan 9 10:26:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 10:26:21 2005 Subject: [ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header Message-ID: Bugs item #1097597, was opened at 2005-01-06 18:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Schachter (razmatazz) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer sends wrong Content-Length header Initial Comment: On Microsoft Windows, text files use \r\n for newline. The SimpleHTTPServer class's "send_head()" method opens files with "r" or "rb" mode depending on the MIME type. Files opened in "r" mode will have \r\n -> \n translation performed automatically, so the stream of bytes sent to the client will be smaller than the size of the file on disk. Unfortunately, the send_head() method sets the Content-Length header using the file size on disk, without compensating for the \r\n -> \n translation. I remedied this on my copy thusly: if mode == "r": content = f.read() contentLength = str(len(content)) f.seek(0) else: contentLength = str(os.fstat(f.fileno())[6]) self.send_header("Content-Length", contentLength) This may not be as inefficient as it seems: the entire file was going to be read in anyway for the newline translation. Hmmm. The code could be slightly simpler: if mode == "r": contentLength = len(f.read()) f.seek(0) else: contentLength = os.fstat(f.fileno())[6] self.send_header("Content-Length", str(contentLength)) The documentation for SimpleHTTPServer in Python 2.3.4 for Windows says: A 'Content-type:' with the guessed content type is output, and then a blank line, signifying end of headers, and then the contents of the file. The file is always opened in binary mode. Actually, after Content-type, the Content-Length header is sent. It would probably be nice if "Content-Length" was "Content-length" or if "Content-type" was "Content-Type", for consistency. The latter is probably best, per RFC 2016. By the way, clients weren't caching the files I sent. I added another line after the Content-Length handling: self.send_header("Expires", "Fri, 31 Dec 2100 12:00:00 GMT") This is egregiously wrong in the general case and just fine in my case. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-09 01:26 Message: Logged In: YES user_id=341410 Would it be wrong to open all files with a mode of 'rb', regardless of file type? While I don't know MIME embeddings all that well, I do have experience with email and that most codecs that use MIME embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n agnostic.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 From noreply at sourceforge.net Sun Jan 9 14:53:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 14:53:21 2005 Subject: [ python-Bugs-1093173 ] distutils/tests not installed Message-ID: Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:53 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 14:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 From noreply at sourceforge.net Sun Jan 9 14:55:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 14:55:16 2005 Subject: [ python-Bugs-1093173 ] distutils/tests not installed Message-ID: Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:55 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:53 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 14:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 From noreply at sourceforge.net Sun Jan 9 15:03:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 15:03:37 2005 Subject: [ python-Bugs-1093173 ] distutils/tests not installed Message-ID: Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-01-09 14:03 Message: Logged In: YES user_id=4771 Attachment was corrupted?? Second try... ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:55 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:53 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 14:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 From noreply at sourceforge.net Sun Jan 9 15:56:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 15:56:09 2005 Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers Message-ID: Bugs item #994101, was opened at 2004-07-19 23:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Sayre (franklinmint) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: improper capitalization of headers Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". This causes HTTP 400 errors on some servers when the request has a body, because there are two content length headers placed in the request: "Content-Length" (inserted by httplib) "Content-length" (inserted by Request.add_unredirected_header) The capitalization is incorrect, and httplib inserts Content-Length anyway, so I'm not sure why urllib2 is bothering. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 15:56 Message: Logged In: YES user_id=469548 This was fixed by the new patch jjlee provided (#997626). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-25 20:06 Message: Logged In: YES user_id=261020 I've added a comment to 996159 which explains what's wrong and points to a new patch. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-22 22:48 Message: Logged In: YES user_id=469548 Patch is available at http://python.org/sf/996159. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 From noreply at sourceforge.net Sun Jan 9 16:33:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 16:33:08 2005 Subject: [ python-Bugs-548176 ] urlparse doesn't handle host?bla Message-ID: Bugs item #548176, was opened at 2002-04-24 17:36 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Markus Demleitner (msdemlei) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse doesn't handle host?bla Initial Comment: The urlparse module (at least in 2.2 and 2.1, Linux) doesn't handle URLs of the form http://www.maerkischeallgemeine.de?loc_id=49 correctly -- everything up to the 9 ends up in the host. I didn't check the RFC, but in the real world URLs like this do show up. urlparse works fine when there's a trailing slash on the host name: http://www.maerkischeallgemeine.de/?loc_id=49 Example: <pre> >>> import urlparse >>> urlparse.urlparse("http://www.maerkischeallgemeine.de/?loc_id=49") ('http', 'www.maerkischeallgemeine.de', '/', '', 'loc_id=49', '') >>> urlparse.urlparse("http://www.maerkischeallgemeine.de?loc_id=49") ('http', 'www.maerkischeallgemeine.de?loc_id=49', '', '', '', '') </pre> This has serious implications for urllib, since urllib.urlopen will fail for URLs like the second one, and with a pretty mysterious exception ("host not found") at that. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 16:33 Message: Logged In: YES user_id=469548 Fixed by applying patch #712317 on maint24 and HEAD. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-11-08 21:48 Message: Logged In: YES user_id=113328 This issue still exists in Python 2.3.4 and Python 2.4b2. ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2004-10-23 09:44 Message: Logged In: YES user_id=162094 I'm sorry, I misunderstood the patch. If it accepts such URL and split it at '?', it's perfectly fine. It shall not reject such URL as malformed. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-23 09:03 Message: Logged In: YES user_id=469548 Somehow I think I'm missing something. Please check my line of reasoning: 1. http://foo?bar=baz is a legal URL. 2. urlparse's 'Network location' should be the same as from rfc2396. 3. Inside an unescaped '?' is not allowed. Rather: is terminated by the '?'. 4. Currently the 'network location' for http://foo?bar=baz would be 'foo?bar=baz. 5. If 'network location' should be the same as , it should also be terminated by the '?'. So shouldn't urlparse.urlsplit('http://foo?bar=baz') return ('http', 'foo', '', '', 'bar=baz', ''), as patch 712317 implements? ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2004-01-27 02:13 Message: Logged In: YES user_id=162094 According to RFC2396 (ftp://ftp.isi.edu/in-notes/rfc2396.txt) absoluteURI (part 3 URI Syntactic Components) can be: """ ://? each of which, except , may be absent from a particular URI. """ Later on (3.2): """ The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. """ So URL "http://server?query" is perfectly legal and shall be allowed and patch 712317 rejected. ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-03-30 22:19 Message: Logged In: YES user_id=666873 For comparison, RFC 1738 section 3.3: An HTTP URL takes the form: http://<host>:<port>/<path>?<searchpart> [...] If neither <path> nor <searchpart> is present, the "/" may also be omitted. ... which does not outright say the '/' may *not* be omitted if <path> is absent but <searchpart> is present (though imho that's implied). But even if the / may not be omitted in this case, ? is not allowed in the authority component under either RFC 2396 or RFC 1738, so urlparse should either treat it as a delimiter or reject the URL as malformed. The principle of being lenient in what you accept favours the former. I've just submitted a patch (712317) for this. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 17:56 Message: Logged In: YES user_id=2772 This actually appears to be permitted by RFC2396 [http://www.ietf.org/rfc/rfc2396.txt]. See section 3.2: 3.2. Authority Component Many URI schemes include a top hierarchical element for a naming authority, such that the namespace defined by the remainder of the URI is governed by that authority. This authority component is typically defined by an Internet-based server or a scheme-specific registry of naming authorities. authority = server | reg_name The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470 From noreply at sourceforge.net Sun Jan 9 17:28:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 17:28:17 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Sun Jan 9 17:45:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 17:46:02 2005 Subject: [ python-Bugs-1098990 ] codec readline() splits lines apart Message-ID: Bugs item #1098990, was opened at 2005-01-09 17:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&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: codec readline() splits lines apart Initial Comment: It seems that the fix for bug 1076985 (Incorrect behaviour of StreamReader.readline leads to crash) has introduced a new bug. using current cvs Python on Linux, I observe faulty behavior of the readline() method on file-like objects returned from the codecs module. See the attached example.txt. The readline() breaks certain lines in half. It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 From noreply at sourceforge.net Sun Jan 9 17:48:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 17:48:58 2005 Subject: [ python-Bugs-1095821 ] The doc for DictProxy is missing Message-ID: Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-09 11:48 Message: Logged In: YES user_id=11365 DictProxy is an implementation detail, perhaps it should have been left out of types. I notice there is no CellType in there. (you can obtain this type like so:) >>> type((lambda x: lambda: x)(1).func_closure[0]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 From noreply at sourceforge.net Sun Jan 9 18:18:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 18:18:39 2005 Subject: [ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header Message-ID: Bugs item #1097597, was opened at 2005-01-07 03:34 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Schachter (razmatazz) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer sends wrong Content-Length header Initial Comment: On Microsoft Windows, text files use \r\n for newline. The SimpleHTTPServer class's "send_head()" method opens files with "r" or "rb" mode depending on the MIME type. Files opened in "r" mode will have \r\n -> \n translation performed automatically, so the stream of bytes sent to the client will be smaller than the size of the file on disk. Unfortunately, the send_head() method sets the Content-Length header using the file size on disk, without compensating for the \r\n -> \n translation. I remedied this on my copy thusly: if mode == "r": content = f.read() contentLength = str(len(content)) f.seek(0) else: contentLength = str(os.fstat(f.fileno())[6]) self.send_header("Content-Length", contentLength) This may not be as inefficient as it seems: the entire file was going to be read in anyway for the newline translation. Hmmm. The code could be slightly simpler: if mode == "r": contentLength = len(f.read()) f.seek(0) else: contentLength = os.fstat(f.fileno())[6] self.send_header("Content-Length", str(contentLength)) The documentation for SimpleHTTPServer in Python 2.3.4 for Windows says: A 'Content-type:' with the guessed content type is output, and then a blank line, signifying end of headers, and then the contents of the file. The file is always opened in binary mode. Actually, after Content-type, the Content-Length header is sent. It would probably be nice if "Content-Length" was "Content-length" or if "Content-type" was "Content-Type", for consistency. The latter is probably best, per RFC 2016. By the way, clients weren't caching the files I sent. I added another line after the Content-Length handling: self.send_header("Expires", "Fri, 31 Dec 2100 12:00:00 GMT") This is egregiously wrong in the general case and just fine in my case. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 18:18 Message: Logged In: YES user_id=469548 http://python.org/sf/839496 has a patch for this, but the submitter isn't sure whetther it's correct. Maybe one of you could take a look at it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-09 10:26 Message: Logged In: YES user_id=341410 Would it be wrong to open all files with a mode of 'rb', regardless of file type? While I don't know MIME embeddings all that well, I do have experience with email and that most codecs that use MIME embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n agnostic.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 From noreply at sourceforge.net Sun Jan 9 19:29:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 9 19:29:58 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Mon Jan 10 01:49:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 01:49:23 2005 Subject: [ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header Message-ID: Bugs item #1097597, was opened at 2005-01-07 03:34 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Schachter (razmatazz) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer sends wrong Content-Length header Initial Comment: On Microsoft Windows, text files use \r\n for newline. The SimpleHTTPServer class's "send_head()" method opens files with "r" or "rb" mode depending on the MIME type. Files opened in "r" mode will have \r\n -> \n translation performed automatically, so the stream of bytes sent to the client will be smaller than the size of the file on disk. Unfortunately, the send_head() method sets the Content-Length header using the file size on disk, without compensating for the \r\n -> \n translation. I remedied this on my copy thusly: if mode == "r": content = f.read() contentLength = str(len(content)) f.seek(0) else: contentLength = str(os.fstat(f.fileno())[6]) self.send_header("Content-Length", contentLength) This may not be as inefficient as it seems: the entire file was going to be read in anyway for the newline translation. Hmmm. The code could be slightly simpler: if mode == "r": contentLength = len(f.read()) f.seek(0) else: contentLength = os.fstat(f.fileno())[6] self.send_header("Content-Length", str(contentLength)) The documentation for SimpleHTTPServer in Python 2.3.4 for Windows says: A 'Content-type:' with the guessed content type is output, and then a blank line, signifying end of headers, and then the contents of the file. The file is always opened in binary mode. Actually, after Content-type, the Content-Length header is sent. It would probably be nice if "Content-Length" was "Content-length" or if "Content-type" was "Content-Type", for consistency. The latter is probably best, per RFC 2016. By the way, clients weren't caching the files I sent. I added another line after the Content-Length handling: self.send_header("Expires", "Fri, 31 Dec 2100 12:00:00 GMT") This is egregiously wrong in the general case and just fine in my case. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-10 01:49 Message: Logged In: YES user_id=129426 http://sourceforge.net/support/tracker.php?aid=839496 is a better url because it has been moved. I've added a comment to my patch, because I'm now quite sure it is good after all. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 18:18 Message: Logged In: YES user_id=469548 http://python.org/sf/839496 has a patch for this, but the submitter isn't sure whetther it's correct. Maybe one of you could take a look at it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-09 10:26 Message: Logged In: YES user_id=341410 Would it be wrong to open all files with a mode of 'rb', regardless of file type? While I don't know MIME embeddings all that well, I do have experience with email and that most codecs that use MIME embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n agnostic.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 From noreply at sourceforge.net Mon Jan 10 03:09:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 03:09:54 2005 Subject: [ python-Bugs-1095821 ] The doc for DictProxy is missing Message-ID: Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 21:09 Message: Logged In: YES user_id=285587 I suggest that it would be better to indicate the purpose and usage of both CellType in the Library Reference. If one is to keep it under the pillow, it should be complete and uptodate. Colin W. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-09 11:48 Message: Logged In: YES user_id=11365 DictProxy is an implementation detail, perhaps it should have been left out of types. I notice there is no CellType in there. (you can obtain this type like so:) >>> type((lambda x: lambda: x)(1).func_closure[0]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 From noreply at sourceforge.net Mon Jan 10 04:07:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 04:07:32 2005 Subject: [ python-Bugs-489256 ] Lib/profile.doc should be updated Message-ID: Bugs item #489256, was opened at 2001-12-05 00:51 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470\\ Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-09 22:07 Message: Logged In: YES user_id=3066 Removing profile.doc sounds fine to me. The only thing that really needs to be done prior to removal is to make sure all the (still current) information in profile.doc is represented in the library documentation. The help() function should probably be replaced with something that refers the user to the library documentation, rather than removing the function. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 20:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 01:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470\\ From noreply at sourceforge.net Mon Jan 10 08:56:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 08:56:09 2005 Subject: [ python-Bugs-756982 ] mailbox should use email not rfc822 Message-ID: Bugs item #756982, was opened at 2003-06-19 12:19 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Leslie (benno37) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox should use email not rfc822 Initial Comment: The mailbox module uses the rfc822 module as its default factory for creating message objects. The rfc822 documentation claims that its use is deprecated. The mailbox module should probably use the new email module as its default factory. Of course this has backward compatibility issues, in which case it should at least be mentioned in the mailbox documentation that it uses the deprecated rfc822 module, and provide an example of how to use the email module instead. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-01-10 18:56 Message: Logged In: YES user_id=29957 Given the amount of code out there using rfc822, should we instead PDW it? In any case, I'm -0 on putting a DeprecationWarning on it unless we've removed all use of it from the stdlib. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-01-09 02:49 Message: Logged In: YES user_id=12800 It's a good question. I'd like to say yes so that we can start adding deprecation warnings to rfc822 for Python 2.5. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:22 Message: Logged In: YES user_id=469548 So, with the plans to seriously start working deprecating rfc822, should we use the email module as the default factory now? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-21 07:48 Message: Logged In: YES user_id=12800 I've added some sample code to the mailbox documentation that explain how to use the email package with the mailbox module. We can't change the default for backward compatibility reasons, as you point out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 From noreply at sourceforge.net Mon Jan 10 10:07:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 10:07:45 2005 Subject: [ python-Bugs-489256 ] Lib/profile.doc should be updated Message-ID: Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 10:07 Message: Logged In: YES user_id=469548 I just checked and there was no information in profile.doc that wasn't in the library reference, so I've removed it now. I've also replaced help() along the lines of what you suggested. Just one more question: could we remove the "How Is This Profiler Different From The Old Profiler?" subsection from the library reference? It's hardly relevant, considering that the Old Profiler was last seen in Python 1.1 (!). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-10 04:07 Message: Logged In: YES user_id=3066 Removing profile.doc sounds fine to me. The only thing that really needs to be done prior to removal is to make sure all the (still current) information in profile.doc is represented in the library documentation. The help() function should probably be replaced with something that refers the user to the library documentation, rather than removing the function. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 From noreply at sourceforge.net Mon Jan 10 10:17:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 10:17:18 2005 Subject: [ python-Bugs-1099324 ] Optik OptionParse important undocumented option Message-ID: Bugs item #1099324, was opened at 2005-01-10 04: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=1099324&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ncouture (nicolas_couture) Assigned to: Nobody/Anonymous (nobody) Summary: Optik OptionParse important undocumented option Initial Comment: the add_help_option variable is undocumented in Python's Library Reference, tho it can be figured by reading the optparse module, I think it would be usefull to document it on http://docs.python.org/lib/optparse-generating-help.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 From noreply at sourceforge.net Mon Jan 10 10:29:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 10:29:14 2005 Subject: [ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header Message-ID: Bugs item #1097597, was opened at 2005-01-07 03:34 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 >Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Schachter (razmatazz) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: SimpleHTTPServer sends wrong Content-Length header Initial Comment: On Microsoft Windows, text files use \r\n for newline. The SimpleHTTPServer class's "send_head()" method opens files with "r" or "rb" mode depending on the MIME type. Files opened in "r" mode will have \r\n -> \n translation performed automatically, so the stream of bytes sent to the client will be smaller than the size of the file on disk. Unfortunately, the send_head() method sets the Content-Length header using the file size on disk, without compensating for the \r\n -> \n translation. I remedied this on my copy thusly: if mode == "r": content = f.read() contentLength = str(len(content)) f.seek(0) else: contentLength = str(os.fstat(f.fileno())[6]) self.send_header("Content-Length", contentLength) This may not be as inefficient as it seems: the entire file was going to be read in anyway for the newline translation. Hmmm. The code could be slightly simpler: if mode == "r": contentLength = len(f.read()) f.seek(0) else: contentLength = os.fstat(f.fileno())[6] self.send_header("Content-Length", str(contentLength)) The documentation for SimpleHTTPServer in Python 2.3.4 for Windows says: A 'Content-type:' with the guessed content type is output, and then a blank line, signifying end of headers, and then the contents of the file. The file is always opened in binary mode. Actually, after Content-type, the Content-Length header is sent. It would probably be nice if "Content-Length" was "Content-length" or if "Content-type" was "Content-Type", for consistency. The latter is probably best, per RFC 2016. By the way, clients weren't caching the files I sent. I added another line after the Content-Length handling: self.send_header("Expires", "Fri, 31 Dec 2100 12:00:00 GMT") This is egregiously wrong in the general case and just fine in my case. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 10:29 Message: Logged In: YES user_id=469548 Okay, fixed on maint24 and HEAD by applying patch 839496. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-10 01:49 Message: Logged In: YES user_id=129426 http://sourceforge.net/support/tracker.php?aid=839496 is a better url because it has been moved. I've added a comment to my patch, because I'm now quite sure it is good after all. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 18:18 Message: Logged In: YES user_id=469548 http://python.org/sf/839496 has a patch for this, but the submitter isn't sure whetther it's correct. Maybe one of you could take a look at it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-09 10:26 Message: Logged In: YES user_id=341410 Would it be wrong to open all files with a mode of 'rb', regardless of file type? While I don't know MIME embeddings all that well, I do have experience with email and that most codecs that use MIME embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n agnostic.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470 From noreply at sourceforge.net Mon Jan 10 11:33:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 11:33:18 2005 Subject: [ python-Bugs-1099363 ] refman doesn't know about universal newlines Message-ID: Bugs item #1099363, was opened at 2005-01-10 11: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=1099363&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: refman doesn't know about universal newlines Initial Comment: The reference manual (in ref/ref2.tex) still talks about the various different end-of-line conventions, but as Python reads source code with universal newlines this is no longer relevant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099363&group_id=5470 From noreply at sourceforge.net Mon Jan 10 11:33:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 11:33:26 2005 Subject: [ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt Message-ID: Bugs item #1099364, was opened at 2005-01-10 11: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=1099364&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: raw_input() displays wrong unicode prompt Initial Comment: I have observed a problem when running Python 2.4, Windows version (python-2.4.msi) and using raw_input() with unicode prompt string in a console program (ran in the DOS window). I do use the following sitecustomize.py file to set the default encoding in the English Windows 2000 Server: sitecustomize.py ================================= import sys sys.setdefaultencoding('cp1250') ================================= test.py ================================= # -*- coding: cp1250 -*- s = u'string with accented letters (different than this)' print s # OK val = raw_input(s) # s displayed differently (wrong) ================================= See the test.png (captured from screen) and the test.py for the used string -- inside the attached zip file. The "type test.py" (result visible on the captured screen) displays the string definition also wrongly, because the DOS window uses different encoding than cp1250. The print command prints the string correctly, converting the internal unicode string to the encoding that the is defined by the output environment. However, the raw_input() probably does convert the unicode string to the cp1250 and does not do the same (more clever) thing that the print does. I did not use the unicode in older Python (2.3.4), so I do not know what was the behaviour earlier. Could you confirm the bug? Sorry if the bug is well known. Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470 From noreply at sourceforge.net Mon Jan 10 12:15:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 12:15:07 2005 Subject: [ python-Bugs-1098990 ] codec readline() splits lines apart Message-ID: Bugs item #1098990, was opened at 2005-01-09 17:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&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: codec readline() splits lines apart Initial Comment: It seems that the fix for bug 1076985 (Incorrect behaviour of StreamReader.readline leads to crash) has introduced a new bug. using current cvs Python on Linux, I observe faulty behavior of the readline() method on file-like objects returned from the codecs module. See the attached example.txt. The readline() breaks certain lines in half. It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-01-10 12:15 Message: Logged In: YES user_id=89016 The problem is that the first readline() reads more than the first line, returns the first line and puts back the rest for the next read. The next call to readline() discovers that there is already data there and doesn't call read() again. I'm working on a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 From noreply at sourceforge.net Mon Jan 10 13:26:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 13:26:52 2005 Subject: [ python-Bugs-1098990 ] codec readline() splits lines apart Message-ID: Bugs item #1098990, was opened at 2005-01-09 17:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: codec readline() splits lines apart Initial Comment: It seems that the fix for bug 1076985 (Incorrect behaviour of StreamReader.readline leads to crash) has introduced a new bug. using current cvs Python on Linux, I observe faulty behavior of the readline() method on file-like objects returned from the codecs module. See the attached example.txt. The readline() breaks certain lines in half. It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-01-10 13:26 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.37 Lib/test/test_codecs.py 1.18 Lib/codecs.py 1.35.2.2 Lib/test/test_codecs.py 1.15.2.2 Thanks for the report! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-01-10 12:15 Message: Logged In: YES user_id=89016 The problem is that the first readline() reads more than the first line, returns the first line and puts back the rest for the next read. The next call to readline() discovers that there is already data there and doesn't call read() again. I'm working on a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 From noreply at sourceforge.net Mon Jan 10 13:32:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 13:32:18 2005 Subject: [ python-Bugs-1099324 ] Optik OptionParse important undocumented option Message-ID: Bugs item #1099324, was opened at 2005-01-10 04:17 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ncouture (nicolas_couture) >Assigned to: Greg Ward (gward) Summary: Optik OptionParse important undocumented option Initial Comment: the add_help_option variable is undocumented in Python's Library Reference, tho it can be figured by reading the optparse module, I think it would be usefull to document it on http://docs.python.org/lib/optparse-generating-help.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 From noreply at sourceforge.net Mon Jan 10 13:32:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 13:32:59 2005 Subject: [ python-Bugs-1095821 ] The doc for DictProxy is missing Message-ID: Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-10 07:32 Message: Logged In: YES user_id=11365 Currently the library reference contains minimal information on internal objects; here's the entire text of the relevant section: """ 2.3.10.10 Internal Objects See the Python Reference Manual for this information. It describes stack frame objects, traceback objects, and slice objects. """ Perhaps cell and dictproxy types should be added to the language reference manual. On the other hand, it isn't clear to me that absolute completeness is desirable. Any language or application has some undocumented features; the fact that they are not documented is a signal to the user that their use is not supported and they may go away without warning in future versions. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 21:09 Message: Logged In: YES user_id=285587 I suggest that it would be better to indicate the purpose and usage of both CellType in the Library Reference. If one is to keep it under the pillow, it should be complete and uptodate. Colin W. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-09 11:48 Message: Logged In: YES user_id=11365 DictProxy is an implementation detail, perhaps it should have been left out of types. I notice there is no CellType in there. (you can obtain this type like so:) >>> type((lambda x: lambda: x)(1).func_closure[0]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 From noreply at sourceforge.net Mon Jan 10 16:29:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 16:30:01 2005 Subject: [ python-Bugs-1099516 ] tempfile files not types.FileType Message-ID: Bugs item #1099516, was opened at 2005-01-10 16: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=1099516&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frans van Nieuwenhoven (vannieuwenhoven) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile files not types.FileType Initial Comment: a temporary file created with the tempfile module is not recognized as a types.FileType testcase: import types import tempfile # this will return False (I think it should return True) isinstance(tempfile.TemporaryFile(), types.FileType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099516&group_id=5470 From noreply at sourceforge.net Mon Jan 10 21:57:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 21:57:14 2005 Subject: [ python-Bugs-1099324 ] Optik OptionParse important undocumented option Message-ID: Bugs item #1099324, was opened at 2005-01-10 10:17 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ncouture (nicolas_couture) Assigned to: Greg Ward (gward) Summary: Optik OptionParse important undocumented option Initial Comment: the add_help_option variable is undocumented in Python's Library Reference, tho it can be figured by reading the optparse module, I think it would be usefull to document it on http://docs.python.org/lib/optparse-generating-help.html. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 21:57 Message: Logged In: YES user_id=469548 This should probably be addressed by fixing http://python.org/sf/993601. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 From noreply at sourceforge.net Mon Jan 10 22:28:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 10 22:28:22 2005 Subject: [ python-Bugs-1099746 ] copy.deepcopy barfs when copying a class derived from dict Message-ID: Bugs item #1099746, was opened at 2005-01-10 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099746&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Doug Winter (winjer) Assigned to: Nobody/Anonymous (nobody) Summary: copy.deepcopy barfs when copying a class derived from dict Initial Comment: I've got a class: class odict(dict): def __init__(self, d={}): self._keys = d.keys() dict.__init__(self, d) def __setitem__(self, key, item): dict.__setitem__(self, key, item) if key not in self._keys: self._keys.append(key) ... When I copy.deepcopy one of these it blows up in __setitem__ with an AttributeError on _keys, because __setitem__ is called without __init__ ever having been called. Presumably this thing looks and smells like a dictionary, so deepcopy thinks it is one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099746&group_id=5470 From noreply at sourceforge.net Tue Jan 11 01:17:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 01:17:51 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Guido van Rossum (gvanrossum) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Tue Jan 11 01:25:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 01:25:42 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library >Group: Python 2.5 Status: Open Resolution: None >Priority: 4 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Tue Jan 11 01:29:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 01:29:55 2005 Subject: [ python-Bugs-809254 ] imp.find_module doesn't work in /tmp Message-ID: Bugs item #809254, was opened at 2003-09-19 13:44 Message generated for change (Comment added) made by vng1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Victor T. Ng (vng1) Assigned to: Nobody/Anonymous (nobody) Summary: imp.find_module doesn't work in /tmp Initial Comment: I'm running OSX 10.2.6 and the imp module seems to have a parsing error when I pass it the directory "/" bash$ cd /tmp bash$ touch __init__.py bash$ python Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp",['/']) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named tmp >>> imp.find_module("tmp",['//']) (None, '//tmp', ('', '', 5)) I'm not sure why, but I seem to need a double slash in the directory name. ---------------------------------------------------------------------- >Comment By: Victor T. Ng (vng1) Date: 2005-01-11 00:29 Message: Logged In: YES user_id=679596 lima:~ buildbox$ cd /tmp lima:/tmp buildbox$ touch __init__.py lima:/tmp buildbox$ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp", ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 From noreply at sourceforge.net Tue Jan 11 01:31:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 01:31:30 2005 Subject: [ python-Bugs-809254 ] imp.find_module doesn't work in /tmp Message-ID: Bugs item #809254, was opened at 2003-09-19 13:44 Message generated for change (Comment added) made by vng1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Victor T. Ng (vng1) Assigned to: Nobody/Anonymous (nobody) Summary: imp.find_module doesn't work in /tmp Initial Comment: I'm running OSX 10.2.6 and the imp module seems to have a parsing error when I pass it the directory "/" bash$ cd /tmp bash$ touch __init__.py bash$ python Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp",['/']) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named tmp >>> imp.find_module("tmp",['//']) (None, '//tmp', ('', '', 5)) I'm not sure why, but I seem to need a double slash in the directory name. ---------------------------------------------------------------------- >Comment By: Victor T. Ng (vng1) Date: 2005-01-11 00:31 Message: Logged In: YES user_id=679596 Affects both Python 2.3 and Python 2.4 on OSX: Python 2.4 (#1, Dec 25 2004, 15:45:34) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module('tmp', ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- Comment By: Victor T. Ng (vng1) Date: 2005-01-11 00:29 Message: Logged In: YES user_id=679596 lima:~ buildbox$ cd /tmp lima:/tmp buildbox$ touch __init__.py lima:/tmp buildbox$ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp", ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 From noreply at sourceforge.net Tue Jan 11 01:32:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 01:32:25 2005 Subject: [ python-Bugs-809254 ] imp.find_module doesn't work in /tmp Message-ID: Bugs item #809254, was opened at 2003-09-19 13:44 Message generated for change (Comment added) made by vng1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Victor T. Ng (vng1) Assigned to: Nobody/Anonymous (nobody) Summary: imp.find_module doesn't work in /tmp Initial Comment: I'm running OSX 10.2.6 and the imp module seems to have a parsing error when I pass it the directory "/" bash$ cd /tmp bash$ touch __init__.py bash$ python Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp",['/']) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named tmp >>> imp.find_module("tmp",['//']) (None, '//tmp', ('', '', 5)) I'm not sure why, but I seem to need a double slash in the directory name. ---------------------------------------------------------------------- >Comment By: Victor T. Ng (vng1) Date: 2005-01-11 00:32 Message: Logged In: YES user_id=679596 No problems under Python 2.4 on Linux: Python 2.4 (#3, Dec 29 2004, 10:03:34) [GCC 3.3.4 (Debian 1:3.3.4-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module('tmp',['/']) (None, '/tmp', ('', '', 5)) >>> ---------------------------------------------------------------------- Comment By: Victor T. Ng (vng1) Date: 2005-01-11 00:31 Message: Logged In: YES user_id=679596 Affects both Python 2.3 and Python 2.4 on OSX: Python 2.4 (#1, Dec 25 2004, 15:45:34) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module('tmp', ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- Comment By: Victor T. Ng (vng1) Date: 2005-01-11 00:29 Message: Logged In: YES user_id=679596 lima:~ buildbox$ cd /tmp lima:/tmp buildbox$ touch __init__.py lima:/tmp buildbox$ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp", ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 From noreply at sourceforge.net Tue Jan 11 02:51:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 02:51:09 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:03:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:03:52 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:15:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:15:52 2005 Subject: [ python-Bugs-645594 ] for lin in file: file.tell() tells wrong Message-ID: Bugs item #645594, was opened at 2002-11-29 06:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: for lin in file: file.tell() tells wrong Initial Comment: Consider following piece of code: f = file("test.txt", "rb") pos = f.tell() for line in f: print "%u: '%s'" % (pos, line) pos = f.tell() During the code execution we have following result: 0 'Line 1' 63 'Line 2' 63 'Line 3' ... 63 'Line 9' However, following piece of code works fine: f = file("test.txt", "rb") while True: pos = f.tell() line = f.readline() if line == "": break print "%u: '%s'" % (pos, line) It prints: 0 'Line 1' 7 'Line 2' 14 'Line 3' ... 56 'Line 9' It seems a file iterator makes file.tell() to tell positions of some internal blocks used by the iterator. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:15 Message: Logged In: YES user_id=752496 Closing it, check bug 1036626 for rationale. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 16:29 Message: Logged In: YES user_id=469548 Closed accoding to rationale in #1036626. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-22 01:09 Message: Logged In: YES user_id=357491 As suggested by Just and Dimtry I am reclassifying this as a doc bug. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-01-08 07:17 Message: Logged In: YES user_id=388573 I agree. Unfortunately a small patch doesn't work here. :-( But I suggest to recategorize it as a documentation bug. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 18:25 Message: Logged In: YES user_id=92689 This bug is very similar to #524804, which was closed as "won't fix". Unless it's recategorized as a documentation bug, I suggest to close this one as a duplicate. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-12-04 08:24 Message: Logged In: YES user_id=388573 File.next() uses readahead buffer (8192 bytes for now). Calling file.seek() drops the buffer, but other operations don't. I think it's possible for file.tell() to return right result (I'll try to make a patch). But all these quirks should be documented. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-29 19:07 Message: Logged In: YES user_id=45365 Actually, all file operations behave the same (well, all: I tried one: readline():-): they behave as if the whole file has been read. I.e. file.readline() within a "for line in file" will return an empty string. If a file iterator behaves as if it has read the complete file at once on instantiation (never mind what it actually does: if it *behaves* as if this happens) I think this should just be documented and that's it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 13:57 Message: Logged In: YES user_id=31435 Possibly. Maybe something fancier could be done too, to give "expected" results. although I don't know how to approach that on Windows for text-mode files (byte arithmetic on seek/tell results doesn't work at all for those). I'd take it to Python-Dev. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-29 13:01 Message: Logged In: YES user_id=21627 Shouldn't tell raise an exception then? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 12:42 Message: Logged In: YES user_id=31435 "for x in file" does do its own chunking under the covers, for speed, and seek() and tell() are indeed not to be used on a file being iterated over in this way. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-29 11:46 Message: Logged In: YES user_id=388573 I'll try to dig in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-29 11:30 Message: Logged In: YES user_id=21627 Would you like to investigate this further? There is no need to, but if you find a solution and a patch, there is a better chance that this is fixed before 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:30:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:30:26 2005 Subject: [ python-Bugs-654783 ] doctest and exception messages Message-ID: Bugs item #654783, was opened at 2002-12-16 16:23 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Aahz (aahz) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 What should change Aahz in the docs? Not clear to me... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-23 19:01 Message: Logged In: YES user_id=3066 Tim sent this back to Aahz, so I'm assigning it to him as a reminder. ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-25 16:08 Message: Logged In: YES user_id=31435 Back to Aahz. I don't mind if you change this -- edit the docs and check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-16 20:39 Message: Logged In: YES user_id=31435 It could, but it shouldn't: error msgs in docs that don't match reality are also an insult to users. doctest should grow some sort of option here, though, as its uses outgrew its original purposes. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-16 19:01 Message: Logged In: YES user_id=35752 Couldn't doctest be modified so that it only compares the exception name only? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:34:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:34:44 2005 Subject: [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 13:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 19:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 13:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. ---------------------------------------------------------------------- Comment By: Dani (asqui) Date: 2003-01-12 13:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:48:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:49:08 2005 Subject: [ python-Bugs-672035 ] Py_Main() does not perform to spec Message-ID: Bugs item #672035, was opened at 2003-01-21 17:42 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_Main() does not perform to spec Initial Comment: I consider this a code bug, not a documentation issue as the documentation is the behavior we want. >From http://www.python.org/doc/current/api/veryhigh.html#l2h- 47 : int Py_Main(int argc, char **argv) The main program for the standard interpreter. This is made available for programs which embed Python. The argc and argv parameters should be prepared exactly as those which are passed to a C program's main() function. It is important to note that the argument list may be modified (but the contents of the strings pointed to by the argument list are not). The return value will be the integer passed to the sys.exit() function, 1 if the interpreter exits due to an exception, or 2 if the parameter list does not represent a valid Python command line. I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al In all cases the code will call exit(2) in C when an improper commandline is given instead of returning 2. ALL exit() calls should be removed from this module. The return value should be passed to exit or returned from main() by the caller of Py_Main() and NOT from within this call. python.c's main() would not need to be changed as it already does this. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:48 Message: Logged In: YES user_id=752496 Effectively closing it. ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-04-21 15:33 Message: Logged In: YES user_id=541557 Patch was applied, just closing ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-01-21 17:50 Message: Logged In: YES user_id=541557 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=672035&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:50:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:51:42 2005 Subject: [ python-Bugs-672035 ] Py_Main() does not perform to spec Message-ID: Bugs item #672035, was opened at 2003-01-21 17:42 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 Category: Extension Modules Group: Python 2.2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_Main() does not perform to spec Initial Comment: I consider this a code bug, not a documentation issue as the documentation is the behavior we want. >From http://www.python.org/doc/current/api/veryhigh.html#l2h- 47 : int Py_Main(int argc, char **argv) The main program for the standard interpreter. This is made available for programs which embed Python. The argc and argv parameters should be prepared exactly as those which are passed to a C program's main() function. It is important to note that the argument list may be modified (but the contents of the strings pointed to by the argument list are not). The return value will be the integer passed to the sys.exit() function, 1 if the interpreter exits due to an exception, or 2 if the parameter list does not represent a valid Python command line. I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al In all cases the code will call exit(2) in C when an improper commandline is given instead of returning 2. ALL exit() calls should be removed from this module. The return value should be passed to exit or returned from main() by the caller of Py_Main() and NOT from within this call. python.c's main() would not need to be changed as it already does this. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:48 Message: Logged In: YES user_id=752496 Effectively closing it. ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-04-21 15:33 Message: Logged In: YES user_id=541557 Patch was applied, just closing ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-01-21 17:50 Message: Logged In: YES user_id=541557 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=672035&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:54:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:55:03 2005 Subject: [ python-Bugs-676346 ] String formatting operation Unicode problem. Message-ID: Bugs item #676346, was opened at 2003-01-28 17:59 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 3 Submitted By: David M. Grimes (dmgrime) Assigned to: M.-A. Lemburg (lemburg) Summary: String formatting operation Unicode problem. Initial Comment: When performing a string formatting operation using %s and a unicode argument, the argument evaluation is performed more than once. In certain environments (see example) this leads to excessive calls. It seems Python-2.2.2:Objects/stringobject.c:3394 is where PyObject_GetItem is used (for dictionary-like formatting args). Later, at :3509, there is a"goto unicode" when a string argument is actually unicode. At this point, everything resets and we do it all over again in PyUnicode_Format. There is an underlying assumption that the cost of the call to PyObject_GetItem is very low (since we're going to do them all again for unicode). We've got a Python-based templating system which uses a very simple Mix-In class to facilitate flexible page generation. At the core is a simple __getitem__ implementation which maps calls to getattr(): class mixin: def __getitem__(self, name): print '%r::__getitem__(%s)' % (self, name) hook = getattr(self, name) if callable(hook): return hook() else: return hook Obviously, the print is diagnostic. So, this basic mechanism allows one to write hierarchical templates filling in content found in "%(xxxx)s" escapes with functions returning strings. It has worked extremely well for us. BUT, we recently did some XML-based work which uncovered this strange unicode behaviour. Given the following classes: class w1u(mixin): v1 = u'v1' class w2u(mixin): def v2(self): return '%(v1)s' % w1u() class w3u(mixin): def v3(self): return '%(v2)s' % w2u() class w1(mixin): v1 = 'v1' class w2(mixin): def v2(self): return '%(v1)s' % w1() class w3(mixin): def v3(self): return '%(v2)s' % w2() And test case: print 'All string:' print '%(v3)s' % w3() print print 'Unicode injected at w1u:' print '%(v3)s' % w3u() print As we can see, the only difference between the w{1,2,3} and w{1,2,3}u classes is that w1u defines v1 as unicode where w1 uses a "normal" string. What we see is the string-based one shows 3 calls, as expected: All string: <__main__.w3 instance at 0x8150524>::__getitem__(v3) <__main__.w2 instance at 0x814effc>::__getitem__(v2) <__main__.w1 instance at 0x814f024>::__getitem__(v1) v1 But the unicode causes a tree-like recursion: Unicode injected at w1u: <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) v1 I'm sure this isn't a "common" use of the string formatting mechanism, but it seems that evaluating the arguments multiple times could be a bad thing. It certainly is for us 8^) We're running this on a RedHat 7.3/8.0 setup, not that it appears to matter (from looking in stringojbect.c). Also appears to still be a problem in 2.3a1. Any comments? Help? Questions? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:54 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-28 19:23 Message: Logged In: YES user_id=38388 I don't see how you can avoid fetching the Unicode argument a second time without restructuring the formatting code altogether. If you know that your arguments can be Unicode, you should start with a Unicode formatting string to begin with. That's faster and doesn't involve a fallback solution. If you still want to see this fixed, I'd suggest to submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 From noreply at sourceforge.net Tue Jan 11 04:58:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 04:58:16 2005 Subject: [ python-Bugs-680379 ] Incorrect permissions set in lib-dynload. Message-ID: Bugs item #680379, was opened at 2003-02-04 15:24 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 Category: Distutils Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Arcady Genkin (antipode) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect permissions set in lib-dynload. Initial Comment: I have seen a number of bugs on this issue, but all of them seem dot be marked as "closed" for some reason. This has been the case in every release since Python 2.1 and is still the case in 2.2.2. When istalling Python by typing "make install" (with umask set to 022) everything is installed with correct permissions, *except* for the stuff in the lib-dynload directory, where the files are installed with mode 700 (should be of 755). Thanks. -- Arcady Genkin ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 From noreply at sourceforge.net Tue Jan 11 05:08:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 05:12:03 2005 Subject: [ python-Bugs-687297 ] Profilier hooked into SystemExit Message-ID: Bugs item #687297, was opened at 2003-02-15 22:41 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dylan Shell (dshell) Assigned to: Nobody/Anonymous (nobody) Summary: Profilier hooked into SystemExit Initial Comment: I've been attempting to profile code that uses the PyOpenGL bindings. Essentially I've got a program with that calls glutMainLoop - which is said to never return. The problem is that since this really envokes some C code that calls "exit" the profiler does not catch a "SystemExit" exception, because this is never thrown. If there was a way to get the profiler to dump state on demand, I could do this in an "onExit" event handler, and then restart python with the pstats module to have a look-see. Alternatively the profiler could use some OS provided exit handler - or something simliar. Also, running the main loop in a thread does not seem to work (the video memory used by GLUT) is corrupted. So, this isn't a fair test on which to profile. I suspect that the ability to dump profile stats to disk could also be useful for other folks. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 01:08 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&group_id=5470 From noreply at sourceforge.net Tue Jan 11 16:04:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:04:10 2005 Subject: [ python-Bugs-1100201 ] Cross-site scripting on BaseHTTPServer Message-ID: Bugs item #1100201, was opened at 2005-01-11 15: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=1100201&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Johnston (paj28) Assigned to: Nobody/Anonymous (nobody) Summary: Cross-site scripting on BaseHTTPServer Initial Comment: Hi, There is a minor XSS flaw in BaseHTTPServer, in the default error message, if you try connecting with a bad method name, e.g.: pugsley:/srv/www/htdocs # telnet risk 8000 Trying 192.168.3.52... Connected to risk. Escape character is '^]'. / HTTP/1.0 HTTP/1.0 501 Unsupported method ("") Server: SimpleHTTP/0.6 Python/2.3.4 Date: Tue, 11 Jan 2005 15:02:48 GMT Content-Type: text/html Connection: close Error response

Error response

Error code 501.

Message: Unsupported method ("").

Error code explanation: 501 = Server does not support this operation. Connection closed by foreign host. This is not likely to be a major security risk, but ideally it should be fixed. In addition it may be that other error messages exhibit this flaw, I haven't done a code audit. Credit for discovery: Richard Moore Best wishes, Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100201&group_id=5470 From noreply at sourceforge.net Tue Jan 11 16:08:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:09:04 2005 Subject: [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 11:45 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 10:08 Message: Logged In: YES user_id=99508 Yes, I believe it should. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-10 22:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-10 22:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 18:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 12:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. ---------------------------------------------------------------------- Comment By: Dani (asqui) Date: 2003-01-12 11:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply at sourceforge.net Tue Jan 11 16:19:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:19:41 2005 Subject: [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 13:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 12:19 Message: Logged In: YES user_id=752496 Jeremy, could you please provide a patch for the docs? Thanks! ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 12:08 Message: Logged In: YES user_id=99508 Yes, I believe it should. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 19:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 13:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. ---------------------------------------------------------------------- Comment By: Dani (asqui) Date: 2003-01-12 13:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply at sourceforge.net Tue Jan 11 16:36:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:36:17 2005 Subject: [ python-Bugs-1099516 ] tempfile files not types.FileType Message-ID: Bugs item #1099516, was opened at 2005-01-10 10:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099516&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Frans van Nieuwenhoven (vannieuwenhoven) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile files not types.FileType Initial Comment: a temporary file created with the tempfile module is not recognized as a types.FileType testcase: import types import tempfile # this will return False (I think it should return True) isinstance(tempfile.TemporaryFile(), types.FileType) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-11 10:36 Message: Logged In: YES user_id=80475 Clarified the doc strings, noting that a file-like object is returned rather than an actual file. Instead of type checking the object, it is a better practice to use "duck typing" where you check for required methods (the interface) instead of an actual type or subtype. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099516&group_id=5470 From noreply at sourceforge.net Tue Jan 11 16:48:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:48:43 2005 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 19:21 Message generated for change (Comment added) made by akosprime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- >Comment By: A. Stocker (akosprime) Date: 2005-01-11 15:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python Modules/python.o libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work ("Use of the `network' resource not enabled") and _locale doesn't work ("*** WARNING: renaming "_locale" since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext") I'm not sure what else to try in order to get this working. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 16:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 16:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 15:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 14:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Tue Jan 11 16:54:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:54:09 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 16:14 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095802&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None 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: Jack Jansen (jackjansen) Date: 2005-01-11 16: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 10: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-06 08: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 Tue Jan 11 16:56:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 16:56:20 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 16:14 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095802&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None 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: Jack Jansen (jackjansen) Date: 2005-01-11 16: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 16: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 10: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-06 08: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 Tue Jan 11 17:00:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 17:00:10 2005 Subject: [ python-Bugs-1100235 ] Scripts started with CGIHTTPServer: missing cgi environment Message-ID: Bugs item #1100235, was opened at 2005-01-11 11: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=1100235&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pacote (pacote) Assigned to: Nobody/Anonymous (nobody) Summary: Scripts started with CGIHTTPServer: missing cgi environment Initial Comment: With Python 2.4 only (2.3 works fine). Tested on Windows 2000. In run_cgi, sys.environ is updated with cgi variables (QUERY_STRING, etc.) but it seems that this environment is not passed to the child process. On Windows os.popen3 is used but something must have changed in that function that is causing this regression. The attached patch fixes this using the subprocess module. It fixes also (I think) bug 1088039 ("directories/scripts with spaces in their name"). Supports too Python installed in a directory with a space (e.g. "Program Files"). Patch note: the subprocess test (have_subprocess) is kind of awkward: is there a better way to do this? Diff follows, complete script attached. ----- --- C:\apps\Python24\Lib\CGIHTTPServer-old.py Mon Aug 30 09:38:16 2004 +++ C:\apps\Python24\Lib\CGIHTTPServer.py Tue Jan 10 19:45:09 2005 @@ -234,18 +234,16 @@ elif self.have_popen2 or self.have_popen3: # Windows -- use popen2 or popen3 to create a subprocess + import subprocess import shutil - if self.have_popen3: - popenx = os.popen3 - else: - popenx = os.popen2 - cmdline = scriptfile + + cmdline = '"%s"' % scriptfile if self.is_python(scriptfile): interp = sys.executable if interp.lower().endswith("w.exe"): # On Windows, use python.exe, not pythonw.exe interp = interp[:-5] + interp[-4:] - cmdline = "%s -u %s" % (interp, cmdline) + cmdline = '"%s" -u %s' % (interp, cmdline) if '=' not in query and '"' not in query: cmdline = '%s "%s"' % (cmdline, query) self.log_message("command: %s", cmdline) @@ -253,11 +251,11 @@ nbytes = int(length) except (TypeError, ValueError): nbytes = 0 - files = popenx(cmdline, 'b') - fi = files[0] - fo = files[1] - if self.have_popen3: - fe = files[2] + + p = subprocess.Popen(cmdline, stdin=subprocess.PIPE, stdout=subprocess.PIPE, + stderr=subprocess.PIPE, env=os.environ) + (fi, fo, fe) = (p.stdin, p.stdout, p.stderr) + if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) @@ -267,16 +265,16 @@ break fi.close() shutil.copyfileobj(fo, self.wfile) - if self.have_popen3: - errors = fe.read() - fe.close() - if errors: - self.log_error('%s', errors) + errors = fe.read() + fe.close() + if errors: + self.log_error('%s', errors) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: self.log_message("CGI script exited OK") + del p else: # Other O.S. -- execute script in this process ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470 From noreply at sourceforge.net Tue Jan 11 17:08:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 17:08:14 2005 Subject: [ python-Bugs-1095822 ] Apple-installed Python fails to build extensions Message-ID: Bugs item #1095822, was opened at 2005-01-04 16:43 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095822&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Apple-installed Python fails to build extensions Initial Comment: Apple-installed Python 2.3 (on Mac OS X 10.3) can no longer build extension modules after a newer framework build has been installed. This happens because it will build extensions with "-framework Python", which will actually link against the newer framework (be it 2.3.X or 2.4 or later) that is in /Library in stead of against it's own framework in /System/Library. After over a year of debating multiple solutions the Pythonmac-SIG consensus is that linking extensions with "-undefined dynamic_lookup" in stead of against the framework is the best solution. All of 2.5a0, 2.4.1 and 2.3.5 will detect the fact that they are being run on a machine that has an Apple-installed python that needs to be patched, and apply that patch. A standalone patch installer will also be made available. In addition, 2.5a0, 2.4.1 and 2.3.5 themselves will also use the -undefined dynamic_lookup method of linking when running on 10.3 or later (unless the user has specifically set MACOSX_DEPLOYMENT_TARGET to 10.2 or earlier). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2005-01-11 17:08 Message: Logged In: YES user_id=45365 All three of 2.3.X, 2.4.X and 2.5a0 now link extensions in a way that makes them either portable between Pythons (10.3 or later) or at least work in the face of other installed Pythons (10.2 or earlier). In addition, doing a frameworkinstall of either 2.3.X, 2.4.X or 2.5a0 will test whether an unpatched Apple-installed Python sits on the machine, and if there is it will warn the user to apply a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095822&group_id=5470 From noreply at sourceforge.net Tue Jan 11 17:56:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 17:56:58 2005 Subject: [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 11:45 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 11:56 Message: Logged In: YES user_id=99508 I think I misunderstood your question. Yes, this *is* already fixed in the documentation for the subprocess module in 2.4. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 10:19 Message: Logged In: YES user_id=752496 Jeremy, could you please provide a patch for the docs? Thanks! ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 10:08 Message: Logged In: YES user_id=99508 Yes, I believe it should. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-10 22:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-10 22:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 18:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 12:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. ---------------------------------------------------------------------- Comment By: Dani (asqui) Date: 2003-01-12 11:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply at sourceforge.net Tue Jan 11 18:32:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 18:32:54 2005 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 09:32 Message: Logged In: YES user_id=71407 You are missing a system library: /usr/lib/libmpc.a I've never done anything special to install this library but it is available on all three IRIX systems that I have access to. The library is not used to resolve any symbols. I guess you could just remove the -lmpc from the link line. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 07:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python Modules/python.o libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work ("Use of the `network' resource not enabled") and _locale doesn't work ("*** WARNING: renaming "_locale" since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext") I'm not sure what else to try in order to get this working. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Tue Jan 11 18:43:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 18:43:08 2005 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 19:21 Message generated for change (Comment added) made by akosprime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- >Comment By: A. Stocker (akosprime) Date: 2005-01-11 17:43 Message: Logged In: YES user_id=1179755 Ralf, Strange, I DO have that library: ls -l /usr/lib/libmpc* -r--r--r-- 1 root sys 1220 Mar 13 2001 /usr/lib/libmpc.a It makes no sense to me that the SGI MIPS compilers can't find a library that's in a default location. Very peculiar. I guess I'm just going to have to give up on getting Python 2.4 working completely under Irix. We need both network and _locale to work in order for the various scripts we have in place to work correctly and I can't get it to compile with gcc. [*sigh*] ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 17:32 Message: Logged In: YES user_id=71407 You are missing a system library: /usr/lib/libmpc.a I've never done anything special to install this library but it is available on all three IRIX systems that I have access to. The library is not used to resolve any symbols. I guess you could just remove the -lmpc from the link line. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 15:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python Modules/python.o libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work ("Use of the `network' resource not enabled") and _locale doesn't work ("*** WARNING: renaming "_locale" since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext") I'm not sure what else to try in order to get this working. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 16:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 16:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 15:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 14:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Tue Jan 11 18:56:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 18:56:23 2005 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 09:56 Message: Logged In: YES user_id=71407 Before giving up I'd try to reset PATH before running configure in the Python directory. I had all kinds of trouble with the freeware tools on path. Here is what I use: /usr/bin /usr/bsd /bin /usr/sbin /sbin /etc /usr/etc /usr/bin/X11 Python 2.4 really works under IRIX, incl. the socket module. I have it going on three different machines. On one machine the timestamp for libmpc.a is from 1998! ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 09:43 Message: Logged In: YES user_id=1179755 Ralf, Strange, I DO have that library: ls -l /usr/lib/libmpc* -r--r--r-- 1 root sys 1220 Mar 13 2001 /usr/lib/libmpc.a It makes no sense to me that the SGI MIPS compilers can't find a library that's in a default location. Very peculiar. I guess I'm just going to have to give up on getting Python 2.4 working completely under Irix. We need both network and _locale to work in order for the various scripts we have in place to work correctly and I can't get it to compile with gcc. [*sigh*] ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 09:32 Message: Logged In: YES user_id=71407 You are missing a system library: /usr/lib/libmpc.a I've never done anything special to install this library but it is available on all three IRIX systems that I have access to. The library is not used to resolve any symbols. I guess you could just remove the -lmpc from the link line. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2005-01-11 07:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python Modules/python.o libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work ("Use of the `network' resource not enabled") and _locale doesn't work ("*** WARNING: renaming "_locale" since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext") I'm not sure what else to try in order to get this working. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Tue Jan 11 19:12:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 19:12:21 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-11 13:12 Message: Logged In: YES user_id=11365 Thanks for the quick work Raymond! I see you have added a test case too. I am attaching a patch which implements this change in a different style, based on setobject.h publicly advertising that v->data is a dictionary for any set object v. It passes the new test code (and the rest of the test suite). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Tue Jan 11 20:02:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 20:02:19 2005 Subject: [ python-Bugs-1100366 ] Frame does not receive configure event on move Message-ID: Bugs item #1100366, was opened at 2005-01-11 14: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=1100366&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anand Kameswaran (akameswaran) Assigned to: Martin v. L?wis (loewis) Summary: Frame does not receive configure event on move Initial Comment: Python : 2.4 OS: WInXP sp2. I have created a frame attached to a Tk(). The frame is bound to the configure sequence. However, the frame does not get a configure on a move, but does get a configure event on a resize. This seems odd as the root does get an event for both resize and move, but only forwards one of them. I have included a sample of the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100366&group_id=5470 From noreply at sourceforge.net Tue Jan 11 20:03:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 20:03:13 2005 Subject: [ python-Bugs-1100368 ] Wrong "type()" syntax in docs Message-ID: Bugs item #1100368, was opened at 2005-01-11 16:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 From noreply at sourceforge.net Tue Jan 11 21:39:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 21:39:55 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-11 15:39 Message: Logged In: YES user_id=80475 I prefer the existing code though it is slightly inefficient (creating an intermediate tuple whose size is known in advance and whose elements are known to be unique). IMO, this beats breaking the encapsulation of the set object structure (knowledge of the v->data field and knowledge that the dict values are set to True). I want to preserve the option for sets to be possibly re-implemented without an underlying dictionary. Someday, I'll craft a C API for sets. It will include an ability to build-up the values element by element. P.S. The code in the attachment needs error checking for the call to PyDict_SetItem(). ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-11 13:12 Message: Logged In: YES user_id=11365 Thanks for the quick work Raymond! I see you have added a test case too. I am attaching a patch which implements this change in a different style, based on setobject.h publicly advertising that v->data is a dictionary for any set object v. It passes the new test code (and the rest of the test suite). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Tue Jan 11 21:54:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 11 21:54:32 2005 Subject: [ python-Bugs-1100429 ] TarFile iteration can break (on Windows) if file has links Message-ID: Bugs item #1100429, was opened at 2005-01-11 11:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: TarFile iteration can break (on Windows) if file has links Initial Comment: I ran into this with a simple loop trying to detar Pyrex-0.9.3: for info in tarfile: tarfile.extract(info) I called the above immediately after calling tarfile.open, so the returned iterator was an instance of TarIter. The problem is that Pyrex includes some symbolic links. When TarFile.makelink finds that os.symlink is missing (on Windows) it then does getmember to find the info for the referenced file. The getmember method results in a call to getmembers, which loads all the infos into the members list. However, this breaks the TarIter, since it assumes the members have not yet been loaded. Not sure what the best fix for this is; in my script, I switched over to using getmembers rather than the iterator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470 From noreply at sourceforge.net Wed Jan 12 00:05:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 00:05:33 2005 Subject: [ python-Bugs-1019882 ] hotshot start / stop stats bug Message-ID: Bugs item #1019882, was opened at 2004-08-31 18:06 Message generated for change (Comment added) made by alecf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019882&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: hotshot start / stop stats bug Initial Comment: Hotshot has a bug that manifests when using start/stop instead of run(), however it appears to only occur in the interactive interpreter or in an embedded application. If you run the attached program like "python hotshotbug.py" it works just fine. However, if you start an interactive session and paste each line one by one into the shell, you get the following exception: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/local/lib/python2.3/hotshot/stats.py", line 29, in load for event in log: File "/usr/local/lib/python2.3/hotshot/log.py", line 110, in next return what, self._pop(), tdelta IndexError: pop from empty list We discovered this when trying to profile an embedded application which doesn't have a single entrypoint suitable for run(). Unfortunately, I can't provide that application, but it shouldn't matter, since the interpreter crash is the same. ---------------------------------------------------------------------- Comment By: Alec Flett (alecf) Date: 2005-01-11 23:05 Message: Logged In: YES user_id=21804 So does this mean there is no decent way to use start() or stop() if they are not called within the same stackframe? I've noticed this by trying to analyze prof files with external python scripts - i.e. I generate the profile in one program, and try to open it in another for analysis. Its the 2nd program that tries to open it that gets the crash. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-11-09 03:26 Message: Logged In: YES user_id=86307 Not sure about the embedded application, but I believe the problem with the interactive interpreter is that you're executing a code snippet ("p.start()") which calls the function to enable the profiler, and then does a return from PyEval_EvalFrame. This means the first event the profiler sees will be the return, without having previosly seen a call (since when PyEval_EvalFrame was entered, profiling was not yet started). The LogReader class assumes that a return event must have been preceeded by a corresponding call event so that it can pop the previously pushed information. You can get the same crash with a simple: >>> p.start() >>> p.stop() and then try to load the stats. By the way, with Python2.4b1, the example does not crash when executed non-interactively from the command line (at least on my Windows XP system). ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2004-10-05 17:45 Message: Logged In: YES user_id=967320 I get the same traceback even when not running interactively. I can provide .prof files if needed. fumanchu@amor.org ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 14:42 Message: Logged In: YES user_id=12800 Could this be related to 900092? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019882&group_id=5470 From noreply at sourceforge.net Wed Jan 12 00:07:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 00:12:46 2005 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-16 19:02 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-01-12 00:07 Message: Logged In: YES user_id=51702 I can confirm the bug with readline 4.3 and Python 2.5a0 (#1, Jan 11 2005, 23:22:16). dsm001's patch fixes it. ---------------------------------------------------------------------- Comment By: DSM (dsm001) Date: 2004-12-31 03:32 Message: Logged In: YES user_id=1175690 This one being simple enough for the likes of me to patch, I did so -- 1093585. Let the school of hard knocks begin! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-20 11:57 Message: Logged In: YES user_id=671362 I'm +1 for sanity checking rather than waiting for the GNU readline to return NULL in these functions. It's just adding a few lines of code right after PyArg_ParseTuple : if (entry_number < 0) { PyErr_SetString(PyExc_ValueError, "index cannot be a negative value"); return NULL; } Then you can work around the problem without worrying about the return value of remove_history nor replace_history_entry. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-19 17:41 Message: Logged In: YES user_id=6656 Do you want to fix it then? :) I can't imagine it's that hard, but it would be easier for someone who can test that their fix helps... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-18 11:45 Message: Logged In: YES user_id=671362 FYI, I can reproduce this with : - Python 2.4 & readline 4.3 under SuSE 9.1 - Python 2.5(snapshot as of 2004-12-17) & readline 4.3 under SuSE 9.1 - Python 2.4 & readline 4.3.5(?) under Cygwin ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-17 15:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Wed Jan 12 01:16:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 01:16:59 2005 Subject: [ python-Bugs-662840 ] configure script fails with wchat_t size. Message-ID: Bugs item #662840, was opened at 2003-01-05 14:03 Message generated for change (Comment added) made by sakshale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails with wchat_t size. Initial Comment: Python version 2.3a1 System RH 7.3 Compiler: gcc 3.2.1 The configure script bails out when trying to determain the size of wchar_t. The configure runs OK with gcc 2.96. . . . checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- Comment By: Sakshale eQuorian (sakshale) Date: 2005-01-11 16:16 Message: Logged In: YES user_id=79659 I am running into the same issue; Solaris 9 SPARC and Python-2.4.tar.bz2 checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 I had --with-libs='/usr/local/ssl/lib/ as a configure option. The error was; configure:18335: checking size of wchar_t configure:18660: gcc -o conftest -g -O2 conftest.c /usr/local/ssl -lsocket -lnsl -lrt -ldl >&5 ld: fatal: file /usr/local/ssl/lib/: unknown file type Removing the --with-libs cured this problem ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 14:54 Message: Logged In: YES user_id=33168 Nadav, do you still have this problem with 2.3b1? Is this a duplicate as indicated in the comments? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-01 17:45 Message: Logged In: YES user_id=33168 Seems to be a duplicate of 678723 (or at least related, both are redhat 7.3). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-01-06 14:01 Message: Logged In: YES user_id=21627 I see. The problem lies in these lines configure:15806: ./conftest ./configure: line 1: 6876 Segmentation fault ./conftest$ac_exeext Now, it is not clear why the test program (printed below these lines) could possible cause a segmentation fault - unless there is a bug in the compiler. So I would conclude this to be a gcc bug, on this configuration. It would be possible to track this further down, but that would require access to the machine, using a debugger, etc. ---------------------------------------------------------------------- Comment By: Nadav Horesh (nadavhoresh) Date: 2003-01-06 12:02 Message: Logged In: YES user_id=75473 Further info: On the same system (RH7.3+gcc3.2.1+PIII) I compliled python 2.2.2 without any problems. On another system: RH8.0 + gcc3.2.1 + dual PIII --- the configure script concluded without errors. I didn't try to compile though. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-01-05 15:12 Message: Logged In: YES user_id=21627 Can you please attach the resulting config.log? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 From noreply at sourceforge.net Wed Jan 12 01:46:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 01:46:59 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: Open Resolution: None 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-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 Wed Jan 12 03:16:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 03:16:43 2005 Subject: [ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin Message-ID: Bugs item #1084766, was opened at 2004-12-14 00:41 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-01-12 03:16 Message: Logged In: YES user_id=51702 A trivial solution is to move the lines _PyExc_Init(); _PyImport_FixupExtensions("exceptions", "exceptions"); above the block that begins with "sysmod = _PySys_Init();" Then when the interpreter is run with "python < ." it outputs: Fatal Python error: Py_Initialize: can't initialize sys Avbruten (SIGABRT) I don't know if that is a good solution. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-19 04:25 Message: Logged In: YES user_id=2772 Duplicated here on a stale CVS version of 2.4. Here's some information from gdb: Starting program: /usr/src/cvs/python/dist/src/python -S -c '' < / [Thread debugging using libthread_db enabled] [New Thread -151074304 (LWP 6154)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074304 (LWP 6154)] 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 549 Py_INCREF(value); (gdb) where #0 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 #1 0x08075e13 in PyDict_SetItemString (v=0xf6fae79c, key=0x8109d60 "stdin", item=0x0) at Objects/dictobject.c:1988 #2 0x080d6988 in _PySys_Init () at Python/sysmodule.c:961 #3 0x080d3e17 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:190 #4 0x080d5815 in Py_Initialize () at Python/pythonrun.c:283 #5 0x08055159 in Py_Main (argc=4, argv=0xfefac1b4) at Modules/main.c:418 #6 0x08054e0f in main (argc=4, argv=0xfefac1b4) at Modules/python.c:23 The problem seems to be that PyFile_FromFile() returns NULL without tripping the PyErr_Occurred() test on my line 946 of sysmodule.c, because the call to fill_file_fields() returns NULL too. It looks like fill_file_fields is supposed to return NULL with an error set, but when dircheck() is called that early, PyExc_IOError is NULL, so no error is set. Maybe _PyExc_Init() must be moved earlier in startup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 From noreply at sourceforge.net Wed Jan 12 06:49:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 06:49:43 2005 Subject: [ python-Bugs-1100673 ] Python Interpreter shell is crashed Message-ID: Bugs item #1100673, was opened at 2005-01-12 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=1100673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: abhishek (abhishekkabra) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter shell is crashed Initial Comment: I faced this problem about 50 % of time when I hit follwing commands on python shell. But I think Crash of interpreter is not a expected behaviour. It should throw some error even if I am wrong/ hitting wrong commands 1. on shell of linux start python 2 On python shell hit _doc__ ( underscore doc underscore underscore ) So Python shell is crashed with following crash dump darwin{akabra}6: python Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> _doc__Segmentation fault (core dumped) darwin{akabra}7: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 From noreply at sourceforge.net Wed Jan 12 20:16:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 20:19:17 2005 Subject: [ python-Bugs-1100673 ] Python Interpreter shell is crashed Message-ID: Bugs item #1100673, was opened at 2005-01-12 05:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: abhishek (abhishekkabra) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter shell is crashed Initial Comment: I faced this problem about 50 % of time when I hit follwing commands on python shell. But I think Crash of interpreter is not a expected behaviour. It should throw some error even if I am wrong/ hitting wrong commands 1. on shell of linux start python 2 On python shell hit _doc__ ( underscore doc underscore underscore ) So Python shell is crashed with following crash dump darwin{akabra}6: python Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> _doc__Segmentation fault (core dumped) darwin{akabra}7: ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-01-12 19:16 Message: Logged In: YES user_id=6656 That's certainly not expected behaviour, however I think it's unlikely to be a python bug -- I've not heard of this behaviour before. Is python using readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 From noreply at sourceforge.net Wed Jan 12 22:30:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 22:30:07 2005 Subject: [ python-Bugs-1101233 ] test_fcntl fails on netbsd2 Message-ID: Bugs item #1101233, was opened at 2005-01-12 16:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101233&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Howard (mikeh-id) Assigned to: Nobody/Anonymous (nobody) Summary: test_fcntl fails on netbsd2 Initial Comment: edit line 23 of test_fcntl.py to add 'netbsd2' to the tuple and it passes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101233&group_id=5470 From noreply at sourceforge.net Wed Jan 12 22:35:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 12 22:35:20 2005 Subject: [ python-Bugs-1101236 ] test_shutil fails on NetBSD 2.0 Message-ID: Bugs item #1101236, was opened at 2005-01-12 16:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101236&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Howard (mikeh-id) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on NetBSD 2.0 Initial Comment: test_shutil.py fails the test 'test_on_error' when run as root but is ok if run by a mortal user. This is because NetBSD 2.0 thinks it is ok for root to remove files and directories for which he does not have write permission. A mere mortal cannot do these things, so test_shutil passes. I don't know if this is a bug or a feature, but there probably should be a test to avoid running 'test_on_error' when root is building Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101236&group_id=5470 From noreply at sourceforge.net Thu Jan 13 05:10:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 05:10:32 2005 Subject: [ python-Bugs-789519 ] CSV reader does not parse Mac line endings Message-ID: Bugs item #789519, was opened at 2003-08-16 07:16 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Larry Meyn (lmeyn) >Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV reader does not parse Mac line endings Initial Comment: #Test code: import csv import traceback class excel_mac(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_mac", excel_mac) class excel_unix(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\n' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_unix", excel_unix) testdata = range(10) for dialect in ["excel","excel_unix","excel_mac"]: try: print '\n Testing dialect "%s"' % dialect test = file('test.csv','w') writer = csv.writer(test,dialect=dialect) for i in range(3): writer.writerow(testdata) test.close() test = file('test.csv','r') reader = csv.reader(test,dialect=dialect) for row in reader: print row except: traceback.print_exc() #Results """ Testing dialect "excel" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_unix" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_mac" Traceback (most recent call last): File "/Users/lmeyn/Desktop/testcsv.py", line 36, in ? print row Error: newline inside string """ ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-13 15:10 Message: Logged In: YES user_id=698599 I'm going to close this issue - we will attempt to improve the documentation, so as to bring this issue to user's awareness, but the supplied iterator needs to return "lines" - on a file using \r, this means using universal newline mode. ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2003-08-22 04:02 Message: Logged In: YES user_id=103811 Why doesn't the csv module use the lineterminator for reading files? As it is, the lineterminator appears to be used only for the writing of rows to a file. This, of course, means that csv will quite happily write a file that it cannot subsequently read with the same dialect. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-22 02:01 Message: Logged In: YES user_id=44345 We've been discussing this bug on the csv mailing list. I suspect we will make a change to U mode for 2.3.1 and 2.4, though we have yet to test the proposed change. Skip ---------------------------------------------------------------------- Comment By: Larry Meyn (lmeyn) Date: 2003-08-22 01:44 Message: Logged In: YES user_id=28540 If I open files using the universal, 'U', mode this is not a problem. Too bad the 'U' mode is not the default. (I know, there is a lot of *nix python code out there that opens binary files as text, and it would all break if 'U' were the default.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 From noreply at sourceforge.net Thu Jan 13 05:14:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 05:14:40 2005 Subject: [ python-Bugs-1072404 ] Bugs in _csv module - lineterminator Message-ID: Bugs item #1072404, was opened at 2004-11-24 23:00 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Chris Withers (fresh) >Assigned to: Andrew McNamara (andrewmcnamara) Summary: Bugs in _csv module - lineterminator Initial Comment: On trying to parse a '\r' terminated csv generated on a Mac, I get a "newline inside string" error from the csv module. Two things sprung to mind having read: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_csv.c?rev=1.15&view=markup ...for a bit. 1. The Dialect's lineterminator doesn't appear to be used when parsing a CSV. This feels like a bug to be, 'cos I could specify the terminator if Reader_iternext(ReaderObj *self) used it :-S 2. The processing in Reader_iternext(ReaderObj *self) assumes that a '\r' will be followed by '\0' for Macs, '\n' for windows, and anything else is an error. but: >>> c = open('var\data\metadata.csv').read() >>> c[:100] 'BENEFIT,,Subjects relating to all benefits,AB \rBENEFIT,PARTNERDIED,Bereavement Should I be expecting to see a '\0' there? Anyway, the real bug seems to be the reader's ignorance of the lineterminator. However, even if my analysis is off the mark, the problem still exists :-S cheers, Chris ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-13 15:14 Message: Logged In: YES user_id=698599 The reader expects to be supplied an iterator that returns lines - in this case, the file iterator has not recognised \r as end-of-line and has read the whole file in and yielded that as a "line". If you use universal-newline mode on your source file, you should have more luck. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-25 15:23 Message: Logged In: YES user_id=44345 This is a known problem. See the April archives of the csv mailing list: http://manatee.mojam.com/pipermail/csv/2004-April/thread.html Solutions are welcome. I suspect any solution will involve either discarding PyIter_Next altogether or further subdividing what it returns. A couple things to note in the way of workarounds: 1. Reader_iternext() defers to PyIter_Next() to grab the next line, so there's really no opportunity to interject the lineterminator into the operation with the current code. This means reading from StringIO objects that use \r lineterminators will always fail. 2. If you have a real file as input and open it in universal newline mode you will get the correct behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470 From noreply at sourceforge.net Thu Jan 13 05:37:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 05:37:35 2005 Subject: [ python-Bugs-1101399 ] dict subclass breaks cPickle noload() Message-ID: Bugs item #1101399, was opened at 2005-01-13 04: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=1101399&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: dict subclass breaks cPickle noload() Initial Comment: The attached script displays the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 From noreply at sourceforge.net Thu Jan 13 05:54:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 05:54:13 2005 Subject: [ python-Bugs-1101399 ] dict subclass breaks cPickle noload() Message-ID: Bugs item #1101399, was opened at 2005-01-13 04:37 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: dict subclass breaks cPickle noload() Initial Comment: The attached script displays the bug. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-01-13 04:54 Message: Logged In: YES user_id=35752 Attached is a patch that seems to fix the problem. Someone please review it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 From noreply at sourceforge.net Thu Jan 13 05:54:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 05:55:02 2005 Subject: [ python-Bugs-1101399 ] dict subclass breaks cPickle noload() Message-ID: Bugs item #1101399, was opened at 2005-01-13 04:37 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Tim Peters (tim_one) Summary: dict subclass breaks cPickle noload() Initial Comment: The attached script displays the bug. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-01-13 04:54 Message: Logged In: YES user_id=35752 Attached is a patch that seems to fix the problem. Someone please review it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 From noreply at sourceforge.net Thu Jan 13 06:46:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 06:46:37 2005 Subject: [ python-Bugs-1100673 ] Python Interpreter shell is crashed Message-ID: Bugs item #1100673, was opened at 2005-01-12 05:49 Message generated for change (Comment added) made by puneet_mnitian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: abhishek (abhishekkabra) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter shell is crashed Initial Comment: I faced this problem about 50 % of time when I hit follwing commands on python shell. But I think Crash of interpreter is not a expected behaviour. It should throw some error even if I am wrong/ hitting wrong commands 1. on shell of linux start python 2 On python shell hit _doc__ ( underscore doc underscore underscore ) So Python shell is crashed with following crash dump darwin{akabra}6: python Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> _doc__Segmentation fault (core dumped) darwin{akabra}7: ---------------------------------------------------------------------- Comment By: Puneet (puneet_mnitian) Date: 2005-01-13 05:46 Message: Logged In: YES user_id=1196195 Not reproducible ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-12 19:16 Message: Logged In: YES user_id=6656 That's certainly not expected behaviour, however I think it's unlikely to be a python bug -- I've not heard of this behaviour before. Is python using readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 From noreply at sourceforge.net Thu Jan 13 06:54:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 06:54:08 2005 Subject: [ python-Bugs-796219 ] ntpath.expanduser() is still wrong Message-ID: Bugs item #796219, was opened at 2003-08-27 15:11 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Kurt B. Kaiser (kbk) Summary: ntpath.expanduser() is still wrong Initial Comment: I found a system with the following setup: - os.getenv("HOME") returns "%USERPROFILE%" - os.getenv("USERPROFILE") returns the home directory Currently, ntpath.py doesn't expand ~ correctly in this case. The fix is pretty simple, I'll try to submit it if I have time. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 15:45 Message: Logged In: YES user_id=341410 I have submitted sf patch #957650 to fix the bug listed. There is still an issue when there actually exists folders with names that mirror environment variables, but regardless of whether we stat the filesystem, the meaning of such a thing is ambiguous. The patch also includes ~user\subpath functionality, which has been missing in ntpath. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-26 19:53 Message: Logged In: YES user_id=341410 After doing some more playing around, I discovered a few other examples that would kill either method described below: HOME=%USERDRIVE%%USERPATH% HOME=C:\%userprofiles\%USERNAME% The real trick is that % can exist in a path on windows, so even c:\%HOME% is a vaild path: Directory of D:\test 03/26/2004 03:58p

. 03/26/2004 03:58p .. 03/26/2004 03:59p %HOME% 0 File(s) 0 bytes 3 Dir(s) 5,355,511,808 bytes free D:\test> I suppose the question remains as to what cases do we want to cover. If we assume that there aren't any % symbols in a path, then the code is straightforward, and I can have a patch for you in a few minutes. If % can be in a path, then the problem is a pain, and a miniature parser needs to be written to deal with it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 17:49 Message: Logged In: YES user_id=6380 Unclear what I'm asked to do here. Josiah, could you produce an actual patch against CVS rather than random example code? If you have forward slashes, you should use os.path.normpath(). Why doesn't that work? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-30 09:00 Message: Logged In: YES user_id=31435 Assigned back to Guido. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2003-09-30 01:33 Message: Logged In: YES user_id=341410 I just noticed that I've got some forward slashes in various paths on my windows machines...here's some updated code: def expandfull(var, rem=3): if not rem: return os.path.expandvars(var) a = os.path.expandvars(var) b = [] d = [b.extend(i.split('\')) for i in a.split('/')] c = [] for i in b: if '%' in i: c.append(expandfull(i), rem-1) else: c.append(i) return '\'.join(c) ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-30 04:55 Message: Logged In: YES user_id=539787 I stand corrected; multiple backslashes inside a path are not merged into one on Windows. Thank you. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2003-08-29 13:48 Message: Logged In: YES user_id=341410 Sourceforge ate my double-backslashes. All '\' should be '\\'. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2003-08-29 13:20 Message: Logged In: YES user_id=341410 The code you offered won't work correctly for all environment variable returns. An example that would kill your code: %SYSTEMROOT%\System32 def expandfull(var, rem=3): if not rem: return expandvars(var) a = expandvars(var) b = a.split('\') c = [] for i in b: if '%' in i: c.append(expandfull(i), rem-1) else: c.append(i) return '\'.join(c) The above would work properly for all environment variables. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-29 03:38 Message: Logged In: YES user_id=539787 If expandvars worked for nt variable syntax too, then just before the expanduser final return, the following code would suffice, right? max_recursion = 3 while '%' in userhome and max_recursion > 0: userhome = expandvars(userhome) max_recursion -= 1 ignoring the fact that path[1:] could contain variables too. Shouldn't expandvars be made to work with %var% format too? If yes, I'll offer code. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2003-08-28 02:47 Message: Logged In: YES user_id=92222 This is very common setting on Windows2000 Professional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470 From noreply at sourceforge.net Thu Jan 13 08:23:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 08:23:56 2005 Subject: [ python-Bugs-1101236 ] test_shutil fails on NetBSD 2.0 Message-ID: Bugs item #1101236, was opened at 2005-01-12 22:35 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101236&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mike Howard (mikeh-id) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on NetBSD 2.0 Initial Comment: test_shutil.py fails the test 'test_on_error' when run as root but is ok if run by a mortal user. This is because NetBSD 2.0 thinks it is ok for root to remove files and directories for which he does not have write permission. A mere mortal cannot do these things, so test_shutil passes. I don't know if this is a bug or a feature, but there probably should be a test to avoid running 'test_on_error' when root is building Python. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-13 08:23 Message: Logged In: YES user_id=469548 This has been fixed on maint24 and HEAD. Thanks for the report though! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101236&group_id=5470 From noreply at sourceforge.net Thu Jan 13 12:34:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 12:34:16 2005 Subject: [ python-Bugs-967934 ] csv module cannot handle embedded \r Message-ID: Bugs item #967934, was opened at 2004-06-07 14:46 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967934&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Bond (gnbond) Assigned to: Andrew McNamara (andrewmcnamara) Summary: csv module cannot handle embedded \r Initial Comment: CSV module cannot handle the case of embedded \r (i.e. carriage return) in a field. As far as I can see, this is hard-coded into the _csv.c file and cannot be fixed with Dialect changes. ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-13 22:34 Message: Logged In: YES user_id=698599 If you're interested, I've just checked in a change to the CVS head for Python 2.5 that may, at least partially, fix this problem (if you try it, let me know how it goes). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-06-07 21:25 Message: Logged In: YES user_id=44345 It certainly intersects with it somehow. ;-) If nothing else, it will serve as a useful test case. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2004-06-07 15:32 Message: Logged In: YES user_id=698599 I suspect this restriction (CR appearing within a quoted field) is a historical accident and can be safely removed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-07 15:02 Message: Logged In: YES user_id=80475 Skip, does this coincide with your planned switchover to universal newlines? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967934&group_id=5470 From noreply at sourceforge.net Thu Jan 13 14:34:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 14:34:04 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-13 08:34 Message: Logged In: YES user_id=11365 Thanks for the review Raymond. Since the code has only one known user, going for efficiency over encapsulation would certainly be premature optimisation. Regarding the P.S.; I modelled the loop building up the dictionary on the case TYPE_DICT code above. PyErr_Occurred() below the loop should catch anything that goes wrong, albeit not immediately - or can you see some way to break this? If so, that's a bug in the dictionary code, surely. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-11 15:39 Message: Logged In: YES user_id=80475 I prefer the existing code though it is slightly inefficient (creating an intermediate tuple whose size is known in advance and whose elements are known to be unique). IMO, this beats breaking the encapsulation of the set object structure (knowledge of the v->data field and knowledge that the dict values are set to True). I want to preserve the option for sets to be possibly re-implemented without an underlying dictionary. Someday, I'll craft a C API for sets. It will include an ability to build-up the values element by element. P.S. The code in the attachment needs error checking for the call to PyDict_SetItem(). ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-11 13:12 Message: Logged In: YES user_id=11365 Thanks for the quick work Raymond! I see you have added a test case too. I am attaching a patch which implements this change in a different style, based on setobject.h publicly advertising that v->data is a dictionary for any set object v. It passes the new test code (and the rest of the test suite). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Thu Jan 13 15:33:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 15:33:08 2005 Subject: [ python-Bugs-1101667 ] popen3 on windows loses environment variables Message-ID: Bugs item #1101667, was opened at 2005-01-13 23: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=1101667&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 on windows loses environment variables Initial Comment: see the following test code: #test_popen3_1.py import os FILENAME='c:\temp\test_popen3_2.py' os.environ['FOOBAR']='foobar' print os.environ['FOOBAR'] fs=os.popen3("c:\python24\python -u %s"% FILENAME,'b') print fs[1].read() #c:\temp\test_popen3_2.py print "from test_popen3_2.py" import os;print os.environ['FOOBAR'] Running test_popen3_1.py is expected to print out: foobar from test_popen3_2.py foobar But it doesn't print the last foobar. It correctly prints out when run on python 2.3. If the FILENAME is set to a relative path, as when you are in the c:\temp directory and the FILENAME is set to test_popen3_2.py, the code works correct. Tests run on windows XP, SP1. This bug is related to the cgi bug #1100235. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 From noreply at sourceforge.net Thu Jan 13 15:36:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 15:38:20 2005 Subject: [ python-Bugs-1101667 ] popen3 on windows loses environment variables Message-ID: Bugs item #1101667, was opened at 2005-01-13 23:33 Message generated for change (Comment added) made by juneaftn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 on windows loses environment variables Initial Comment: see the following test code: #test_popen3_1.py import os FILENAME='c:\temp\test_popen3_2.py' os.environ['FOOBAR']='foobar' print os.environ['FOOBAR'] fs=os.popen3("c:\python24\python -u %s"% FILENAME,'b') print fs[1].read() #c:\temp\test_popen3_2.py print "from test_popen3_2.py" import os;print os.environ['FOOBAR'] Running test_popen3_1.py is expected to print out: foobar from test_popen3_2.py foobar But it doesn't print the last foobar. It correctly prints out when run on python 2.3. If the FILENAME is set to a relative path, as when you are in the c:\temp directory and the FILENAME is set to test_popen3_2.py, the code works correct. Tests run on windows XP, SP1. This bug is related to the cgi bug #1100235. ---------------------------------------------------------------------- >Comment By: June Kim (juneaftn) Date: 2005-01-13 23:36 Message: Logged In: YES user_id=116941 Sorry. I got confused. When FILENAME is absolute, popen3 loses the environment variables, whereas it is relative, popen3 works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 From noreply at sourceforge.net Thu Jan 13 16:47:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 16:47:53 2005 Subject: [ python-Bugs-1089395 ] segfault/assert in tokenizer Message-ID: Bugs item #1089395, was opened at 2004-12-21 13:02 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L?wis (loewis) Summary: segfault/assert in tokenizer Initial Comment: The attached script fail.py (with the attached codec evilascii.py) leads to a segfault in both Python 2.3 and 2.4. With a debug build I get: python: Parser/tokenizer.c:367: fp_readl: Assertion `strlen(str) < (size_t)size' failed. Aborted Assigning to Martin, because this seems to be PEP 263 related. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2005-01-13 06:47 Message: Logged In: YES user_id=86307 I just posted a patch for this here: www.python.org/sf/1101726 I'd appreciate any comments/corrections. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 From noreply at sourceforge.net Thu Jan 13 17:21:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 17:21:19 2005 Subject: [ python-Bugs-1101756 ] popen4/cygwin ssh hangs Message-ID: Bugs item #1101756, was opened at 2005-01-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=1101756&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ph.E (ph_e) Assigned to: Nobody/Anonymous (nobody) Summary: popen4/cygwin ssh hangs Initial Comment: The following python code hangs on executing cmd2 (works with cmd1). The commands works fine when executed on a shell. I have the same problem with Python 2.3.4 and 2.4 (Windows). I use the latest Cygwin binaries import os cmd1 = "bin\ssh" cmd2 = "bin\ssh -i id_dsa admin@myserver.com uptime" def docmd(cmd): print "Doing %s ..." % cmd (stdin, stdouterr) = os.popen4(cmd) for line in stdouterr.readlines(): print line stdin.close() stdouterr.close() print "Done." if __name__ == '__main__': docmd(cmd1) docmd(cmd2) Give me some advice for testing (popen, linux, ...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470 From noreply at sourceforge.net Thu Jan 13 18:33:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 18:34:45 2005 Subject: [ python-Bugs-1101756 ] popen4/cygwin ssh hangs Message-ID: Bugs item #1101756, was opened at 2005-01-13 17:21 Message generated for change (Comment added) made by ph_e You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ph.E (ph_e) Assigned to: Nobody/Anonymous (nobody) Summary: popen4/cygwin ssh hangs Initial Comment: The following python code hangs on executing cmd2 (works with cmd1). The commands works fine when executed on a shell. I have the same problem with Python 2.3.4 and 2.4 (Windows). I use the latest Cygwin binaries import os cmd1 = "bin\ssh" cmd2 = "bin\ssh -i id_dsa admin@myserver.com uptime" def docmd(cmd): print "Doing %s ..." % cmd (stdin, stdouterr) = os.popen4(cmd) for line in stdouterr.readlines(): print line stdin.close() stdouterr.close() print "Done." if __name__ == '__main__': docmd(cmd1) docmd(cmd2) Give me some advice for testing (popen, linux, ...). ---------------------------------------------------------------------- >Comment By: Ph.E (ph_e) Date: 2005-01-13 18:33 Message: Logged In: YES user_id=1196530 The same code in Linux Python 2.3.4 works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470 From noreply at sourceforge.net Thu Jan 13 19:28:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 19:36:04 2005 Subject: [ python-Bugs-1101399 ] dict subclass breaks cPickle noload() Message-ID: Bugs item #1101399, was opened at 2005-01-12 23:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Jim Fulton (dcjim) Summary: dict subclass breaks cPickle noload() Initial Comment: The attached script displays the bug. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-13 13:28 Message: Logged In: YES user_id=31435 Oh. fudge. I'd like to say that since noload() is wholly undocumented, tough luck . The GLOBAL and NEWOBJ opcodes just stick None on the stack in noload()-mode. That's why the test script yields TypeError: object does not support item assignment (SETITEM is griping about the None noload()'s NEWOBJ left behind). I agree your patch fixes that, and offhand can't think of a more principled approach. Assigning to Jim in case he can. In any case, please put the marker() call on a different line and check its return value. I know some other code in cPickle takes the shortcut you're using, but it's not a good idea to grow more code like that (it changes what would have been a clear ""could not find MARK" error into a more mysterious "unpickling stack underflow" error). It would be good to get this fixed in 2.3.5 too. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-01-12 23:54 Message: Logged In: YES user_id=35752 Attached is a patch that seems to fix the problem. Someone please review it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 From noreply at sourceforge.net Thu Jan 13 22:14:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 22:14:11 2005 Subject: [ python-Bugs-1098985 ] set objects cannot be marshalled Message-ID: Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-13 16:14 Message: Logged In: YES user_id=80475 The code in TYPE_DICT is not a good coding practice. I don't think it should be changed, but the style should not get propagated elsewhere. BTW, if sets gets a C API for Py2.5, go ahead and resubmit your patch. At that point, saving a few bytes may become worth it. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-13 08:34 Message: Logged In: YES user_id=11365 Thanks for the review Raymond. Since the code has only one known user, going for efficiency over encapsulation would certainly be premature optimisation. Regarding the P.S.; I modelled the loop building up the dictionary on the case TYPE_DICT code above. PyErr_Occurred() below the loop should catch anything that goes wrong, albeit not immediately - or can you see some way to break this? If so, that's a bug in the dictionary code, surely. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-11 15:39 Message: Logged In: YES user_id=80475 I prefer the existing code though it is slightly inefficient (creating an intermediate tuple whose size is known in advance and whose elements are known to be unique). IMO, this beats breaking the encapsulation of the set object structure (knowledge of the v->data field and knowledge that the dict values are set to True). I want to preserve the option for sets to be possibly re-implemented without an underlying dictionary. Someday, I'll craft a C API for sets. It will include an ability to build-up the values element by element. P.S. The code in the attachment needs error checking for the call to PyDict_SetItem(). ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-11 13:12 Message: Logged In: YES user_id=11365 Thanks for the quick work Raymond! I see you have added a test case too. I am attaching a patch which implements this change in a different style, based on setobject.h publicly advertising that v->data is a dictionary for any set object v. It passes the new test code (and the rest of the test suite). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 From noreply at sourceforge.net Thu Jan 13 22:22:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 22:22:10 2005 Subject: [ python-Bugs-680379 ] Incorrect permissions set in lib-dynload. Message-ID: Bugs item #680379, was opened at 2003-02-04 13:24 Message generated for change (Comment added) made by antipode You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 Category: Distutils Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Arcady Genkin (antipode) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect permissions set in lib-dynload. Initial Comment: I have seen a number of bugs on this issue, but all of them seem dot be marked as "closed" for some reason. This has been the case in every release since Python 2.1 and is still the case in 2.2.2. When istalling Python by typing "make install" (with umask set to 022) everything is installed with correct permissions, *except* for the stuff in the lib-dynload directory, where the files are installed with mode 700 (should be of 755). Thanks. -- Arcady Genkin ---------------------------------------------------------------------- >Comment By: Arcady Genkin (antipode) Date: 2005-01-13 16:22 Message: Logged In: YES user_id=27110 I just tested with 2.3.4 and 2.4 and could not reproduce it. I guess this bug can be closed now. Thanks! -- Arcady Genkin ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-10 22:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 From noreply at sourceforge.net Thu Jan 13 22:31:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 22:31:26 2005 Subject: [ python-Bugs-680379 ] Incorrect permissions set in lib-dynload. Message-ID: Bugs item #680379, was opened at 2003-02-04 15:24 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 Category: Distutils Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Arcady Genkin (antipode) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect permissions set in lib-dynload. Initial Comment: I have seen a number of bugs on this issue, but all of them seem dot be marked as "closed" for some reason. This has been the case in every release since Python 2.1 and is still the case in 2.2.2. When istalling Python by typing "make install" (with umask set to 022) everything is installed with correct permissions, *except* for the stuff in the lib-dynload directory, where the files are installed with mode 700 (should be of 755). Thanks. -- Arcady Genkin ---------------------------------------------------------------------- Comment By: Arcady Genkin (antipode) Date: 2005-01-13 18:22 Message: Logged In: YES user_id=27110 I just tested with 2.3.4 and 2.4 and could not reproduce it. I guess this bug can be closed now. Thanks! -- Arcady Genkin ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 From noreply at sourceforge.net Thu Jan 13 23:59:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 13 23:59:36 2005 Subject: [ python-Bugs-926423 ] socket timeouts + Ctrl-C don't play nice Message-ID: Bugs item #926423, was opened at 2004-03-31 05:48 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: Nobody/Anonymous (nobody) Summary: socket timeouts + Ctrl-C don't play nice Initial Comment: As reported by Koen Vossen in c.l.py, when a timeout is set on a socket, a try...except block around a socket.recv (or socket.recvfrom) won't properly catch a keyboard interrupt (by Ctrl-C). I've attached example code that shows this. Run it and press Ctrl-C before the socket times out. This is for Python 2.3 under Linux. I believe the problem boils down to this sequence of events inside of the socketmodule.c::sock_recv function (and similiar for sock_recvfrom): 1) internal_select is called, which calls select, which waits for a timeout. A SIGINT is received (and caught by the default handler). The select returns with errno set to EINTR. internal_select returns with timeout==1 2) without checking errno, recv() is called. Since there is actually no data, it returns an error, with errno set to EAGAIN. 3) the default socket error handler is called, which calls PyErr_SetFromErrno(). Since errno != EINTR (it's now EAGAIN), a socket_error exception is thrown. 4) the innermost try..except block is triggered. 5) next loop around in eval_frame, notices that SIGINT was caught, and so KeyboardInterrupt is raised, exiting innermost try..except clause 6) KeyboardInterrupt is caught by the outermost try..except block. I was going to make a patch, but I couldn't figure out the best way to fix this in general :-( There are likely similiar problems with everywhere internal_select is used. The quick fix is to check errno before calling recv() ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-13 23:59 Message: Logged In: YES user_id=129426 (confirmed on Python 2.4 and HEAD) But: your analysis is not correct: internal_select doesn't return with timeout==1 when a SIGINT occurs, instead it returns 0, because it doesn't check for an error condition that select() may return. So I hacked around a bit and changed internal_select to return -1 when the select() system call returns -1, and then also added the following in sock_recv: if(errno) { Py_DECREF(buf); return PyErr_SetFromErrno(socket_error); } Which seems to make the example script that is attached to this bug report run as expected. As you say, I also think that this check must be added at all locations where internal_select is called. What do you say? I can make a patch if this is okay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 From noreply at sourceforge.net Fri Jan 14 00:28:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 00:28:56 2005 Subject: [ python-Bugs-926423 ] socket timeouts + Ctrl-C don't play nice Message-ID: Bugs item #926423, was opened at 2004-03-30 22:48 Message generated for change (Comment added) made by dmcooke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: Nobody/Anonymous (nobody) Summary: socket timeouts + Ctrl-C don't play nice Initial Comment: As reported by Koen Vossen in c.l.py, when a timeout is set on a socket, a try...except block around a socket.recv (or socket.recvfrom) won't properly catch a keyboard interrupt (by Ctrl-C). I've attached example code that shows this. Run it and press Ctrl-C before the socket times out. This is for Python 2.3 under Linux. I believe the problem boils down to this sequence of events inside of the socketmodule.c::sock_recv function (and similiar for sock_recvfrom): 1) internal_select is called, which calls select, which waits for a timeout. A SIGINT is received (and caught by the default handler). The select returns with errno set to EINTR. internal_select returns with timeout==1 2) without checking errno, recv() is called. Since there is actually no data, it returns an error, with errno set to EAGAIN. 3) the default socket error handler is called, which calls PyErr_SetFromErrno(). Since errno != EINTR (it's now EAGAIN), a socket_error exception is thrown. 4) the innermost try..except block is triggered. 5) next loop around in eval_frame, notices that SIGINT was caught, and so KeyboardInterrupt is raised, exiting innermost try..except clause 6) KeyboardInterrupt is caught by the outermost try..except block. I was going to make a patch, but I couldn't figure out the best way to fix this in general :-( There are likely similiar problems with everywhere internal_select is used. The quick fix is to check errno before calling recv() ---------------------------------------------------------------------- >Comment By: David M. Cooke (dmcooke) Date: 2005-01-13 18:28 Message: Logged In: YES user_id=65069 Looks like my assertion that timeout==1 is wrong :-). Otherwise, the analysis is correct: recv is called when select() retuned EINTR. I think your approach is the way to go. Since the return value of internal_select is no longer a boolean for a timeout, maybe in the expressions "timeout = internal_select(...)", "timeout" should be renamed to something more generic (possibly 'selectresult')? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-13 17:59 Message: Logged In: YES user_id=129426 (confirmed on Python 2.4 and HEAD) But: your analysis is not correct: internal_select doesn't return with timeout==1 when a SIGINT occurs, instead it returns 0, because it doesn't check for an error condition that select() may return. So I hacked around a bit and changed internal_select to return -1 when the select() system call returns -1, and then also added the following in sock_recv: if(errno) { Py_DECREF(buf); return PyErr_SetFromErrno(socket_error); } Which seems to make the example script that is attached to this bug report run as expected. As you say, I also think that this check must be added at all locations where internal_select is called. What do you say? I can make a patch if this is okay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 From noreply at sourceforge.net Fri Jan 14 01:06:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 01:07:06 2005 Subject: [ python-Bugs-1101399 ] dict subclass breaks cPickle noload() Message-ID: Bugs item #1101399, was opened at 2005-01-13 04:37 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Jim Fulton (dcjim) Summary: dict subclass breaks cPickle noload() Initial Comment: The attached script displays the bug. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-01-14 00:06 Message: Logged In: YES user_id=35752 New patch. Checks for invalid marker as suggested by Tim. It also add noload_append() and noload_appends(). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-13 18:28 Message: Logged In: YES user_id=31435 Oh. fudge. I'd like to say that since noload() is wholly undocumented, tough luck . The GLOBAL and NEWOBJ opcodes just stick None on the stack in noload()-mode. That's why the test script yields TypeError: object does not support item assignment (SETITEM is griping about the None noload()'s NEWOBJ left behind). I agree your patch fixes that, and offhand can't think of a more principled approach. Assigning to Jim in case he can. In any case, please put the marker() call on a different line and check its return value. I know some other code in cPickle takes the shortcut you're using, but it's not a good idea to grow more code like that (it changes what would have been a clear ""could not find MARK" error into a more mysterious "unpickling stack underflow" error). It would be good to get this fixed in 2.3.5 too. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-01-13 04:54 Message: Logged In: YES user_id=35752 Attached is a patch that seems to fix the problem. Someone please review it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 From noreply at sourceforge.net Fri Jan 14 01:24:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 01:24:20 2005 Subject: [ python-Bugs-1101399 ] dict subclass breaks cPickle noload() Message-ID: Bugs item #1101399, was opened at 2005-01-12 23:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Jim Fulton (dcjim) Summary: dict subclass breaks cPickle noload() Initial Comment: The attached script displays the bug. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-13 19:24 Message: Logged In: YES user_id=31435 Yup, good catch on append/appends too. Moral dilemma: should undocumented features be tested? That's a slippery slope in cPickle . ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-01-13 19:06 Message: Logged In: YES user_id=35752 New patch. Checks for invalid marker as suggested by Tim. It also add noload_append() and noload_appends(). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-13 13:28 Message: Logged In: YES user_id=31435 Oh. fudge. I'd like to say that since noload() is wholly undocumented, tough luck . The GLOBAL and NEWOBJ opcodes just stick None on the stack in noload()-mode. That's why the test script yields TypeError: object does not support item assignment (SETITEM is griping about the None noload()'s NEWOBJ left behind). I agree your patch fixes that, and offhand can't think of a more principled approach. Assigning to Jim in case he can. In any case, please put the marker() call on a different line and check its return value. I know some other code in cPickle takes the shortcut you're using, but it's not a good idea to grow more code like that (it changes what would have been a clear ""could not find MARK" error into a more mysterious "unpickling stack underflow" error). It would be good to get this fixed in 2.3.5 too. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-01-12 23:54 Message: Logged In: YES user_id=35752 Attached is a patch that seems to fix the problem. Someone please review it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101399&group_id=5470 From noreply at sourceforge.net Fri Jan 14 08:25:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 08:25:31 2005 Subject: [ python-Bugs-1102141 ] % operator bug Message-ID: Bugs item #1102141, was opened at 2005-01-14 17: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=1102141&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ChrisF (bogo666) Assigned to: Nobody/Anonymous (nobody) Summary: % operator bug Initial Comment: The attached code snippet is contains a function with a return value using the percent operator, but the interpreter complains about a TypeError, which is incorrect. Output from script is: chris@py:~/tmp/Python-2.4$ ./python ~/python/bug.py 10 0 0 0 Traceback (most recent call last): File "/home/chris/python/bug.py", line 13, in ? str_ip = string_ip_from_long(0x0a000000L) File "/home/chris/python/bug.py", line 11, in string_ip_from_long return ('%d.%d.%d.%d' % octets) TypeError: int argument required I've been able to reproduce this problem using versions: Python 2.2.3 (#1, Jun 16 2003, 13:21:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Python 2.3.4 (#1, Jun 11 2004, 12:13:19) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Python 2.3.4 (#2, Nov 21 2004, 23:17:26) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 (Sparc64 box:) Python 2.3.4 (#2, Dec 3 2004, 17:25:48) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Python version details: 2.4 (#1, Jan 14 2005, 17:20:35) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102141&group_id=5470 From noreply at sourceforge.net Fri Jan 14 12:06:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 12:06:44 2005 Subject: [ python-Bugs-1102141 ] % operator bug Message-ID: Bugs item #1102141, was opened at 2005-01-14 16:25 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102141&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ChrisF (bogo666) Assigned to: Nobody/Anonymous (nobody) Summary: % operator bug Initial Comment: The attached code snippet is contains a function with a return value using the percent operator, but the interpreter complains about a TypeError, which is incorrect. Output from script is: chris@py:~/tmp/Python-2.4$ ./python ~/python/bug.py 10 0 0 0 Traceback (most recent call last): File "/home/chris/python/bug.py", line 13, in ? str_ip = string_ip_from_long(0x0a000000L) File "/home/chris/python/bug.py", line 11, in string_ip_from_long return ('%d.%d.%d.%d' % octets) TypeError: int argument required I've been able to reproduce this problem using versions: Python 2.2.3 (#1, Jun 16 2003, 13:21:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Python 2.3.4 (#1, Jun 11 2004, 12:13:19) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Python 2.3.4 (#2, Nov 21 2004, 23:17:26) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 (Sparc64 box:) Python 2.3.4 (#2, Dec 3 2004, 17:25:48) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Python version details: 2.4 (#1, Jan 14 2005, 17:20:35) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-14 20:06 Message: Logged In: YES user_id=671362 % operator requires a tuple, but you're giving it a list. >>> "%d.%d"%[1,2] Traceback (most recent call last): File "", line 1, in ? TypeError: int argument required >>> "%d.%d"%(1,2) '1.2' 2.3.6.2 String Formatting Operations http://docs.python.org/lib/typesseq-strings.html % behaves as documented and is not likely a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102141&group_id=5470 From noreply at sourceforge.net Fri Jan 14 12:44:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 12:44:30 2005 Subject: [ python-Bugs-1102141 ] % operator bug Message-ID: Bugs item #1102141, was opened at 2005-01-14 02:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102141&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ChrisF (bogo666) Assigned to: Nobody/Anonymous (nobody) Summary: % operator bug Initial Comment: The attached code snippet is contains a function with a return value using the percent operator, but the interpreter complains about a TypeError, which is incorrect. Output from script is: chris@py:~/tmp/Python-2.4$ ./python ~/python/bug.py 10 0 0 0 Traceback (most recent call last): File "/home/chris/python/bug.py", line 13, in ? str_ip = string_ip_from_long(0x0a000000L) File "/home/chris/python/bug.py", line 11, in string_ip_from_long return ('%d.%d.%d.%d' % octets) TypeError: int argument required I've been able to reproduce this problem using versions: Python 2.2.3 (#1, Jun 16 2003, 13:21:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Python 2.3.4 (#1, Jun 11 2004, 12:13:19) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Python 2.3.4 (#2, Nov 21 2004, 23:17:26) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 (Sparc64 box:) Python 2.3.4 (#2, Dec 3 2004, 17:25:48) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Python version details: 2.4 (#1, Jan 14 2005, 17:20:35) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-14 06:06 Message: Logged In: YES user_id=671362 % operator requires a tuple, but you're giving it a list. >>> "%d.%d"%[1,2] Traceback (most recent call last): File "", line 1, in ? TypeError: int argument required >>> "%d.%d"%(1,2) '1.2' 2.3.6.2 String Formatting Operations http://docs.python.org/lib/typesseq-strings.html % behaves as documented and is not likely a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102141&group_id=5470 From noreply at sourceforge.net Fri Jan 14 18:40:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 18:40:56 2005 Subject: [ python-Bugs-1102469 ] rfc822 Deprecated since release 2.3? Message-ID: Bugs item #1102469, was opened at 2005-01-14 09: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=1102469&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: rfc822 Deprecated since release 2.3? Initial Comment: rfc822.Message is still subclassed by minetool.Message and httplib.HTTPMessage. It should either 1. upgrade httplib etc to the email package. 2. or make a note in the rfc822 page that it is still being in use 3. or undeprecate rfc822. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102469&group_id=5470 From noreply at sourceforge.net Fri Jan 14 22:58:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 14 22:58:31 2005 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-15 08:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 From noreply at sourceforge.net Sat Jan 15 03:58:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 03:59:13 2005 Subject: [ python-Bugs-1099746 ] copy.deepcopy barfs when copying a class derived from dict Message-ID: Bugs item #1099746, was opened at 2005-01-10 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099746&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Doug Winter (winjer) Assigned to: Nobody/Anonymous (nobody) Summary: copy.deepcopy barfs when copying a class derived from dict Initial Comment: I've got a class: class odict(dict): def __init__(self, d={}): self._keys = d.keys() dict.__init__(self, d) def __setitem__(self, key, item): dict.__setitem__(self, key, item) if key not in self._keys: self._keys.append(key) ... When I copy.deepcopy one of these it blows up in __setitem__ with an AttributeError on _keys, because __setitem__ is called without __init__ ever having been called. Presumably this thing looks and smells like a dictionary, so deepcopy thinks it is one. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-01-15 03:58 Message: Logged In: YES user_id=51702 See patch 1100562 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099746&group_id=5470 From noreply at sourceforge.net Sat Jan 15 06:30:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 06:30:12 2005 Subject: [ python-Bugs-1102469 ] rfc822 Deprecated since release 2.3? Message-ID: Bugs item #1102469, was opened at 2005-01-14 18:40 Message generated for change (Comment added) made by percivall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102469&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: rfc822 Deprecated since release 2.3? Initial Comment: rfc822.Message is still subclassed by minetool.Message and httplib.HTTPMessage. It should either 1. upgrade httplib etc to the email package. 2. or make a note in the rfc822 page that it is still being in use 3. or undeprecate rfc822. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-15 06:30 Message: Logged In: YES user_id=329382 No, rfc822 is actually not deprecated. It's also used in other parts of the stdlib. Look at the Python-Dev thread from August 2004 "Removing stuff from 2.4". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102469&group_id=5470 From noreply at sourceforge.net Sat Jan 15 12:38:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 12:38:46 2005 Subject: [ python-Bugs-926423 ] socket timeouts + Ctrl-C don't play nice Message-ID: Bugs item #926423, was opened at 2004-03-31 05:48 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: Nobody/Anonymous (nobody) Summary: socket timeouts + Ctrl-C don't play nice Initial Comment: As reported by Koen Vossen in c.l.py, when a timeout is set on a socket, a try...except block around a socket.recv (or socket.recvfrom) won't properly catch a keyboard interrupt (by Ctrl-C). I've attached example code that shows this. Run it and press Ctrl-C before the socket times out. This is for Python 2.3 under Linux. I believe the problem boils down to this sequence of events inside of the socketmodule.c::sock_recv function (and similiar for sock_recvfrom): 1) internal_select is called, which calls select, which waits for a timeout. A SIGINT is received (and caught by the default handler). The select returns with errno set to EINTR. internal_select returns with timeout==1 2) without checking errno, recv() is called. Since there is actually no data, it returns an error, with errno set to EAGAIN. 3) the default socket error handler is called, which calls PyErr_SetFromErrno(). Since errno != EINTR (it's now EAGAIN), a socket_error exception is thrown. 4) the innermost try..except block is triggered. 5) next loop around in eval_frame, notices that SIGINT was caught, and so KeyboardInterrupt is raised, exiting innermost try..except clause 6) KeyboardInterrupt is caught by the outermost try..except block. I was going to make a patch, but I couldn't figure out the best way to fix this in general :-( There are likely similiar problems with everywhere internal_select is used. The quick fix is to check errno before calling recv() ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-15 12:38 Message: Logged In: YES user_id=129426 I've submitted a patch, it's at 1102879 Please have a close look at it. ---------------------------------------------------------------------- Comment By: David M. Cooke (dmcooke) Date: 2005-01-14 00:28 Message: Logged In: YES user_id=65069 Looks like my assertion that timeout==1 is wrong :-). Otherwise, the analysis is correct: recv is called when select() retuned EINTR. I think your approach is the way to go. Since the return value of internal_select is no longer a boolean for a timeout, maybe in the expressions "timeout = internal_select(...)", "timeout" should be renamed to something more generic (possibly 'selectresult')? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-13 23:59 Message: Logged In: YES user_id=129426 (confirmed on Python 2.4 and HEAD) But: your analysis is not correct: internal_select doesn't return with timeout==1 when a SIGINT occurs, instead it returns 0, because it doesn't check for an error condition that select() may return. So I hacked around a bit and changed internal_select to return -1 when the select() system call returns -1, and then also added the following in sock_recv: if(errno) { Py_DECREF(buf); return PyErr_SetFromErrno(socket_error); } Which seems to make the example script that is attached to this bug report run as expected. As you say, I also think that this check must be added at all locations where internal_select is called. What do you say? I can make a patch if this is okay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 From noreply at sourceforge.net Sat Jan 15 13:26:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 13:26:45 2005 Subject: [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-17 01:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:26 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-08-19 21:29 Message: Logged In: YES user_id=6405 This is still an issue... has there been any movement on it outside of this bug report? I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is finding the BROWSER env var as described above, and thus not finding a usable browser. As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but just prepended with its value. Sure, that means that the KDE BROWSER value will be ignored, but it'll still find konqueror. This approach works for me, and I'm sure it'll work for others who have "valid" BROWSER values :) Simple patch against python2.3 (sorry, sf will mangle this, but it's short): --- webbrowser.py 2003-08-20 10:28:07.000000000 +1000 +++ /usr/lib/python2.3/webbrowser.py 2003-08-04 10:18:17.000000000 +1000 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) + _tryorder = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 22:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-02 17:43 Message: Logged In: YES user_id=198518 A week after posting <slrnb5iu1s.t8.matt@sake.mondoinfo.com> ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 10:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply at sourceforge.net Sat Jan 15 13:41:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 13:42:05 2005 Subject: [ python-Bugs-698706 ] imaplib: parsing INTERNALDATE Message-ID: Bugs item #698706, was opened at 2003-03-06 10:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) >Assigned to: Piers Lauder (pierslauder) Summary: imaplib: parsing INTERNALDATE Initial Comment: The regular expression InternalDate in imaplib does not match dates in which the day number is two-digit with a leading zero. >From a cursory glance at the IMAP definition, this is a legal format, and there is at least one IMAP server that uses it (courier-imap). The attached patch is for Python 2.2.2, but the problem still exists in 2.3a2. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:41 Message: Logged In: YES user_id=752496 This patch is not yet applied in CVS. Piers, I assign this to you because you know the module, but the patch is pretty simple, it's just adding a 0 to a part of the InternalDate's re: From: (?P[ 123] To: (?P[ 0123] ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-04-22 22:43 Message: Logged In: YES user_id=552329 This is correct, RFC 2060 allows for the date to be "2digit", where digit includes 0. There is no attached patch, but I can't attach to this tracker, so I'm putting it here in the comment (it's a one character change). This still exists in 2004-04-23 anon cvs. *** imaplib.py Fri Apr 23 13:40:32 2004 --- imaplib-fixed.py Fri Apr 23 13:42:31 2004 *************** *** 79,85 **** Continuation = re.compile(r'\+( (?P.*))?') Flags = re.compile(r'.*FLAGS \((?P[^\)]*)\)') InternalDate = re.compile(r'.*INTERNALDATE "' ! r'(?P[ 123][0-9])-(?P[A-Z][a-z][a-z])-(?P[0-9][0-9][0- 9][0-9])' r' (?P[0-9][0-9]):(?P[0-9][0-9]):(?P[0-9][0-9])' r' (?P[-+])(?P[0-9][0-9])(?P[0-9][0-9])' r'"') --- 79,85 ---- Continuation = re.compile(r'\+( (?P.*))?') Flags = re.compile(r'.*FLAGS \((?P[^\)]*)\)') InternalDate = re.compile(r'.*INTERNALDATE "' ! r'(?P[ 0123][0-9])-(?P[A-Z][a-z][a-z])-(?P[0-9][0-9][0 -9][0-9])' r' (?P[0-9][0-9]):(?P[0-9][0-9]):(?P[0-9][0-9])' r' (?P[-+])(?P[0-9][0-9])(?P[0-9][0-9])' r'"') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 From noreply at sourceforge.net Sat Jan 15 13:46:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 13:46:43 2005 Subject: [ python-Bugs-699816 ] Canvas Widget origin is off-screen Message-ID: Bugs item #699816, was opened at 2003-03-08 03:21 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas Widget origin is off-screen Initial Comment: I'm a Python newbie, so be patient. I noticed that create-<item> didn't place the item where I expected. My help@Python.org guru Matt Cowles suggested that highlightthickness (hT hereinafter) might be the culprit. I wasn't using hT, but I was using borderwidth (bd to all), and I eventually found the problem. I believe that it is an error in Tkinter, but I'll be happy to be corrected. I wrote a program to display the canvases with the four combinations of hT and bd, and later I doubled up to see if 'relief' with bd==0 had any effect. I'll try to upload the code (oops. It invoves two modules. I may have to send two messages, one with each module). Here is what I think happens, and what I think should happen : DOES: SHOULD: Tkinter finds screen coordinates cx, cy of Canvas same (crucial step omitted) tx, ty = cx, cy Tkinter translates cx, cy = cx - bd, cy -bd tx, ty = tx- bd, ty - bd Tkinter draws the border (width is 2*bd wider than the Canvas) draws the border Tkinter translates cx, cy = cx - hT, cy - hT tx, ty = tx - hT, ty - hT Tkinter draws the highlight box (width is 2*hT wider than the border) draws the hightlight box Tkinter delivers cx, cy as the origin of the Canvas delivers cx, cy as the origin The attached program, if it arrives, demonstrates this effect. Any one doing serious graphics will need to adjust the x,y values of every Canvas item they draw. Putting a wrapper around each to .get() the values of hT and bd (and others I haven't discovered yet ?) is feasible but awful. Putting a function at the top of each event callback function to correct the event object x and y is even more awkward. To preserve backwards compatibility, I suggest that Tkinter Canvas items all be given an extra set of x and y values, with distinctive names. The user can put any old values in the current x,y positional spots and use xcorrected = NN, ycorrected=NN to override the stuff in the positional spots. To handle the variable number of x,y pairs in create_polygon(), create_line(), and perhaps other, Tkinter might require that the new values be given in a tuple of pairs or two tuples (x0,x1,x2) & (y0,y1,y2) The attached file is TkCoords03.py The next error will include algGrid03.py. Hope you can get them together. Roy Keir newbieroy rmkeir@earthlink.net ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 From noreply at sourceforge.net Sat Jan 15 13:46:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 13:46:48 2005 Subject: [ python-Bugs-700650 ] Canvas origin is off-canvas in create_< item> (). Worka Message-ID: Bugs item #700650, was opened at 2003-03-10 02:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) >Summary: Canvas origin is off-canvas in create_<item>(). Worka Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 From noreply at sourceforge.net Sat Jan 15 13:53:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 13:53:45 2005 Subject: [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 09:05 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:53 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-17 19:14 Message: Logged In: YES user_id=21627 Yes, please attached unified or context diffs to this bug report, preferably using the CVS version of Python (or 2.3a2 if CVS is not possible). ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 16:30 Message: Logged In: YES user_id=732192 It becomes clear for me that making a good help for all systems out there is very difficult. But I could create a better ./configure --help output for python that is comon for all systems. And I can create a patch for the README file that explains the libstdc++ dependencies if you are building with GNU C++. Can I simply add a patch for these to the patch list or how does it work? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-17 15:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 09:24 Message: Logged In: YES user_id=732192 For example.......... The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 08:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx=<compiler> flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-15 10:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply at sourceforge.net Sat Jan 15 13:59:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 13:59:58 2005 Subject: [ python-Bugs-705792 ] test_atexit fails in directories with spaces Message-ID: Bugs item #705792, was opened at 2003-03-18 16:33 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 Category: None Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: test_atexit fails in directories with spaces Initial Comment: The regression test program test_atexit.py constructs a command line without doing any quoting of arguments. If the name of the build directory contains spaces, the command doesn't work and the test fails. Here's what happens in Windows: H:\benh\My Documents\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. Traceback (most recent call last): File "test_atexit.py", line 33, in ? """) File "test_support.py", line 122, in vereq raise TestFailed, "%r == %r" % (a, b) test_support.TestFailed: '' == "handler2 (7,) {'kw': 'abc'}\nhandler2 () {}\nhandler1\n" [5168 refs] If I change the current directory to use a compatibility name without a space in it: H:\benh\My Documents\python\Python-2.2.2\Lib\test>cd h:\benh\mydocu~1\python\python-2.2.2\lib\test H:\benh\MYDOCU~1\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. [5168 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 21:42 Message: Logged In: YES user_id=33168 Directories with spaces should work with current CVS. The fix needs to be backported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 From noreply at sourceforge.net Sat Jan 15 17:13:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 17:13:19 2005 Subject: [ python-Bugs-1102973 ] Incorrect RFC 2231 decoding Message-ID: Bugs item #1102973, was opened at 2005-01-15 11: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=1102973&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Incorrect RFC 2231 decoding Initial Comment: The following message ---snip snip--- Content-Transfer-Encoding: base64 Content-Type: application/msword; x-mac-type=42494E41; x-unix-mode=0644; x-mac-creator=4D535744; name="miriam's file.doc" Content-Disposition: attachment; filename*0="miriam's file"; filename*1=ths.doc ---snip snip--- Is incorrectly decoded according to RFC 2231. The bug is in Utils.py in the decode_params() and decode_rfc2231() functions. charset/lang encoding should only be present on the first parameter, i.e. filename*0 and even then, the quoted single quote should not trip up the scanner. The problem is two fold: - first, the unquoting of filename*0 happens in decode_param(), too early for decode_rfc2231() to know about it. Second, the logic in docode_rfc2231() is too naive; it should take quoting into account to decide whether a single quote is part of the file name or part of the leading charset/lang encoding. I've labeled this in the Group: Python 2.4, but it really affects Python 2.3 as well, and the current head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102973&group_id=5470 From noreply at sourceforge.net Sat Jan 15 18:38:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 18:38:26 2005 Subject: [ python-Bugs-706595 ] codecs.open and iterators Message-ID: Bugs item #706595, was opened at 2003-03-19 20:02 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Todd Reed (toddreed) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.open and iterators Initial Comment: Greg Aumann originally posted this problem in comp.lang.python on Nov 4, 2002, but I could not find a bug report. I've simply copied his news post, which explains the problem: ----------- Recently I figured out how to use iterators and generators. Quite easy to use and a great improvement. But when I refactored some of my code I came across a discrepancy that seems like it must be a bug. If you use the old file reading idiom with a codec the lines are converted to unicode but if you use the new iterators idiom then they retain the original encoding and the line is returned in non unicode strings. Surely using the new "for line in file:" idiom should give the same result as the old, "while 1: ...." I came across this when using the pythonzh Chinese codecs but the below code uses the cp1252 encoding to illustrate the problem because everyone should have those codecs. The symptoms are the same with both codecs. I am using python 2.2.2 on win2k. Is this definitely a bug, or is it an undocumented 'feature' of the codecs module? Greg Aumann The following code illustrates the problem: ------------------------------------------------------------------------ """Check readline iterator using a codec.""" import codecs fname = 'tmp.txt' f = file(fname, 'w') for i in range(0x82, 0x8c): f.write( '%x, %s\n' % (i, chr(i))) f.close() def test_iter(): print '\ntesting codec iterator.' f = codecs.open(fname, 'r', 'cp1252') for line in f: l = line.rstrip() print repr(l) print repr(l.decode('cp1252')) f.close() def test_readline(): print '\ntesting codec readline.' f = codecs.open(fname, 'r', 'cp1252') while 1: line = f.readline() if not line: break l = line.rstrip() print repr(l) try: print repr(l.decode('cp1252')) except AttributeError, msg: print 'AttributeError', msg f.close() test_iter() test_readline() ------------------------------------------------------------------------ This code gives the following output: ------------------------------------------------------------------------ testing codec iterator. '82, \x82' u'82, \u201a' '83, \x83' u'83, \u0192' '84, \x84' u'84, \u201e' '85, \x85' u'85, \u2026' '86, \x86' u'86, \u2020' '87, \x87' u'87, \u2021' '88, \x88' u'88, \u02c6' '89, \x89' u'89, \u2030' '8a, \x8a' u'8a, \u0160' '8b, \x8b' u'8b, \u2039' testing codec readline. u'82, \u201a' AttributeError 'unicode' object has no attribute 'decode' u'83, \u0192' AttributeError 'unicode' object has no attribute 'decode' u'84, \u201e' AttributeError 'unicode' object has no attribute 'decode' u'85, \u2026' AttributeError 'unicode' object has no attribute 'decode' u'86, \u2020' AttributeError 'unicode' object has no attribute 'decode' u'87, \u2021' AttributeError 'unicode' object has no attribute 'decode' u'88, \u02c6' AttributeError 'unicode' object has no attribute 'decode' u'89, \u2030' AttributeError 'unicode' object has no attribute 'decode' u'8a, \u0160' AttributeError 'unicode' object has no attribute 'decode' u'8b, \u2039' AttributeError 'unicode' object has no attribute 'decode' ------------------------------------------------------------------------ ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:38 Message: Logged In: YES user_id=752496 Can not test it so far, all I got is: testing codec iterator. u'82, \u201a' Traceback (most recent call last): ... File "C:\Python24\lib\encodings\cp1252.py", line 22, in decode return codecs.charmap_decode(input,errors,decoding_map) UnicodeEncodeError: 'ascii' codec can't encode character u'\u201a' in position 4: ordinal not in range(128) I'm on Win2k, sp2, with Py2.4 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:38 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-20 06:35 Message: Logged In: YES user_id=38388 That's a bug in the iterator support which was added to the codecs module: the .next() methods should not call the .next() methods on the reader directly, but instead redirect to the .readline() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470 From noreply at sourceforge.net Sat Jan 15 18:46:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 18:46:10 2005 Subject: [ python-Bugs-716634 ] " build_ext" " libraries" subcommand not s Message-ID: Bugs item #716634, was opened at 2003-04-07 06:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470 Category: Distutils Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) >Summary: "build_ext" "libraries" subcommand not s Initial Comment: The "libraries" command for "build_ext" is definitely one that should accept multiple libraries. However, this is impossible for both the command line as well as the configuration file. Patch attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470 From noreply at sourceforge.net Sat Jan 15 18:43:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 18:46:58 2005 Subject: [ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2 Message-ID: Bugs item #711830, was opened at 2003-03-29 12:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: SEEK_{SET,CUR,END} missing in 2.2.2 Initial Comment: Python 1.5.2 used to define SEEK_{SET,CUR,END} both in FCNTL.py and in posixfile.py Python 2.2.2 obsoletes both of them (and the symbols are no longer in FCNTL anyway). A quick grep on the 2.2.2 tree shows me posixfile is the only place that still defines the SEEK_* constants. It seems to me it's wrong to drop the constants (because a deprecated module will eventually be dropped). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:43 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-29 14:36 Message: Logged In: YES user_id=21627 Would you agree that these constants are best located in the os module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470 From noreply at sourceforge.net Sat Jan 15 18:50:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 18:50:25 2005 Subject: [ python-Bugs-718532 ] inspect, class instances and __getattr__ Message-ID: Bugs item #718532, was opened at 2003-04-09 17:01 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Raymond Hettinger (rhettinger) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 07:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-04-15 07:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 21:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 From noreply at sourceforge.net Sat Jan 15 18:54:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 18:54:28 2005 Subject: [ python-Bugs-727241 ] Core Dumps : Python2.2.2 Message-ID: Bugs item #727241, was opened at 2003-04-24 19:16 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470 Category: None Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eli Rosenberg (elirosenberg) Assigned to: Nobody/Anonymous (nobody) Summary: Core Dumps : Python2.2.2 Initial Comment: Hello, I am able to cause python to core dump on IRIX 6.5.18 and above with the code listed below. I have compiled with 3 versions of gcc as well as MIPSpro. Running this code with a valid host and a port that will cause a connection refused socket error produces a core dump with the the stack trace below. >>> import socket >>> x=socket.socket() >>> x.connect(('www.google.com', 1234)) > 0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527, 0xfb245fc] 1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945, 0xfb24e44] 2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230, 0xfb24078] 3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186, 0xfb23ee4] 4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868, 0x10092244] 5 _PyObject_GC_New(tp = 0x1013fbe0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895, 0x10092368] 6 newtracebackobject(next = (nil), frame = 0x1016b670, lasti = 21, lineno = 1) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":115, 0x100c6684] 7 PyTraceBack_Here(frame = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":133, 0x100c67f4] 8 eval_frame(f = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238, 0x1004e894] 9 PyEval_EvalCodeEx(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount = 0, kws = (nil), kwcount = 0, defs = (nil), defcount = 0, closure = (nil)) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595, 0x1004ffe0 10 PyEval_EvalCode(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":481, 0x10047ea0] 11 run_node(n = 0x101a5b28, filename = 0x1014e978 = "<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079, 0x1006f380] 12 PyRun_InteractiveOneFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590, 0x1006d57c] 13 PyRun_InteractiveLoopFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526, 0x1006d198] 14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", closeit = 0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489, 0x1006cf48] 15 Py_Main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/main.c":364, 0x1000fa44] 16 main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/python.c":10, 0x1000ecdc] 17 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1000ec78] I compiled Python 64-bit and the code above appears not to cause a segfault but the code below will bus error after a few iterations. import socket import time def doit(): s = socket.socket() start = time.time() try: s.connect(('www.cnn.com', 80)) except socket.error,e: print repr(e),str(e) finish = time.time() time.sleep(.5) print str(finish-start),"\n" s.close() for x in xrange(10): doit() Here is the stack trace: > 0 realfree(0x10162e98, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527, 0xfb245fc] 1 cleanfree(0x0, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945, 0xfb24e44] 2 __malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230, 0xfb24078] 3 _malloc(0x28, 0x0, 0x200000, 0x65637469, 0x17dd4, 0x1, 0x1, 0x8) ["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186, 0xfb23ee4] 4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868, 0x10092244] 5 _PyObject_GC_New(tp = 0x1013fbe0) ["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895, 0x10092368] 6 newtracebackobject(next = (nil), frame = 0x1016b670, lasti = 21, lineno = 1) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":115, 0x100c6684] 7 PyTraceBack_Here(frame = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/traceback.c":133, 0x100c67f4] 8 eval_frame(f = 0x1016b670) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238, 0x1004e894] 9 PyEval_EvalCodeEx(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount = 0, kws = (nil), kwcount = 0, defs = (nil), defcount = 0, closure = (nil)) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595, 0x1004ffe0 10 PyEval_EvalCode(co = 0x1016e990, globals = 0x1016a5d0, locals = 0x1016a5d0) ["/usr/people/eli/Python-2.2.2/Python/ceval.c":481, 0x10047ea0] 11 run_node(n = 0x101a5b28, filename = 0x1014e978 = "<stdin>", globals = 0x1016a5d0, locals = 0x1016a5d0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079, 0x1006f380] 12 PyRun_InteractiveOneFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590, 0x1006d57c] 13 PyRun_InteractiveLoopFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526, 0x1006d198] 14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename = 0x1014e978 = "<stdin>", closeit = 0, flags = 0x7fff2e2c) ["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489, 0x1006cf48] 15 Py_Main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/main.c":364, 0x1000fa44] 16 main(argc = 1, argv = 0x7fff2f24) ["/usr/people/eli/Python-2.2.2/Modules/python.c":10, 0x1000ecdc] 17 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1000ec78] Any help would be appreciated. thanks. -Eli ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:54 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-24 22:56 Message: Logged In: YES user_id=33168 I can't reproduce this problem with 2.2.3 on Irix 6.5: % uname -a IRIX rattler 6.5 10120734 IP32 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-25 16:03 Message: Logged In: YES user_id=21627 No. Except for MacOS, there is are no port maintainers. There are experts for some of the Unices, but only for Linux and Solaris. For things as strange as Irix, we have to have actual users of the systems to fully understand the problem and provide patches. In general, we accept work-arounds only if it can be shown that a work-around is necessary around a true platform bug (see how the getaddrinfo emulation is used on OSX, even though the platform provides a native implementation). I'm pretty certain that Python's usage of the getaddrinfo API is correct. If this is still causing crashes, it may be that the implementation in the Irix library is buggy. Have you applied all vendor patches? ---------------------------------------------------------------------- Comment By: Eli Rosenberg (elirosenberg) Date: 2003-04-25 15:28 Message: Logged In: YES user_id=764663 Hmm, I don't know for sure, but closing might not be the best idea because anyone else building on a really recent IRIX will have problems with socketmodule. Is there an IRIX maintainer or somebody like that? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-25 15:06 Message: Logged In: YES user_id=6656 so... do you think the fault is with Python or IRIX? if you're happy enough with the situation as it stands, we may as well close this... ---------------------------------------------------------------------- Comment By: Eli Rosenberg (elirosenberg) Date: 2003-04-25 14:41 Message: Logged In: YES user_id=764663 Hi, I think I have fixed things...for now. Here is what I see: IRIX now includes POSIX 1003.1g draft implementations of getaddrinfo/getnameinfo in accordance with http://www.ietf.org/proceedings/01mar/I-D/ipngwg-rfc2553bis-03.txt Previously, netdb.h on IRIX did not have these definitions and Python compiled in its own implementations and things seemed to work. I changed pyconfig.h to have socketmodule use its own implementations, but I did have to make a few changes because the IRIX prototypes for these functions are for the 2001 version of the standards, whereas socketmodule seemed to have 1999 versions from RFC2553. Not knowing much about the Python C API, I did not look closely enough to see why socketmodule seems to cause memory faults when compiled with the IRIX libc versions of these functions. Hopefully this is the source of the problem. -eli ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-25 07:53 Message: Logged In: YES user_id=6656 This looks nasty... Could you try making a debug build of Python (pass --with-pydebug to ./configure) and/or try with current CVS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&group_id=5470 From noreply at sourceforge.net Sat Jan 15 18:55:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 18:56:18 2005 Subject: [ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix Message-ID: Bugs item #728515, was opened at 2003-04-27 14:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 09:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 From noreply at sourceforge.net Sat Jan 15 19:04:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 19:04:38 2005 Subject: [ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr Message-ID: Bugs item #730222, was opened at 2003-04-30 12:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Initial Comment: In the Modules/socketmodule.c file, the inet_pton function implicitly treats "long packed_addr" as a 4-byte object or expects that the required 4-bytes is at &packed_addr[0]-[3]. This is not true under SUPER-UX/SX. In order to get this working right, I changed the data type from "long" to "int". This now works properly. -----Modules/socketmodule.c: #3825 /* 042303; JM; this routine really expects a 4-byte packed_addr * not a long; long on SX is 8-bytes! */ #if SX int packed_addr; #else long packed_addr; #endif ... if (packed_addr == INADDR_NONE) return 0; memcpy(dst, &packed_addr, 4); ----- ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 This patch is no applied, the bug persists? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 00:32 Message: Logged In: YES user_id=33168 Attached is a patch which should fix the problem. There was one other place that needed to be changed. This change is more generic. Let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 From noreply at sourceforge.net Sat Jan 15 19:10:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 19:11:00 2005 Subject: [ python-Bugs-1103023 ] raw_input problem with readline and UTF8 Message-ID: Bugs item #1103023, was opened at 2005-01-15 18: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=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'); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103023&group_id=5470 From noreply at sourceforge.net Sat Jan 15 19:42:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 19:42:13 2005 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 14:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:42 Message: Logged In: YES user_id=752496 Both bugs are for the same problem, keeping this alive (because it has the patch), closing the other as Duplicate. Regarding the patch, the actual code has something very similar to it, so maybe the bug is already fixed... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:42 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 03:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 10:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Sat Jan 15 19:43:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 19:43:29 2005 Subject: [ python-Bugs-778804 ] CGIHTTPServer cannot manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 06:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer cannot manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:43 Message: Logged In: YES user_id=752496 Duplicate of #737202, as the other has the patch, please go on with it. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 03:19 Message: Logged In: YES user_id=23486 same as bug 737202, which has an attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 14:06 Message: Logged In: YES user_id=80475 Eric, this was your change (2/9/2001). Will you take it from here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply at sourceforge.net Sat Jan 15 19:50:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 19:50:34 2005 Subject: [ python-Bugs-751758 ] ftplib.retrbinary fails when called from retrlines callback Message-ID: Bugs item #751758, was opened at 2003-06-10 03:51 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751758&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christian Long (christianmlong) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib.retrbinary fails when called from retrlines callback Initial Comment: Subject: ftplib.retrbinary() fails when called from inside retrlines() callback function I'm using ftplib to backup files from a Linux server to a Windows 2000 worksation. Client: Windows 2000 Pro ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Komodo IDE Server: ProFTP server (ProFTPd version 1.25) Mandrake Linux 9.0 Summary: When I use it like this it works fine. # Build a list of files that are on the remote server f.retrlines('NLST', makeListOfFiles) --then-- # Iterate over the list, retrieving each file for remoteFileName in listOfFiles: --snip-- f.retrbinary('RETR %s' % remoteFileName, localFile.write) --snip-- But it fails if I try to do the retrieve directly in my callback function. def transferFile(listLine): --snip-- f.retrbinary('RETR %s' % remoteFileName, localFile.write) <--fails here on first time through --snip-- # get list of files from server, adn transfer each file as it gets listed f.retrlines('LIST', transferFile) --snip-- File "D:\My Documents\Computer World\Python Resources\My Utilities\backup_remote_files.py", line 45, in ? f.retrlines('LIST', transferFile) File "C:\Python22\lib\ftplib.py", line 413, in retrlines callback(line) File "D:\My Documents\Computer World\Python Resources\My Utilities\backup_remote_files.py", line 36, in transferFile f.retrbinary('RETR mra.py', localFile.write) --snip-- File "C:\Python22\lib\ftplib.py", line 300, in makepasv host, port = parse227(self.sendcmd('PASV')) File "C:\Python22\lib\ftplib.py", line 572, in parse227 raise error_reply, resp error_reply: 200 Type set to I. It looks like the server is returning a 200 instead of a 227 when retrbinary() is called inside a callback function for retrlines(). Files: 2 Files are included: a broken version and a version that works This One Is Broken - retrbinary() called from inside a callback function for retrlines(). =================================================== import ftplib import os import time REMOTE_DIR = "/home/mydir" LOCAL_DIR = "C:\My Documents" TIME_FORMAT = "%y%m%d" # YYMMDD, like 030522 def transferFile(listLine): # Strips the file name from a line of a # directory listing, and gets it from the # server. Depends on filenames # with no embedded spaces or extra dots. if listLine.endswith('.py'): #Split file name on the dot splitFileName=remoteFileName.split('.') # Add a timestamp localFileName="%s_%s.%s" % (splitFileName[0], time.strftime(TIME_FORMAT), splitFileName[1]) # Open a local file for (over)writing, in binary mode. # print os.path.join(LOCAL_DIR,localFileName) localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb') print remoteFileName print localFile # Execute the FTP retrieve command, calling # the write() function of the local file # for each block retrieved from the FTP server # BUG: This should work, but I get the following traceback f.retrbinary('RETR %s' % remoteFileName, localFile.write) #<--- Fails # Here # mra.py #<open file 'D:\My Documents\Work\IA\Miller\MRA\Dev\Backup of remote files\mra_030610.py', mode 'wb' at 0x00886B70> #Traceback (most recent call last): # File "C:\Program Files\ActiveState Komodo 2.3\callkomodo\kdb.py", line 430, in _do_start # self.kdb.run(code_ob, locals, locals) # File "C:\Python22\lib\bdb.py", line 349, in run # exec cmd in globals, locals # File "D:\My Documents\Computer World\Python Resources\My Utilities\backup_remote_files.py", line 45, in ? # f.retrlines('LIST', transferFile) # File "C:\Python22\lib\ftplib.py", line 413, in retrlines # callback(line) # File "D:\My Documents\Computer World\Python Resources\My Utilities\backup_remote_files.py", line 36, in transferFile # f.retrbinary('RETR mra.py', localFile.write) # File "C:\Python22\lib\ftplib.py", line 385, in retrbinary # conn = self.transfercmd(cmd, rest) # File "C:\Python22\lib\ftplib.py", line 346, in transfercmd # return self.ntransfercmd(cmd, rest)[0] # File "C:\Python22\lib\ftplib.py", line 322, in ntransfercmd # host, port = self.makepasv() # File "C:\Python22\lib\ftplib.py", line 300, in makepasv # host, port = parse227(self.sendcmd('PASV')) # File "C:\Python22\lib\ftplib.py", line 572, in parse227 # raise error_reply, resp #error_reply: 200 Type set to I. # The problem is that the self.sendcmd('PASV') call is not getting a 227 # reply from the server. Rather, it is getting a 200 reply, confirming # that the type was set to I (Image). localFile.flush() localFile.close() f=ftplib.FTP('server', 'user', 'password') f.cwd(REMOTE_DIR) # List directory contents, and call the transferFile # function on each line in the listing f.retrlines('LIST', transferFile) f.close() =================================================== This One Works - retlines() builds a list, and then files are transferred by iterating over that list and calling retrbinary() for each. =================================================== import ftplib import os import time REMOTE_DIR = "/home/mydir" LOCAL_DIR = "C:\My Documents" TIME_FORMAT = "%y%m%d" # YYMMDD, like 030522 listOfFiles = [] def makeListOfFiles(remoteFileName): # Strips the file name from a line of a # directory listing, and gets file from the # server. Depends on filenames # with no embedded spaces or extra dots. if remoteFileName.endswith('.py'): listOfFiles.append(remoteFileName) f=ftplib.FTP('server', 'user', 'password') f.cwd(REMOTE_DIR) # List directory contents, and call the transferFile # function on each line in the listing f.retrlines('NLST', makeListOfFiles) print listOfFiles for remoteFileName in listOfFiles: #Split file name on the dot splitFileName=remoteFileName.split('.') # Add a timestamp localFileName="%s_%s.%s" % (splitFileName[0], time.strftime(TIME_FORMAT), splitFileName[1]) # Open a local file for (over)writing, in binary mode. # print os.path.join(LOCAL_DIR,localFileName) localFile=file(os.path.join(LOCAL_DIR,localFileName), 'wb') # Execute the FTP retrieve command, calling # the write() function of the local file # for each block retrieved from the FTP server f.retrbinary('RETR %s' % remoteFileName, localFile.write) localFile.flush() localFile.close() f.close() =================================================== ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:50 Message: Logged In: YES user_id=752496 Same behaviour, Py2.4 on Win2k, sp2. ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-14 21:45 Message: Logged In: YES user_id=589306 The problem seems to happen when you use a callback within a function that was called as a callback. Here is a much simpler case that demonstrates the problem: ----------------------------- import ftplib def transferFile(listLine): filename = listLine.split()[-1] if filename == 'README': # Note that retrlines uses a default # callback that just prints the file f.retrlines('RETR README') # <-- Fails f=ftplib.FTP('ftp.python.org', 'ftp', 'anon@') f.cwd('/pub/python') f.retrlines('LIST', transferFile) f.close() ----------------------------- This fails with the following: Traceback (most recent call last): File "ftptest.py", line 10, in ? f.retrlines('LIST', transferFile) File "/home/sjones/src/python/dist/src/Lib/ftplib.py", line 407, in retrlines callback(line) File "ftptest.py", line 6, in transferFile f.retrlines('RETR README') # <-- Fails File "/home/sjones/src/python/dist/src/Lib/ftplib.py", line 396, in retrlines conn = self.transfercmd(cmd) File "/home/sjones/src/python/dist/src/Lib/ftplib.py", line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "/home/sjones/src/python/dist/src/Lib/ftplib.py", line 321, in ntransfercmd host, port = self.makepasv() File "/home/sjones/src/python/dist/src/Lib/ftplib.py", line 299, in makepasv host, port = parse227(self.sendcmd('PASV')) File "/home/sjones/src/python/dist/src/Lib/ftplib.py", line 566, in parse227 raise error_reply, resp ftplib.error_reply: 200 Type set to A. Note this is with the current CVS version on Redhat 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751758&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:07:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:07:05 2005 Subject: [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks Message-ID: Bugs item #756104, was opened at 2003-06-17 15:25 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 >Category: Documentation >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex R.M. Turner (plexq) Assigned to: Nobody/Anonymous (nobody) Summary: Calling socket.recv() with a large number breaks Initial Comment: I have a backup script that calls socket.recv() passing the amount of data that is left to get for a given file as the argument. For very large files (I have one here that is 1.9Gig) it seems to break horribly after receiving about 130Meg. I have tried to track it down precisely with basic debugging (putting in print statements in the python code) but it just seams to freak out around the 130meg mark, and it just doesn't make sense. If I change the argument passed to recv to 32767 it works just fine. I have attatched the loop that reads data from the socket (In a working state, the bad code is commented out). ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:07 Message: Logged In: YES user_id=752496 This is a documentation bug; something the user should be "warned" about. This caught me once, and two different persons asked about this in #python, so maybe we should put something like the following in the recv() docs. """ For best match with hardware and network realities, the value of "buffer" should be a relatively small power of 2, for example, 4096. """ If you think the wording is right, just assign the bug to me, I'll take care of it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-13 11:11 Message: Logged In: YES user_id=31435 As Jeremy implied at the start, someone needs to demonstrate that "the bug" is actually in Python, not in your platform's implementation of sockets. If a C program displays the same behavior, your complaint is with your platform socket implementation. Sockets are low-level gimmicks, which is why Jeremy expected a C program to fail the same way. ---------------------------------------------------------------------- Comment By: Dmitry Dvoinikov (targeted) Date: 2004-09-13 08:17 Message: Logged In: YES user_id=1120792 I've also been hit by this problem, not at a 130Meg read, but at a mere 10Meg. Because of that I had to change my code to read many small chunks rather than a single blob and that fixed it. Still, I disagree with tim_one. If recv() is limited with the amount of data it can read per call, it should be set and documented, otherwise it is a bug and the call is unreliable. Nobody has to follow the decribed "best-practice" of reading small chunks, it actually worsens code quality, and what's worse - it makes other stuff break. Example - I was using the SimpleXMLRPCServer (Lib/SimpleXMLRPCServer.py), and it contains the following line at it's heart: data = self.rfile.read(int(self.headers["content-length"])) Guess what was happening with requests with content-length larger than 10Meg (in my case). I've aso thought the problem was with max() instead of min(), but as tim_one rightfully pointed out, this was a desired behaviour. Ironically though, replacing max() with min() fixes the problem as there is no more huge reads at lower level. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 21:41 Message: Logged In: YES user_id=31435 potterru, I don't believe plexq was using _fileobject.read() -- he said he was using socket.recv(), and all the comments later were consistent with that. The code you found does appear to *intend* max(): code following the snippet you quoted clearly expects that it may have read more than "left" bytes, and it would not be worrying about that had min() been intended. I agree the code is pretty inscrutable regardless, but we'd have to ask Guido why he wrote it that way. In any case, since this bug report is about socket.recv(), if you want to make a case that _fileobject.read() is buggy you should open a new report for that. ---------------------------------------------------------------------- Comment By: Igor E. Poteryaev (potterru) Date: 2004-07-26 08:23 Message: Logged In: YES user_id=48596 It looks like bug in module socket.py in _fileobject.read method. ... while True:     left = size - buf_len     recv_size = max(self._rbufsize, left)     data = self._sock.recv(recv_size) This code should read not more than *left* or *buffer size* So, it should be min instead of max ! Should I file a bug/patch for this ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 15:51 Message: Logged In: YES user_id=31435 I assume you're running on Linux. Python's implementation of recv asks the platform malloc for a buffer of the size requested, and raises an exception if malloc returns NULL. Unfortunately, malloc on Linux has a nasty habit of returning non-NULL even if there's no chance you can actually use the amount of memory requested. There's really nothing Python can do about that. So back to Jeremy's comment: try the same thing in C. If you get ridiculous behavior there too, it's a platform C/OS bug, and Python won't be able to hide it from you. ---------------------------------------------------------------------- Comment By: Alex R.M. Turner (plexq) Date: 2003-06-18 15:22 Message: Logged In: YES user_id=60034 That as maybe - it might be worth putting a suggested maximum in the docs. However I would say that given that an IPv6 packet could be as large as 2Gig, it's not unreasonable to ask for a packet as large as 1 Gig. Wether the problem is in glibc or python I don't know, although it seems that asking for a buffer of 1.3 Gig in size, and passing that to recv() would be odd behaviour on a current system in C given that most systems couldn't allocate that much memory to a buffer ;). I have written fairly extensive socket code in C/C++ before, and I never used anything larger than 65536 for the obvious reason that you can't receive anything bigger than that in IPv4 (and most NICs can't handle anything that big either). I figured it would be interesting to see what happened :). I have a penchant for being the only person in history to do quite a few things apparently! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 13:29 Message: Logged In: YES user_id=31435 BTW, if you're new to socket programming, do read Python's socket programming HOWTO: http://www.amk.ca/python/howto/sockets/ I expect you're the only person in history to try passing such a large value to recv() -- even if it worked, you'd almost certainly run out of memory trying to allocate buffer space for 1.9GB. sockets are a low-level facility, and it's common to pass a relatively small power of 2 (for best match with hardware and network realities). ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-18 13:02 Message: Logged In: YES user_id=31392 What happens when you write a C program that does the same thing? I expect you'll see similar problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:23:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:23:37 2005 Subject: [ python-Bugs-756940 ] can't CNTRL-C when running os.system in a thread Message-ID: Bugs item #756940, was opened at 2003-06-18 20:52 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Jones (morngnstar) Assigned to: Nobody/Anonymous (nobody) Summary: can't CNTRL-C when running os.system in a thread Initial Comment: This is related to Bug #756924. When os.system is called in a thread, Control-C is ignored. Steps to reproduce: 1. Download the attached file fibonacci.py. 2. Run python2.2 fibonacci.py. 3. Hit CNTRL-C. fibonacci.py starts a thread that executes fibonacci.py again (but with a flag to prevent this from recursing infinitely). Then it computes and prints the Fibonacci sequence, the slow way. The process executed in the thread redirects this to a file to avoid conflict over stdout. All this is just to give the program something to do while you hit CNTRL-C. Expected, and Python 2.1 behavior: You get a KeyboardInterrupt exception, a stack trace, and the program exits. Actual Python 2.2 behavior: No response. You have to run kill on the process. Maybe this is not a bug, but rather a limitation of Linux, since I understand SIGINT is blocked during the C function 'system'. However, CNTRL-C worked in Python 2.1, and that was nicer. Removing the lines of code described in Bug #756924 also fix this bug. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 The other bug have a very long discussion about this, and talks about patches to be applied to Py2.4, and the last patch is actually accepted. Maybe this is already fixed, please give it a try. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Greg Jones (morngnstar) Date: 2003-06-18 23:58 Message: Logged In: YES user_id=554883 OS is Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:40:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:41:05 2005 Subject: [ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection Message-ID: Bugs item #763190, was opened at 2003-06-30 10:34 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Maria Martinsdotter (dehex) Assigned to: Nobody/Anonymous (nobody) Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection Initial Comment: Environment: Python 2.2.2 win32all-150 Win2000 Server Dell server 2 CPU Pentuim 4 emulating 4 CPU's. Application: Service with many (50-150) threads. Problem: The entire service exits unexepectedly with only a brief reference made by Dr.Watson indicating the Windows equivalent of SIGSEGV in RtlEnterCriticalSection. Side info: Known to have happened once, we believe it may have happened three times in total but the two extra did not leave even a Dr.Watson trace. The known occurrence can be connected to our use of a timer where the action routine restarts the timer. The two extra's occurred at a point in time that connect the problem event to the timer expiration. The application have been used for five months, runnning around the clock. The customer installation currently use five instances of the base software, only configuration differs. It is arbitrary which instance fail. We have no means to trigger the problem. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:40 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Maria Martinsdotter (dehex) Date: 2003-06-30 19:00 Message: Logged In: YES user_id=807857 Apart from what we initially reported, no extensions are used. It is all pure Python and the only part of win32all used is the support for running it as a service. We are aware of the enhancements provided by 2.3 beta but let it suffice to say that the customer is picky. We have not been able to reproduce the problem in our test environment, however the hardware is not as sophisticated. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 12:13 Message: Logged In: YES user_id=33168 Are there any other C/Extension modules used which are not from the standard python distribution? Can you make a self contained test case? I encourage you to test with 2.3 beta 2. There were some thread changes which could affect this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:46:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:46:36 2005 Subject: [ python-Bugs-774546 ] popen does not like filenames with spaces Message-ID: Bugs item #774546, was opened at 2003-07-20 09:29 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:46 Message: Logged In: YES user_id=752496 Think that this should be closed with "Won't fix" specially now that we have the subprocess module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-01 13:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 07:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( cmd ) because piping multiple commands would required parenthesis nesting which does not look nice. The goal is to reach the simplicity of shell scripting. To execute the previous command, one would simple again use the go() method: (stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ).go() Here for my suggestion. It might be more appropriate to post it to a mailing list, to get more feedback ? I am sorry, I am very busy now and won't have time to implement this myself. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-19 09:17 Message: Logged In: YES user_id=139865 Yes, it works. This is also the same behaviour as os.system. os.popen2 allows one to pass either a quoted string or a sequence of strings (pfremy's suggested behaviour). It would be nice to have consistent functionality, and using a sequence would be easier when providing a list of files to be operated on. I am willing to provide a patch if this is the desired functionality. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 20:03 Message: Logged In: YES user_id=80475 Does it work for you if the filename is quoted: "thrill seeker.txt" ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:50:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:51:03 2005 Subject: [ python-Bugs-794291 ] double symlinking corrupts sys.path[0] Message-ID: Bugs item #794291, was opened at 2003-08-24 16:52 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794291&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Csaba Henk (dzsekijo) Assigned to: Nobody/Anonymous (nobody) Summary: double symlinking corrupts sys.path[0] Initial Comment: The bug can be demonstrated as follows (In some Bourne-tpye Unix shell) type $ mkdir d1 d2 && echo 'import sys print sys.path[0]' > d1/script.py && ln -s ../d1/script.py d2 && ln -s d2/script.py . Now see what the three invocations of script.py give us: $ python d1/script.py d1 $ python d2/script.py d2/../d1 $ python script.py d2 -- if script.py imported modules residing in d1, at the third invocation the modules would not be found. ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-08-28 02:39 Message: Logged In: YES user_id=666873 I confirm this behaviour on Linux 2.4.17 (glibc 2.2.4) with Python 2.2.2 and 2.2.3; but not with Python 2.3. The relevant change seems to be revision 2.114 of Python/sysmodule.c, which implemented SF patch #664376 (q.v.). The change appeared in 2.3a2. Should this be backported to the 2.2 line? ---------------------------------------------------------------------- Comment By: Csaba Henk (dzsekijo) Date: 2003-08-27 12:29 Message: Logged In: YES user_id=754125 I hope the startup message is exact enough: Python 2.2.2 (#1, May 19 2003, 03:15:27) [GCC 3.1] on linux2 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-27 08:46 Message: Logged In: YES user_id=539787 My mistake, I missed the Pyhton 2.2.2 part, sorry. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-27 08:45 Message: Logged In: YES user_id=539787 Which version of Python? With a recent 2.4 (built on Aug 21, sources of Aug 20), on a 2.4.19 SMP kernel: $ mkdir d1 d2 $ echo 'import sys > print sys.path[0]' >d1/script.py $ ln -s ../d1/script.py d2 $ ln -s d2/script.py . $ python d1/script.py /tmp/tzot/d1 $ python d2/script.py /tmp/tzot/d1 $ python script.py /tmp/tzot/d1 Please specify OS too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794291&group_id=5470 From noreply at sourceforge.net Sat Jan 15 20:59:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 20:59:18 2005 Subject: [ python-Bugs-856706 ] popen3 under threads reports different stderr results Message-ID: Bugs item #856706, was opened at 2003-12-09 04:08 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 Category: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Steven Howe (stevenhowe) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 under threads reports different stderr results Initial Comment: Using os.popen3 inside a thread (start_new_thread) returns different results from the stderr file dev. I discovered this while trying to trap badblocks program output. I have usb floppy I am trying to format, after a badblock check. My floppy is on /dev/sdb. code: import thread import os def dd( outfilename ): cmd='/sbin/badblocks -n -s -v -c 16 -b 512 /dev/sdb' channels = os.popen3( cmd ) ch = ' ' ff = '/tmp/%s' % outfilename out=open( ff ,'w') while ch != '': ch = channels[2].read(1) out.write( ch ) Run two ways. First as a stand alone code. Then as a threaded program. def( 'nothread.err' ) thead.start_new_thread( def, ( 'thread.err' ) ) --------------- Now view the results with od -ta. You will see that the results are very different. All the the verbose data, on current blocks completed, are missing. Steven Howe ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:59 Message: Logged In: YES user_id=752496 Duplicate of #853411 (the OP says so in the other bug). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-25 16:42 Message: Logged In: YES user_id=139865 This appears to be a duplicate of #853411. The thread on python-dev with subject "Python threads end up blocking signals in subprocesses" discusses this. ---------------------------------------------------------------------- Comment By: Steven Howe (stevenhowe) Date: 2003-12-12 16:02 Message: Logged In: YES user_id=916892 Hello Gaul. Well I found a work around. Using threading.Thread, I init a routine that forks and execv's a script (execv has no method to accept redirects '> 2>') that runs the badblocks program and route output to files. Then I the a thread that uses open() to attach the <stderr> to a progress reading routine and when complete <stdout> for the badblock list (if any). This method created another problem. Popen3 does not return an end of file ( '' ) until the process has ended. With badblocks forked, there is no syncronization between my script and the badblocks output. So I can and do overrun the <stderr> output, which then returns an EOF. Another workaround: I wrote a routine to make sure I never read to the end of file: readsize = os.stat(fname)[stat.ST_SIZE] - fptr.tell() - BIAS All this so I can using threading. No doubt you're asking why use threading? I'm making a pygtk app similar to 'gfloppy' that can handle USB floppies. I need to make a progress meter. Using threading allows a GTK call back to examine the current status of badblocks. But a fix would be preferable. Thanks, Steven Howe ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 07:03 Message: Logged In: YES user_id=139865 Confirmed with Python CVS and Fedora on x86. e2fsprogs/misc/badblocks:alarm_intr sets a SIGALRM handler and calls alarm(1), but it is not getting fired. I will look into this further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 From noreply at sourceforge.net Sat Jan 15 21:34:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 21:34:48 2005 Subject: [ python-Bugs-701836 ] Thread running (os.system or popen#) Message-ID: Bugs item #701836, was opened at 2003-03-11 18:46 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: Thread running (os.system or popen#) Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p <pid>) ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:34 Message: Logged In: YES user_id=752496 Works ok for me: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import thread, os >>> thread.start_new_thread(os.system,("/usr/sbin/ntpdate ifi.uio.no",)) -1210684496 >>> ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Johan Fredrik ?hman (johanfo) Date: 2003-03-12 13:12 Message: Logged In: YES user_id=556425 I have verified this bug on both Redhat 8.0 and SuSE 8.1, linux yes. Signal is one possible path, filedescriptors another. I read somwhere that there was some issues with pthreads forking and filedescriptors. However, this is not my area (too low level).... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-12 09:40 Message: Logged In: YES user_id=6656 IIRC, threads other than the main thread get a signal mask that blocks everything. That could be the problem, but I don't know what to do about it... What platform are you on? Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply at sourceforge.net Sat Jan 15 21:48:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 21:48:17 2005 Subject: [ python-Bugs-768649 ] popen4 doesn't close filedescriptors when in Threads Message-ID: Bugs item #768649, was opened at 2003-07-09 15:36 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: martin doudoroff (mdoudoroff) Assigned to: Nobody/Anonymous (nobody) Summary: popen4 doesn't close filedescriptors when in Threads Initial Comment: Running the following code under Linux will result in a crash on the 508th thread started. The error is OSError: [Errno 24] Too many open files The nature of the bug seems to be that Python isn't closing filedescriptors cleanly when running a thread. --------------------------------------- import os from threading import Thread class Crash(Thread): def run(self): a = os.popen4('ls') b = a[1].read() # uncommenting these lines fixes the problem # but this isn't really documented as far as # we can tell... # a[0].close() # a[1].close() for i in range(1000): t = Crash() t.start() while t.isAlive(): pass print i --------------------------------------- The same code without threads (Crash as a plain class) doesn't crash, so the descriptor must be getting taken care of when the run() method is exited. import os class Crash: def run(self): a = os.popen4('ls') b = a[1].read() for i in range(1000): t = Crash() t.run() print i ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:48 Message: Logged In: YES user_id=752496 Works fine to me: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 with glibc-2.3.4-2 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:48 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-01 15:51 Message: Logged In: YES user_id=139865 Duplicated with Python 2.3 on Red Hat 7.3 using glibc-2.2.5-43. Popen3.{poll,wait} are written under the incorrect assumption that waitpid can monitor any process in the same process group, when it only works for immediate children. _active.remove is never called, so Popen3 objects are never destroyed and the associated file descriptors are not returned to the operating system. A general solution for Popen[34] is not obvious to me. With patch #816059, popen2.popen[234] plugs the _active leak, which in turn returns the file descriptors to the operating system when the file objects that popen2.popen[234] return go out of scope. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:20 Message: Logged In: YES user_id=33168 I can't duplicate this on Redhat 9. What OS, what version of glibc and what kernel are you using? Does it always crash on the 508th iteration? I tested with both 2.2.3 and 2.3b2 from CVS without problems. I even used ulimit to set my open files to 10. Can you try the patch in bug #761888 to see if that helps? http://pythong.org/sf/761888 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470 From noreply at sourceforge.net Sat Jan 15 21:55:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 21:55:22 2005 Subject: [ python-Bugs-1100673 ] Python Interpreter shell is crashed Message-ID: Bugs item #1100673, was opened at 2005-01-12 02:49 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: abhishek (abhishekkabra) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter shell is crashed Initial Comment: I faced this problem about 50 % of time when I hit follwing commands on python shell. But I think Crash of interpreter is not a expected behaviour. It should throw some error even if I am wrong/ hitting wrong commands 1. on shell of linux start python 2 On python shell hit _doc__ ( underscore doc underscore underscore ) So Python shell is crashed with following crash dump darwin{akabra}6: python Python 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> _doc__Segmentation fault (core dumped) darwin{akabra}7: ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:55 Message: Logged In: YES user_id=752496 Works ok to me. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Puneet (puneet_mnitian) Date: 2005-01-13 02:46 Message: Logged In: YES user_id=1196195 Not reproducible ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-12 16:16 Message: Logged In: YES user_id=6656 That's certainly not expected behaviour, however I think it's unlikely to be a python bug -- I've not heard of this behaviour before. Is python using readline? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100673&group_id=5470 From noreply at sourceforge.net Sat Jan 15 22:26:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 22:26:45 2005 Subject: [ python-Bugs-771429 ] Signals discard one level of exception handling Message-ID: Bugs item #771429, was opened at 2003-07-15 03:57 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Signals discard one level of exception handling Initial Comment: Signals handled by Python (especially KeyboardInterrupt) may discard one level of exception handling. Consider the following code fragment: try: # outer exception handling level try: # inner exception handling level blocking_external_extension_function() except: print "inner exception handling" except: print "outer exception handling" Assume that "blocking_external_extension_function" is an external function (implemented in "C") that blocks until interrupted by a signal (EINTR) and then returns with an exception but without handling the signal. In our concrete case, "blocking_external_extension_function" has been "psycopg.connect" (the database "connect" from the Python-PostgreSQL bridge "psycopg"). In this case, when you interrupt the execution, while "blocking_external_extension_function" waits, the "KeyboardInterrupt" is not caught in the inner "try: ...except: ..." but only in the outer "try: ... except: ..." The following happens in detail in Python's main interpreter loop: * "blocking_external_extension_function" returns with an exception. * Python sets the next instruction to the exception handler of the inner exception handling * Python begins a new run through its main loop. At the start, it detects the "KeyboardInterrupt" signal. It now thinks, the "KeyboardInterrupt" were caused inside the inner exception handler and pops this exception handling level without executing it. The interpreter has lost one level of exception handling. The behaviour would probably better fit with expectations, when the interpreter would check for signals at the end of its main loop and before it sets its instruction pointer to the exception handler. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:26 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:33 Message: Logged In: YES user_id=6656 Oh, after some judicious view-sourcing and query-replacing, I get the problem. However, I can't reproduce it (see attached script). So we're back to needing a failing example and more platform details. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:16 Message: Logged In: YES user_id=6656 In addition, attaching any code samples rather than including them would seem a good idea. I can't make head or tail of the code in the summary. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-08 20:45 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 From noreply at sourceforge.net Sat Jan 15 22:27:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 22:27:28 2005 Subject: [ python-Bugs-771429 ] Signals discard one level of exception handling Message-ID: Bugs item #771429, was opened at 2003-07-15 03:57 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Signals discard one level of exception handling Initial Comment: Signals handled by Python (especially KeyboardInterrupt) may discard one level of exception handling. Consider the following code fragment: try: # outer exception handling level try: # inner exception handling level blocking_external_extension_function() except: print "inner exception handling" except: print "outer exception handling" Assume that "blocking_external_extension_function" is an external function (implemented in "C") that blocks until interrupted by a signal (EINTR) and then returns with an exception but without handling the signal. In our concrete case, "blocking_external_extension_function" has been "psycopg.connect" (the database "connect" from the Python-PostgreSQL bridge "psycopg"). In this case, when you interrupt the execution, while "blocking_external_extension_function" waits, the "KeyboardInterrupt" is not caught in the inner "try: ...except: ..." but only in the outer "try: ... except: ..." The following happens in detail in Python's main interpreter loop: * "blocking_external_extension_function" returns with an exception. * Python sets the next instruction to the exception handler of the inner exception handling * Python begins a new run through its main loop. At the start, it detects the "KeyboardInterrupt" signal. It now thinks, the "KeyboardInterrupt" were caused inside the inner exception handler and pops this exception handling level without executing it. The interpreter has lost one level of exception handling. The behaviour would probably better fit with expectations, when the interpreter would check for signals at the end of its main loop and before it sets its instruction pointer to the exception handler. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:26 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:33 Message: Logged In: YES user_id=6656 Oh, after some judicious view-sourcing and query-replacing, I get the problem. However, I can't reproduce it (see attached script). So we're back to needing a failing example and more platform details. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-09 08:16 Message: Logged In: YES user_id=6656 In addition, attaching any code samples rather than including them would seem a good idea. I can't make head or tail of the code in the summary. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-08 20:45 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 From noreply at sourceforge.net Sat Jan 15 22:32:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 22:32:55 2005 Subject: [ python-Bugs-629345 ] build does not respect --prefix Message-ID: Bugs item #629345, was opened at 2002-10-27 04:10 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629345&group_id=5470 Category: Build Group: Python 2.1.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Philip Brown (theferret) Assigned to: Nobody/Anonymous (nobody) Summary: build does not respect --prefix Initial Comment: I want to compile python with a different prefix. I use configure --prefix=/my/stuf but some things are still hardcoded to look in /usr/local for example, setup.py This stops extensions like bsddb from being built, even though the include files are present in $prefix/include Even if I go the extra mile to do export CPPFLAGS=/my/stuff, and the configure script successfully detects I have db.h... it STILL does not compile bsddb until I make a link from /my/stuff/include/db.h to /usr/local/include/db.h Please fix all those locations that have hardcodes for /usr/local ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-08 20:56 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Philip Brown (theferret) Date: 2002-10-27 22:53 Message: Logged In: YES user_id=7120 Whats wrong with editing Modules/Setup? How about, "whats wrong with automating the build process in a standard fashion, instead of forcing builders to jump through unneccessary hoops?" Thats what autoconf, etc. is for, after all. LD_LIBRARY_PATH is a standard environment setting, across virtually all modern UNIXen. Most other programs tend to compile a fake program, or some such, to check for existance of a library (like, $CC -o test test.c -ldb, and see if it works) That is a fairly standard autoconf method of checking for libraries, and has the nice side effect of taking advantage of whatever dynamic loading paths the OS happens to use. If you are going to stick with your own methods of probing, you should make those methods as effective as the more common ones. The way to DO that, is to respect LD_LIBRARY_PATH, if it is set. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-27 16:36 Message: Logged In: YES user_id=21627 What's wrong with editing Modules/Setup? ---------------------------------------------------------------------- Comment By: Philip Brown (theferret) Date: 2002-10-27 16:27 Message: Logged In: YES user_id=7120 When trying to detect whether a library is available, you should at least respect LD_LIBRARY_PATH if it is set, rather than hardcoding stuff like /usr/local reguardless of $prefix ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-27 15:54 Message: Logged In: YES user_id=21627 #--prefix specifies what to put in strings instead of /usr/local. No. See ./configure --help: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] ---------------------------------------------------------------------- Comment By: Philip Brown (theferret) Date: 2002-10-27 15:51 Message: Logged In: YES user_id=7120 --prefix specifies what to put in strings instead of /usr/local. It is common practice to install ALL free software under a /usr/local equivalent. eg: /opt/freeware Clearly, /opt/freeware is for ALL freeware, not just for "this package". It is the most consistent to scan whatever was specified for $prefix, rather than to hardcode for /usr/local Additionally, there could conceptually be other stuff in /usr/local that might conflict (which actually happend to me) The whole point of --prefix is to specify a location to use INSTEAD OF /usr/local. If the user/admin explicitly says "do not use /usr/local, use this path instead", you should NOT use /usr/local !! (unless it is in $PATH, $CPPFLAGS, or $LD_LIBRARY_PATH. Which it is not, in my case) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-27 09:20 Message: Logged In: YES user_id=21627 This is by design. --prefix specifies the places to install *this* package (i.e. python), not the places to look for other packages. If you want to find libraries in different locations, edit Modules/Setup appropriately; setup.py is not designed that case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629345&group_id=5470 From noreply at sourceforge.net Sat Jan 15 23:32:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 15 23:32:26 2005 Subject: [ python-Bugs-487471 ] urllib2 proxyhandle won't work. Message-ID: Bugs item #487471, was opened at 2001-11-30 09:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 19:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. . Facundo ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 20:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-30 16:02 Message: Logged In: YES user_id=261020 That last comment was from me (cookie problems, ironically). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-10-30 15:57 Message: Logged In: NO This should be closed. I don't recall which minor version of 2.2 this was introduced at, but there's no need to replace build_opener any more. The most you have to do is to explicitly pass a handler or two to build_opener with appropriately set handler_order attributes. Or you can subclass the handlers. ---------------------------------------------------------------------- Comment By: Micah Stetson (micahs) Date: 2003-05-07 20:29 Message: Logged In: YES user_id=774014 I don't know about Ha Shao, but I have the problem with Python 2.2.2. My work around was to modify urllib2.build_opener to add the user's supplied handlers before the defaults. Shao's idea of a list-like class is probably better. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 18:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? ---------------------------------------------------------------------- Comment By: Ha Shao (hashao) Date: 2001-11-30 10:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 From noreply at sourceforge.net Sun Jan 16 02:00:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 02:00:55 2005 Subject: [ python-Feature Requests-774546 ] popen does not like filenames with spaces Message-ID: Feature Requests item #774546, was opened at 2003-07-20 07:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=774546&group_id=5470 >Category: Python Library >Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-15 20:00 Message: Logged In: YES user_id=80475 The proposed change would not be eligible for backporting as it is a new feature. And since Py2.4 and later already have a preferred solution (in the form of the subprocess modules), will close this feature request as being out-of-date (or least, no longer necessary). Feel free to re-open if the sub-process module does not fully meet your needs. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Think that this should be closed with "Won't fix" specially now that we have the subprocess module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-01 11:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 05:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( cmd ) because piping multiple commands would required parenthesis nesting which does not look nice. The goal is to reach the simplicity of shell scripting. To execute the previous command, one would simple again use the go() method: (stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ).go() Here for my suggestion. It might be more appropriate to post it to a mailing list, to get more feedback ? I am sorry, I am very busy now and won't have time to implement this myself. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-19 07:17 Message: Logged In: YES user_id=139865 Yes, it works. This is also the same behaviour as os.system. os.popen2 allows one to pass either a quoted string or a sequence of strings (pfremy's suggested behaviour). It would be nice to have consistent functionality, and using a sequence would be easier when providing a list of files to be operated on. I am willing to provide a patch if this is the desired functionality. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 18:03 Message: Logged In: YES user_id=80475 Does it work for you if the filename is quoted: "thrill seeker.txt" ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=774546&group_id=5470 From noreply at sourceforge.net Sun Jan 16 04:39:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 04:39:11 2005 Subject: [ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2 Message-ID: Bugs item #711830, was opened at 2003-03-29 10:54 Message generated for change (Comment added) made by misa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: SEEK_{SET,CUR,END} missing in 2.2.2 Initial Comment: Python 1.5.2 used to define SEEK_{SET,CUR,END} both in FCNTL.py and in posixfile.py Python 2.2.2 obsoletes both of them (and the symbols are no longer in FCNTL anyway). A quick grep on the 2.2.2 tree shows me posixfile is the only place that still defines the SEEK_* constants. It seems to me it's wrong to drop the constants (because a deprecated module will eventually be dropped). ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2005-01-15 22:39 Message: Logged In: YES user_id=205865 Did a quick grep in python 2.3.4 - still only defined in posixfile which is deprecated. I didn't notice Martin's question - yes, the os module seems to be the best place to put them. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 12:43 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-29 12:36 Message: Logged In: YES user_id=21627 Would you agree that these constants are best located in the os module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470 From noreply at sourceforge.net Sun Jan 16 09:41:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 09:41:40 2005 Subject: [ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2 Message-ID: Bugs item #711830, was opened at 2003-03-29 16:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: SEEK_{SET,CUR,END} missing in 2.2.2 Initial Comment: Python 1.5.2 used to define SEEK_{SET,CUR,END} both in FCNTL.py and in posixfile.py Python 2.2.2 obsoletes both of them (and the symbols are no longer in FCNTL anyway). A quick grep on the 2.2.2 tree shows me posixfile is the only place that still defines the SEEK_* constants. It seems to me it's wrong to drop the constants (because a deprecated module will eventually be dropped). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-16 09:41 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.84 libos.tex 1.149 NEWS 1.1226 ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2005-01-16 04:39 Message: Logged In: YES user_id=205865 Did a quick grep in python 2.3.4 - still only defined in posixfile which is deprecated. I didn't notice Martin's question - yes, the os module seems to be the best place to put them. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:43 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-29 18:36 Message: Logged In: YES user_id=21627 Would you agree that these constants are best located in the os module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470 From noreply at sourceforge.net Sun Jan 16 11:43:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 11:44:03 2005 Subject: [ python-Feature Requests-774546 ] popen does not like filenames with spaces Message-ID: Feature Requests item #774546, was opened at 2003-07-20 14:29 Message generated for change (Comment added) made by pfremy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=774546&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. ---------------------------------------------------------------------- >Comment By: Philippe Fremy (pfremy) Date: 2005-01-16 11:43 Message: Logged In: YES user_id=233844 I am ok with closing the bug as WONTFIX but I think that: - the documentation to os.popen and the module popen should inform the user about this limitation - the documentatino to os.popen and the module popen should point the user to the new subprocess module Not everybody reads the What's new and people might still be using popen when subprocess does a better job. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-16 02:00 Message: Logged In: YES user_id=80475 The proposed change would not be eligible for backporting as it is a new feature. And since Py2.4 and later already have a preferred solution (in the form of the subprocess modules), will close this feature request as being out-of-date (or least, no longer necessary). Feel free to re-open if the sub-process module does not fully meet your needs. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 20:46 Message: Logged In: YES user_id=752496 Think that this should be closed with "Won't fix" specially now that we have the subprocess module. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 20:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-01 17:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 12:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( cmd ) because piping multiple commands would required parenthesis nesting which does not look nice. The goal is to reach the simplicity of shell scripting. To execute the previous command, one would simple again use the go() method: (stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ).go() Here for my suggestion. It might be more appropriate to post it to a mailing list, to get more feedback ? I am sorry, I am very busy now and won't have time to implement this myself. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-19 14:17 Message: Logged In: YES user_id=139865 Yes, it works. This is also the same behaviour as os.system. os.popen2 allows one to pass either a quoted string or a sequence of strings (pfremy's suggested behaviour). It would be nice to have consistent functionality, and using a sequence would be easier when providing a list of files to be operated on. I am willing to provide a patch if this is the desired functionality. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:03 Message: Logged In: YES user_id=80475 Does it work for you if the filename is quoted: "thrill seeker.txt" ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=774546&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:01:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:01:15 2005 Subject: [ python-Bugs-1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule Message-ID: Bugs item #1103350, was opened at 2005-01-16 16: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=1103350&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: send/recv SEGMENT_SIZE should be used more in socketmodule Initial Comment: socketmodule.c contains a SEGMENT_SIZE define that is used to limit the send/recv buffer size on VMS. But IMO there are two problems: 1) it should also be used on windows, because windows doesn't like a large send/recv buffer either, 2) it should be used in more places: at least sendall, but perhaps also recvfrom, sendto ad 1: see also this bug: http://www.python.org/sf/853507 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103350&group_id=5470 From noreply at sourceforge.net Sun Jan 16 16:07:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:07:32 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 irmen 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: 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 Sun Jan 16 16:12:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 16:12:06 2005 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 19:54 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- >Comment By: Hartmut Goebel (htgoebel) Date: 2005-01-16 16:11 Message: Logged In: YES user_id=376953 Encloded please find a testcase. I've checkt it with 2.3.3. Buf should still persist in 2.3.4 and 2.4. I've checked the CVS diffs and there is no change which would solve it. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 19:42 Message: Logged In: YES user_id=752496 Both bugs are for the same problem, keeping this alive (because it has the patch), closing the other as Duplicate. Regarding the patch, the actual code has something very similar to it, so maybe the bug is already fixed... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 19:42 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 07:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 15:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Sun Jan 16 18:40:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 18:40:49 2005 Subject: [ python-Bugs-1100429 ] TarFile iteration can break (on Windows) if file has links Message-ID: Bugs item #1100429, was opened at 2005-01-11 21:54 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: TarFile iteration can break (on Windows) if file has links Initial Comment: I ran into this with a simple loop trying to detar Pyrex-0.9.3: for info in tarfile: tarfile.extract(info) I called the above immediately after calling tarfile.open, so the returned iterator was an instance of TarIter. The problem is that Pyrex includes some symbolic links. When TarFile.makelink finds that os.symlink is missing (on Windows) it then does getmember to find the info for the referenced file. The getmember method results in a call to getmembers, which loads all the infos into the members list. However, this breaks the TarIter, since it assumes the members have not yet been loaded. Not sure what the best fix for this is; in my script, I switched over to using getmembers rather than the iterator. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-01-16 18:40 Message: Logged In: YES user_id=642936 I wrote a patch (#1103407) that should fix this. Thank you for pointing that out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470 From noreply at sourceforge.net Sun Jan 16 23:01:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 16 23:01:21 2005 Subject: [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-17 15:17 Message generated for change (Comment added) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2005-01-17 09:01 Message: Logged In: YES user_id=6405 This is still an issue. python -c 'import webbrowser;webbrowser.open("http://www.google.com/")' on a system using KDE will exhibit the break. I posted a patch to fix the behaviour in my last message. I just noticed that I invoked diff the wrong way around (though the explanation still stands) - a correct invocation: --- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208 +1100 +++ /usr/lib/python2.3/webbrowser.py 2005-01-17 08:59:58.269989095 +1100 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder = os.environ["BROWSER"].split(os.pathsep) + _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 23:26 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-08-20 10:29 Message: Logged In: YES user_id=6405 This is still an issue... has there been any movement on it outside of this bug report? I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is finding the BROWSER env var as described above, and thus not finding a usable browser. As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but just prepended with its value. Sure, that means that the KDE BROWSER value will be ignored, but it'll still find konqueror. This approach works for me, and I'm sure it'll work for others who have "valid" BROWSER values :) Simple patch against python2.3 (sorry, sf will mangle this, but it's short): --- webbrowser.py 2003-08-20 10:28:07.000000000 +1000 +++ /usr/lib/python2.3/webbrowser.py 2003-08-04 10:18:17.000000000 +1000 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) + _tryorder = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 12:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-03 07:43 Message: Logged In: YES user_id=198518 A week after posting <slrnb5iu1s.t8.matt@sake.mondoinfo.com> ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-24 00:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply at sourceforge.net Mon Jan 17 01:26:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 01:26:47 2005 Subject: [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 04:05 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-16 16:26 Message: Logged In: YES user_id=357491 This is no longer a problem. Closed as "out of date". ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 04:53 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-17 14:14 Message: Logged In: YES user_id=21627 Yes, please attached unified or context diffs to this bug report, preferably using the CVS version of Python (or 2.3a2 if CVS is not possible). ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 11:30 Message: Logged In: YES user_id=732192 It becomes clear for me that making a good help for all systems out there is very difficult. But I could create a better ./configure --help output for python that is comon for all systems. And I can create a patch for the README file that explains the libstdc++ dependencies if you are building with GNU C++. Can I simply add a patch for these to the patch list or how does it work? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-17 10:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 04:24 Message: Logged In: YES user_id=732192 For example.......... The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 03:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx=<compiler> flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-15 05:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply at sourceforge.net Mon Jan 17 03:30:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 03:30:54 2005 Subject: [ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called Message-ID: Bugs item #1090139, was opened at 2004-12-22 20:00 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) Assigned to: Greg Ward (gward) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text:
args
should be changed to:
args
to match the rest of the items on the page. This may require changing the LaTeX. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2005-01-16 21:30 Message: Logged In: YES user_id=14422 This problem stems from the mkpydoc script in Optik's source repository. I've fixed it there (rev 485) so that future merges from Optik's repository into Python's won't resurrect this bug. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-31 04:35 Message: Logged In: YES user_id=469548 I think the optparse documentation is automatically generated from the optik ReST docs, so Greg should take a look at this as well. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-30 20:08 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 From noreply at sourceforge.net Mon Jan 17 06:31:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 06:31:45 2005 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 10:54 Message generated for change (Comment added) made by titus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2005-01-16 21:31 Message: Logged In: YES user_id=23486 Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS. The attached patches are just a filename; you should try downloading them to be sure they're actually a patch ;). A simpe self-contained example is at http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz it works under Python 2.2 or greater & demonstrates the problem. A patch for the current CVS HEAD is at http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff and 2.4 should probably be back-patched as well. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2005-01-16 07:11 Message: Logged In: YES user_id=376953 Encloded please find a testcase. I've checkt it with 2.3.3. Buf should still persist in 2.3.4 and 2.4. I've checked the CVS diffs and there is no change which would solve it. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 10:42 Message: Logged In: YES user_id=752496 Both bugs are for the same problem, keeping this alive (because it has the patch), closing the other as Duplicate. Regarding the patch, the actual code has something very similar to it, so maybe the bug is already fixed... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 10:42 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-18 22:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 06:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Mon Jan 17 15:20:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 15:20:13 2005 Subject: [ python-Bugs-1102469 ] rfc822 Deprecated since release 2.3? Message-ID: Bugs item #1102469, was opened at 2005-01-15 04:40 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102469&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 Deprecated since release 2.3? Initial Comment: rfc822.Message is still subclassed by minetool.Message and httplib.HTTPMessage. It should either 1. upgrade httplib etc to the email package. 2. or make a note in the rfc822 page that it is still being in use 3. or undeprecate rfc822. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-01-18 01:20 Message: Logged In: YES user_id=29957 rfc822 is currently in a state of PendingPendingDeprecation. It would have gained a PendingDeprecationWarning in 2.4, but as you point out, we're still using it in the stdlib. This is going to be fixed in 2.5 - the stdlib won't be using it any further. Nonetheless, the warning on the documentation page saying "Use email, instead" is still valid. I'd hate for people to start using rfc822 at this very late stage in it's life. Marking as 'wontfix' ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-15 16:30 Message: Logged In: YES user_id=329382 No, rfc822 is actually not deprecated. It's also used in other parts of the stdlib. Look at the Python-Dev thread from August 2004 "Removing stuff from 2.4". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102469&group_id=5470 From noreply at sourceforge.net Mon Jan 17 15:45:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 15:45:19 2005 Subject: [ python-Bugs-1103926 ] email.base64MIME.header_encode vs RFC 1522 Message-ID: Bugs item #1103926, was opened at 2005-01-17 15:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103926&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ucho (ucho) Assigned to: Nobody/Anonymous (nobody) Summary: email.base64MIME.header_encode vs RFC 1522 Initial Comment: i have a question about email.base64MIME.header_encode. It returns something like: =?iso-8859-2?b?. Shouldn't it be "B" instead "b" ? RFC 1522 says it can be only "Q" or "B" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103926&group_id=5470 From noreply at sourceforge.net Mon Jan 17 16:52:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 16:52:44 2005 Subject: [ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr Message-ID: Bugs item #730222, was opened at 2003-04-30 11:00 Message generated for change (Comment added) made by john_marshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Initial Comment: In the Modules/socketmodule.c file, the inet_pton function implicitly treats "long packed_addr" as a 4-byte object or expects that the required 4-bytes is at &packed_addr[0]-[3]. This is not true under SUPER-UX/SX. In order to get this working right, I changed the data type from "long" to "int". This now works properly. -----Modules/socketmodule.c: #3825 /* 042303; JM; this routine really expects a 4-byte packed_addr * not a long; long on SX is 8-bytes! */ #if SX int packed_addr; #else long packed_addr; #endif ... if (packed_addr == INADDR_NONE) return 0; memcpy(dst, &packed_addr, 4); ----- ---------------------------------------------------------------------- >Comment By: John Marshall (john_marshall) Date: 2005-01-17 10:52 Message: Logged In: YES user_id=768577 I no longer have access to SUPER-UX/SX systems, but the problem must still exist since nothing has changed in the source (I just checked that "long packed_addr" is still used -- SUPER-UX/SX systems support 8-byte longs). The more general patch supplied by nnorwitz should do the trick, though. Thanks, John ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:04 Message: Logged In: YES user_id=752496 This patch is no applied, the bug persists? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:04 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:32 Message: Logged In: YES user_id=33168 Attached is a patch which should fix the problem. There was one other place that needed to be changed. This change is more generic. Let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 From noreply at sourceforge.net Mon Jan 17 17:57:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 17:57:04 2005 Subject: [ python-Bugs-1104021 ] wishlist: os.feed_urandom(input) Message-ID: Bugs item #1104021, was opened at 2005-01-17 16: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=1104021&group_id=5470 Category: Python Library Group: Feature Request 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104021&group_id=5470 From noreply at sourceforge.net Mon Jan 17 21:07:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 21:07:37 2005 Subject: [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE Message-ID: Bugs item #783887, was opened at 2003-08-05 23:00 Message generated for change (Comment added) made by nanjundi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Andy Huibers (ahuibers) Assigned to: Kurt B. Kaiser (kbk) Summary: Tab / Space Configuration Does Not Work in IDLE Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- Comment By: Nanjundi (nanjundi) Date: 2005-01-17 15:07 Message: Logged In: YES user_id=1199110 I got the error. I am using Python 2.3.4. Hitting TAB in the editor advances the cursor by "4" spaces irrespective of the "indent width" in Configure idle...-> Fonts/Tab -> choose indentation size: I did a quick and dirty fix. I had to modify the Line# 915 in file Python23/Lib/idlelib/EditorWindow.py Requires restart of IDLE for the change to take effect. [Before] indentwidth = 3 [After] indentwidth = idleConf.GetOption('main','Indent','num-spaces', default=4,type='int') ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-09-05 19:26 Message: Logged In: YES user_id=149084 I can reproduce this on XP and Linux. Of course, everyone should use 4 spaces :) ---------------------------------------------------------------------- Comment By: Andy Huibers (ahuibers) Date: 2003-08-06 15:09 Message: Logged In: YES user_id=838612 Mmm.. I re-installed the Windows Python-2.3 installer EXE on a fresh PC and I have the problem, even when I hit "Apply" and "OK". It is not a big deal of course, but would be nice if it worked.. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 01:17 Message: Logged In: YES user_id=80475 I cannot reproduce the problem. This may be a silly question, but did you click Apply after changing the setting? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply at sourceforge.net Mon Jan 17 21:55:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 21:55:44 2005 Subject: [ python-Bugs-706595 ] codecs.open and iterators Message-ID: Bugs item #706595, was opened at 2003-03-20 00:02 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Todd Reed (toddreed) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.open and iterators Initial Comment: Greg Aumann originally posted this problem in comp.lang.python on Nov 4, 2002, but I could not find a bug report. I've simply copied his news post, which explains the problem: ----------- Recently I figured out how to use iterators and generators. Quite easy to use and a great improvement. But when I refactored some of my code I came across a discrepancy that seems like it must be a bug. If you use the old file reading idiom with a codec the lines are converted to unicode but if you use the new iterators idiom then they retain the original encoding and the line is returned in non unicode strings. Surely using the new "for line in file:" idiom should give the same result as the old, "while 1: ...." I came across this when using the pythonzh Chinese codecs but the below code uses the cp1252 encoding to illustrate the problem because everyone should have those codecs. The symptoms are the same with both codecs. I am using python 2.2.2 on win2k. Is this definitely a bug, or is it an undocumented 'feature' of the codecs module? Greg Aumann The following code illustrates the problem: ------------------------------------------------------------------------ """Check readline iterator using a codec.""" import codecs fname = 'tmp.txt' f = file(fname, 'w') for i in range(0x82, 0x8c): f.write( '%x, %s\n' % (i, chr(i))) f.close() def test_iter(): print '\ntesting codec iterator.' f = codecs.open(fname, 'r', 'cp1252') for line in f: l = line.rstrip() print repr(l) print repr(l.decode('cp1252')) f.close() def test_readline(): print '\ntesting codec readline.' f = codecs.open(fname, 'r', 'cp1252') while 1: line = f.readline() if not line: break l = line.rstrip() print repr(l) try: print repr(l.decode('cp1252')) except AttributeError, msg: print 'AttributeError', msg f.close() test_iter() test_readline() ------------------------------------------------------------------------ This code gives the following output: ------------------------------------------------------------------------ testing codec iterator. '82, \x82' u'82, \u201a' '83, \x83' u'83, \u0192' '84, \x84' u'84, \u201e' '85, \x85' u'85, \u2026' '86, \x86' u'86, \u2020' '87, \x87' u'87, \u2021' '88, \x88' u'88, \u02c6' '89, \x89' u'89, \u2030' '8a, \x8a' u'8a, \u0160' '8b, \x8b' u'8b, \u2039' testing codec readline. u'82, \u201a' AttributeError 'unicode' object has no attribute 'decode' u'83, \u0192' AttributeError 'unicode' object has no attribute 'decode' u'84, \u201e' AttributeError 'unicode' object has no attribute 'decode' u'85, \u2026' AttributeError 'unicode' object has no attribute 'decode' u'86, \u2020' AttributeError 'unicode' object has no attribute 'decode' u'87, \u2021' AttributeError 'unicode' object has no attribute 'decode' u'88, \u02c6' AttributeError 'unicode' object has no attribute 'decode' u'89, \u2030' AttributeError 'unicode' object has no attribute 'decode' u'8a, \u0160' AttributeError 'unicode' object has no attribute 'decode' u'8b, \u2039' AttributeError 'unicode' object has no attribute 'decode' ------------------------------------------------------------------------ ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-01-17 21:55 Message: Logged In: YES user_id=89016 Using Python 2.4 on Windows the test works perfectly if the broken code that tries to decode the unicode again via cp1252 (i.e. "print repr(l.decode('cp1252'))") is removed. Here is the output: testing codec iterator. u'82, \u201a' u'83, \u0192' u'84, \u201e' u'85, \u2026' u'86, \u2020' u'87, \u2021' u'88, \u02c6' u'89, \u2030' u'8a, \u0160' u'8b, \u2039' testing codec readline. u'82, \u201a' u'83, \u0192' u'84, \u201e' u'85, \u2026' u'86, \u2020' u'87, \u2021' u'88, \u02c6' u'89, \u2030' u'8a, \u0160' u'8b, \u2039' So the output is proper decoded unicode. This bug has been fixed in codecs.py 1.28 (which went into Python 2.3). Closing the bug report. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:38 Message: Logged In: YES user_id=752496 Can not test it so far, all I got is: testing codec iterator. u'82, \u201a' Traceback (most recent call last): ... File "C:\Python24\lib\encodings\cp1252.py", line 22, in decode return codecs.charmap_decode(input,errors,decoding_map) UnicodeEncodeError: 'ascii' codec can't encode character u'\u201a' in position 4: ordinal not in range(128) I'm on Win2k, sp2, with Py2.4 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:38 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-20 10:35 Message: Logged In: YES user_id=38388 That's a bug in the iterator support which was added to the codecs module: the .next() methods should not call the .next() methods on the reader directly, but instead redirect to the .readline() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470 From noreply at sourceforge.net Mon Jan 17 23:54:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 23:54:21 2005 Subject: [ python-Bugs-1104249 ] configure doesn't set up CFLAGS properly Message-ID: Bugs item #1104249, was opened at 2005-01-17 14: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=1104249&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't set up CFLAGS properly Initial Comment: I'm trying to build a 32-bit python on an x86_64 Linux box running Fedora Core 3. Here's my configure command line: CFLAGS=-m32 LDFLAGS=-m32 ../../../python/configure --prefix=/opt/python --enable-shared --enable-ipv6 --enable-profiling --enable-unicode=ucs4 When I try to do a make afterwards, the build immediately fails: gcc -pthread -c -pg -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../../../python/Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ../../../python/Modules/python.c In file included from ../../../python/Include/Python.h:55, from ../../../python/Modules/python.c:3: ../../../python/Include/pyport.h:612:2: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." make: *** [Modules/python.o] Error 1 Notice the lack of "-m32" on the gcc command line. Sure enough, look in the Makefile and LDFLAGS is set correctly, with -m32, but CFLAGS makes no mention of it, nor does BASECFLAGS. If I modify BASECFLAGS by hand, python itself builds OK, but then the shared libraries fail to link because LDSHARED is not having LDFLAGS passed in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104249&group_id=5470 From noreply at sourceforge.net Mon Jan 17 23:55:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 17 23:55:58 2005 Subject: [ python-Bugs-1104249 ] configure doesn't set up CFLAGS properly Message-ID: Bugs item #1104249, was opened at 2005-01-17 14:54 Message generated for change (Comment added) made by bos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104249&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't set up CFLAGS properly Initial Comment: I'm trying to build a 32-bit python on an x86_64 Linux box running Fedora Core 3. Here's my configure command line: CFLAGS=-m32 LDFLAGS=-m32 ../../../python/configure --prefix=/opt/python --enable-shared --enable-ipv6 --enable-profiling --enable-unicode=ucs4 When I try to do a make afterwards, the build immediately fails: gcc -pthread -c -pg -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../../../python/Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ../../../python/Modules/python.c In file included from ../../../python/Include/Python.h:55, from ../../../python/Modules/python.c:3: ../../../python/Include/pyport.h:612:2: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." make: *** [Modules/python.o] Error 1 Notice the lack of "-m32" on the gcc command line. Sure enough, look in the Makefile and LDFLAGS is set correctly, with -m32, but CFLAGS makes no mention of it, nor does BASECFLAGS. If I modify BASECFLAGS by hand, python itself builds OK, but then the shared libraries fail to link because LDSHARED is not having LDFLAGS passed in. ---------------------------------------------------------------------- >Comment By: Bryan O'Sullivan (bos) Date: 2005-01-17 14:55 Message: Logged In: YES user_id=28380 The "correct" (i.e. works for me) way to work around this is to run configure with CC="gcc -32" CXX="g++ -m32" instead of setting CFLAGS and LDFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104249&group_id=5470 From noreply at sourceforge.net Tue Jan 18 00:18:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 00:18:40 2005 Subject: [ python-Bugs-1104249 ] configure doesn't set up CFLAGS properly Message-ID: Bugs item #1104249, was opened at 2005-01-17 23:54 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104249&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bryan O'Sullivan (bos) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't set up CFLAGS properly Initial Comment: I'm trying to build a 32-bit python on an x86_64 Linux box running Fedora Core 3. Here's my configure command line: CFLAGS=-m32 LDFLAGS=-m32 ../../../python/configure --prefix=/opt/python --enable-shared --enable-ipv6 --enable-profiling --enable-unicode=ucs4 When I try to do a make afterwards, the build immediately fails: gcc -pthread -c -pg -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../../../python/Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ../../../python/Modules/python.c In file included from ../../../python/Include/Python.h:55, from ../../../python/Modules/python.c:3: ../../../python/Include/pyport.h:612:2: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." make: *** [Modules/python.o] Error 1 Notice the lack of "-m32" on the gcc command line. Sure enough, look in the Makefile and LDFLAGS is set correctly, with -m32, but CFLAGS makes no mention of it, nor does BASECFLAGS. If I modify BASECFLAGS by hand, python itself builds OK, but then the shared libraries fail to link because LDSHARED is not having LDFLAGS passed in. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-01-18 00:18 Message: Logged In: YES user_id=38388 Try using LDSHARED instead. This works for compiling extensions on x86_64 (using C shell): setenv CCSHARED "-m32 -fPIC" setenv LDSHARED "gcc -m32 -shared" ---------------------------------------------------------------------- Comment By: Bryan O'Sullivan (bos) Date: 2005-01-17 23:55 Message: Logged In: YES user_id=28380 The "correct" (i.e. works for me) way to work around this is to run configure with CC="gcc -32" CXX="g++ -m32" instead of setting CFLAGS and LDFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104249&group_id=5470 From noreply at sourceforge.net Tue Jan 18 12:25:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 12:25:55 2005 Subject: [ python-Bugs-1072404 ] Bugs in _csv module - lineterminator Message-ID: Bugs item #1072404, was opened at 2004-11-24 12:00 Message generated for change (Comment added) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470 Category: Python Library Group: None >Status: Open >Resolution: None >Priority: 1 Submitted By: Chris Withers (fresh) Assigned to: Andrew McNamara (andrewmcnamara) Summary: Bugs in _csv module - lineterminator Initial Comment: On trying to parse a '\r' terminated csv generated on a Mac, I get a "newline inside string" error from the csv module. Two things sprung to mind having read: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_csv.c?rev=1.15&view=markup ...for a bit. 1. The Dialect's lineterminator doesn't appear to be used when parsing a CSV. This feels like a bug to be, 'cos I could specify the terminator if Reader_iternext(ReaderObj *self) used it :-S 2. The processing in Reader_iternext(ReaderObj *self) assumes that a '\r' will be followed by '\0' for Macs, '\n' for windows, and anything else is an error. but: >>> c = open('var\data\metadata.csv').read() >>> c[:100] 'BENEFIT,,Subjects relating to all benefits,AB \rBENEFIT,PARTNERDIED,Bereavement Should I be expecting to see a '\0' there? Anyway, the real bug seems to be the reader's ignorance of the lineterminator. However, even if my analysis is off the mark, the problem still exists :-S cheers, Chris ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2005-01-18 11:25 Message: Logged In: YES user_id=24723 I don't think its fair to close this as a rejection. The documentation implies that you can control what line terminator this module uses, which currently isn't the case. I'm not saying this is a high priority issue, just that it shouldn't be rejected in case some day someone (maybe even me ;-) wants to haev a goat fixing it... ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-13 04:14 Message: Logged In: YES user_id=698599 The reader expects to be supplied an iterator that returns lines - in this case, the file iterator has not recognised \r as end-of-line and has read the whole file in and yielded that as a "line". If you use universal-newline mode on your source file, you should have more luck. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-25 04:23 Message: Logged In: YES user_id=44345 This is a known problem. See the April archives of the csv mailing list: http://manatee.mojam.com/pipermail/csv/2004-April/thread.html Solutions are welcome. I suspect any solution will involve either discarding PyIter_Next altogether or further subdividing what it returns. A couple things to note in the way of workarounds: 1. Reader_iternext() defers to PyIter_Next() to grab the next line, so there's really no opportunity to interject the lineterminator into the operation with the current code. This means reading from StringIO objects that use \r lineterminators will always fail. 2. If you have a real file as input and open it in universal newline mode you will get the correct behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470 From noreply at sourceforge.net Tue Jan 18 13:11:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 13:11:42 2005 Subject: [ python-Bugs-1072404 ] Bugs in _csv module - lineterminator Message-ID: Bugs item #1072404, was opened at 2004-11-24 23:00 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 1 Submitted By: Chris Withers (fresh) Assigned to: Andrew McNamara (andrewmcnamara) Summary: Bugs in _csv module - lineterminator Initial Comment: On trying to parse a '\r' terminated csv generated on a Mac, I get a "newline inside string" error from the csv module. Two things sprung to mind having read: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_csv.c?rev=1.15&view=markup ...for a bit. 1. The Dialect's lineterminator doesn't appear to be used when parsing a CSV. This feels like a bug to be, 'cos I could specify the terminator if Reader_iternext(ReaderObj *self) used it :-S 2. The processing in Reader_iternext(ReaderObj *self) assumes that a '\r' will be followed by '\0' for Macs, '\n' for windows, and anything else is an error. but: >>> c = open('var\data\metadata.csv').read() >>> c[:100] 'BENEFIT,,Subjects relating to all benefits,AB \rBENEFIT,PARTNERDIED,Bereavement Should I be expecting to see a '\0' there? Anyway, the real bug seems to be the reader's ignorance of the lineterminator. However, even if my analysis is off the mark, the problem still exists :-S cheers, Chris ---------------------------------------------------------------------- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-18 23:11 Message: Logged In: YES user_id=698599 This cannot be fixed with the current interface - the line splitting is being done by the file iterator, and it only supports \r and \n. As I said, you'll get better results with universal newline mode. The parser in Python 2.5 (the CVS HEAD) has been improved somewhat, but it's still not possible to use anything other than \r and \n for end-of-line. The documentation has been updated to reflect this fact. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2005-01-18 22:25 Message: Logged In: YES user_id=24723 I don't think its fair to close this as a rejection. The documentation implies that you can control what line terminator this module uses, which currently isn't the case. I'm not saying this is a high priority issue, just that it shouldn't be rejected in case some day someone (maybe even me ;-) wants to haev a goat fixing it... ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-13 15:14 Message: Logged In: YES user_id=698599 The reader expects to be supplied an iterator that returns lines - in this case, the file iterator has not recognised \r as end-of-line and has read the whole file in and yielded that as a "line". If you use universal-newline mode on your source file, you should have more luck. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-25 15:23 Message: Logged In: YES user_id=44345 This is a known problem. See the April archives of the csv mailing list: http://manatee.mojam.com/pipermail/csv/2004-April/thread.html Solutions are welcome. I suspect any solution will involve either discarding PyIter_Next altogether or further subdividing what it returns. A couple things to note in the way of workarounds: 1. Reader_iternext() defers to PyIter_Next() to grab the next line, so there's really no opportunity to interject the lineterminator into the operation with the current code. This means reading from StringIO objects that use \r lineterminators will always fail. 2. If you have a real file as input and open it in universal newline mode you will get the correct behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072404&group_id=5470 From noreply at sourceforge.net Tue Jan 18 17:49:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 17:49:19 2005 Subject: [ python-Bugs-1104608 ] Wrong expression with \w+? Message-ID: Bugs item #1104608, was opened at 2005-01-18 17: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=1104608&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 expression with \w+? Initial Comment: str = 'match the url www.junit.org with following regex' regex = re.compile('(www\.\w+?\.\w+?)') print regex.sub('\1', str) # It produces match the url www.junit.org with following regex # It should produce match the url www.junit.org with following regex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470 From noreply at sourceforge.net Tue Jan 18 18:23:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 18:23:53 2005 Subject: [ python-Bugs-1104608 ] Wrong expression with \w+? Message-ID: Bugs item #1104608, was opened at 2005-01-18 17:49 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470 Category: Regular Expressions Group: Python 2.4 >Status: Deleted >Resolution: Wont Fix Priority: 5 Submitted By: rengel (engel_re) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Wrong expression with \w+? Initial Comment: str = 'match the url www.junit.org with following regex' regex = re.compile('(www\.\w+?\.\w+?)') print regex.sub('\1', str) # It produces match the url www.junit.org with following regex # It should produce match the url www.junit.org with following regex ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-01-18 18:23 Message: Logged In: YES user_id=38376 No, it shouldn't. "+?" means the shortest possible match that's one character or more. If you want the longest possible match, get rid of the "?". (in this case, I'd use "(www[.\w]*)") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470 From noreply at sourceforge.net Tue Jan 18 18:26:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 18:26:03 2005 Subject: [ python-Bugs-1104608 ] Wrong expression with \w+? Message-ID: Bugs item #1104608, was opened at 2005-01-18 16:49 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&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 expression with \w+? Initial Comment: str = 'match the url www.junit.org with following regex' regex = re.compile('(www\.\w+?\.\w+?)') print regex.sub('\1', str) # It produces match the url www.junit.org with following regex # It should produce match the url www.junit.org with following regex ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2005-01-18 17:25 Message: Logged In: YES user_id=7887 There's nothing wrong with this result. You asked for a non-greedy match (you've used '\w+?', not '\w+'), and SRE gave you the minimum possible match. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-01-18 17:23 Message: Logged In: YES user_id=38376 No, it shouldn't. "+?" means the shortest possible match that's one character or more. If you want the longest possible match, get rid of the "?". (in this case, I'd use "(www[.\w]*)") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104608&group_id=5470 From noreply at sourceforge.net Tue Jan 18 23:03:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 18 23:03:51 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 (Comment added) made by cjwhrh 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: Nobody/Anonymous (nobody) 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: 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 Wed Jan 19 01:58:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 01:58:37 2005 Subject: [ python-Bugs-1104923 ] Bug in String rstrip method Message-ID: Bugs item #1104923, was opened at 2005-01-18 17:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rick Coupland (rcouplan) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in String rstrip method Initial Comment: There appears to be a data sensitive bug in the string rstrip method as demonstrated by the following code: >>> "ecigrcal.fle".rstrip(".fle") 'ecigrca' As you can see, it is striping an extra character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470 From noreply at sourceforge.net Wed Jan 19 02:51:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 02:51:55 2005 Subject: [ python-Bugs-1104923 ] Bug in String rstrip method Message-ID: Bugs item #1104923, was opened at 2005-01-18 19:58 Message generated for change (Comment added) made by dsm001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rick Coupland (rcouplan) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in String rstrip method Initial Comment: There appears to be a data sensitive bug in the string rstrip method as demonstrated by the following code: >>> "ecigrcal.fle".rstrip(".fle") 'ecigrca' As you can see, it is striping an extra character. ---------------------------------------------------------------------- Comment By: DSM (dsm001) Date: 2005-01-18 20:51 Message: Logged In: YES user_id=1175690 I don't think this is a bug. The documentation for the rstrip method reads: rstrip(...) S.rstrip([chars]) -> string or unicode Return a copy of the string S with trailing whitespace removed. If chars is given and not None, remove characters in chars instead. When you pass the method ".rle", you're telling it to treat the four characters ".", "r", "l", and "e" as trailing whitespace and remove them from the right side of the string. That's why it removes the extra "l". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470 From noreply at sourceforge.net Wed Jan 19 02:56:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 02:56:25 2005 Subject: [ python-Bugs-1104923 ] Bug in String rstrip method Message-ID: Bugs item #1104923, was opened at 2005-01-18 19:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Rick Coupland (rcouplan) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in String rstrip method Initial Comment: There appears to be a data sensitive bug in the string rstrip method as demonstrated by the following code: >>> "ecigrcal.fle".rstrip(".fle") 'ecigrca' As you can see, it is striping an extra character. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-18 20:56 Message: Logged In: YES user_id=31435 Yes, dsm001 is right. The argument is treated as a _set_ of characters to be stripped, not as a literal string. This is a natural generalization of .rstrip() without any characters, which chops off all whitespace characters (no matter how many there, and no matter what order they appear in). Passing an argument just changes the set of characters it deletes. ---------------------------------------------------------------------- Comment By: DSM (dsm001) Date: 2005-01-18 20:51 Message: Logged In: YES user_id=1175690 I don't think this is a bug. The documentation for the rstrip method reads: rstrip(...) S.rstrip([chars]) -> string or unicode Return a copy of the string S with trailing whitespace removed. If chars is given and not None, remove characters in chars instead. When you pass the method ".rle", you're telling it to treat the four characters ".", "r", "l", and "e" as trailing whitespace and remove them from the right side of the string. That's why it removes the extra "l". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1104923&group_id=5470 From noreply at sourceforge.net Wed Jan 19 05:25:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 05:26:03 2005 Subject: [ python-Bugs-900580 ] IDLE docs broken on OSX Message-ID: Bugs item #900580, was opened at 2004-02-19 14:59 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jonathan Brandmeyer (jbrandmeyer) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE docs broken on OSX Initial Comment: Under Apple's OSX operating system, the variable sys.platform is named'darwin'. In at least one place, idle makes a test to see if thecurrent platform is MS Windows by checking for the substring 'win' insys.platform, which leads to incorrect behavior on the Mac. In particular, in lib/python2.3/idlelib/EditorWindow.py, member function EditorWindow.python_docs() behaves incorrectly on OS X. I believe that if the test for MS Windows is completely removed that you will get correct behavior on all platforms, based on my reading of the webbrowser module source. Please change that function to the following (near line 313): >>> def python_docs(self, event=None): >>> webbrowser.open(self.help_url) >>> return "break" ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-18 23:25 Message: Logged In: YES user_id=149084 Backported to 2.3.5 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-15 00:01 Message: Logged In: YES user_id=149084 EditorWindow.py 1.60 configHelpSourceEdit.py 1.7 Backport candidate. Please test on Mac. ---------------------------------------------------------------------- Comment By: Jonathan Brandmeyer (jbrandmeyer) Date: 2004-03-02 14:06 Message: Logged In: YES user_id=676765 There are a series of changes related to the one I mentioned before. In addition, Safari requires the full URI to local files when started via the webbrowser module (or via several other methods) even though it automatically prepends that string when entered in the address bar. So, I have an additional patch that makes appropriate modifications for file:/// prefixed paths. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470 From noreply at sourceforge.net Wed Jan 19 06:06:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 06:06:52 2005 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-14 16:58 Message generated for change (Comment added) made by fdrake 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: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 00: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 10: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 Wed Jan 19 06:09:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 06:09:47 2005 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-14 16:58 Message generated for change (Comment added) made by fdrake 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: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 00: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 00: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 10: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 Wed Jan 19 07:04:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:04:10 2005 Subject: [ python-Bugs-853800 ] No documentation for zipimport module Message-ID: Bugs item #853800, was opened at 2003-12-03 22:35 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: No documentation for zipimport module Initial Comment: It doesn't appear that the zipimport module is documented in Python 2.3.2, apart from a note in the "what's new in Python 2.3" section. It should really be in the list of all standard modules. Presumably the help(zipimport) contents could form the basis of this documentation. I'd be willing to put a patch together for this if someone gives me clear guidelines about what should be there. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:04 Message: Logged In: YES user_id=3066 Committed modified patch for the trunk, release24-maint, and release23-maint branches. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-02-16 21:44 Message: Logged In: YES user_id=552329 New version with correct PEP references. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-02-16 19:56 Message: Logged In: YES user_id=552329 Well, it's been two months (setting up latex2html on cygwin isn't easy! ), but here's something. Attached is a draft module doc for zipimport, and a diff to add it to the library (I wasn't really sure where it belonged, so this diff might be no good it's only one line, anyway). The documentation is a combination of the docstrings, stuff from the PEP, and stuff from the "what's new in 2.3" page. Hope it's ok. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-12-07 12:55 Message: Logged In: YES user_id=92689 The doc strings should indeed be a good start. See also http:// python.org/peps/pep-0273.html and http://python.org/peps/pep- 0302.html for way more details than neccesary for the docs. Feel free to concact me off line if you have more questions; your offer is most welcome! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:12:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:12:13 2005 Subject: [ python-Bugs-1103926 ] email.base64MIME.header_encode vs RFC 1522 Message-ID: Bugs item #1103926, was opened at 2005-01-17 09:45 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103926&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ucho (ucho) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.base64MIME.header_encode vs RFC 1522 Initial Comment: i have a question about email.base64MIME.header_encode. It returns something like: =?iso-8859-2?b?. Shouldn't it be "B" instead "b" ? RFC 1522 says it can be only "Q" or "B" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103926&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:25:24 2005 Subject: [ python-Bugs-1093173 ] distutils/tests not installed Message-ID: Bugs item #1093173, was opened at 2004-12-30 04:43 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:25 Message: Logged In: YES user_id=3066 Committed the patch on the trunk and release24-maint branch (Makefile.pre.in revisions 1.150, 1.148.2.1.) Yes, distutils.tests should have been distutils.test for consistency; sorry. Habits die hard, though, and we use "tests" at work. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-01-09 09:03 Message: Logged In: YES user_id=4771 Attachment was corrupted?? Second try... ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-01-09 08:55 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-01-09 08:53 Message: Logged In: YES user_id=4771 Patch attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 09:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:33:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:33:20 2005 Subject: [ python-Bugs-1097834 ] urllib2 doesn't handle urls without a scheme Message-ID: Bugs item #1097834, was opened at 2005-01-07 07:49 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097834&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without a scheme Initial Comment: Unlike urllib, urllib2 does not handle "/path/to/file" style urls (without a scheme) as "file:" urls. I'm not sure whether this is a bug per se, but if this behaviour is by design then urllib2 should get a pathname2url() method that changes a pathname to a "file:"-prefixed url. urllib.pathname2url() does not prefix the url, but that's fine because urllib.urlopen() treats urls without schemes as file: urls. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 01:33 Message: Logged In: YES user_id=3066 There's no such thing as a URL without a scheme, regardless of what browsers do. The best thing to do is to determine the "base" to which a relative URL reference (whcih can have the scheme omitted) should be resolved, and join the base and relative URL reference using urlparse.urljoin(base, rel). Closing as "not a bug". urllib.pathname2url() is a problem in it's own right; it doesn't behave consistently across Windows and Unix. On Windows, pathname2url() returns too many slashes, or it returns too few on Unix. I've been using helper functions that hide that difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097834&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:35:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:35:46 2005 Subject: [ python-Bugs-839709 ] Windows non-MS compiler doc updates Message-ID: Bugs item #839709, was opened at 2003-11-10 21:47 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Windows non-MS compiler doc updates Initial Comment: Documents affected: http://www.python.org/doc/2.3.2/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3.1/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.2.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1/inst/tweak-flags.html sec. 3.1.2 1. Filenames in the examples are way out of date. It is also not clear to the reader that python23.dll is located in %SystemRoot%\System32. I suggest that you change the pexports command line example to pexports \Windows\System32\python23.dll > python23.def In the Python 2.2 docs, use python22.dll and python22.def. In the Python 2.1 docs, use python21.dll and python21.def. 2. It's not clear to the reader where dlltool is. dlltool can also output directly to the right directory. I suggest that you change the dlltool command line example to \cygwin\bin\dlltool --dllname python23.dll --def python23.def --output-lib \Python23\Libs\libpython23.a In the Python 2.2 docs, use python22.dll, python22.def, and libpython22.a. In the Python 2.1 docs, use python21.dll, python21.def and libpython21.a. 3. Another filename out of date. I suggest that you change "The resulting library has to be placed in the same directory as python20.lib." to "The resulting library has to be placed in the same directory as python23.lib." In the Python 2.2 docs, use python22.lib. In the Python 2.1 docs, use python21.lib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 From noreply at sourceforge.net Wed Jan 19 07:38:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 07:39:01 2005 Subject: [ python-Bugs-973579 ] Doc error on super(cls,self) Message-ID: Bugs item #973579, was opened at 2004-06-15 18:43 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc error on super(cls,self) Initial Comment: In both the Library Reference, section 2.1, and in the Python 2.2 Quick Reference, page 19, the explanation for this function is: super( type[, object-or-type]) Returns the superclass of type. ... This is misleading. I could not get this function to work right until I realized that it is searching the entire MRO, not just the superclasses of 'type'. See comp.lang.python 6/11/04, same subject as above, for further discussion and an example. I think a better explanation would be: super(cls,self).m(arg) Calls method 'm' from a class in the MRO (Method Resolution Order) of 'self'. The selected class is the first one which is above 'cls' in the MRO and which contains 'm'. The 'super' built-in function actually returns not a class, but a 'super' object. This object can be saved, like a bound method, and later used to do a new search of the MRO for a different method to be applied to the saved instance. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2004-07-21 11:20 Message: Logged In: YES user_id=676422 While waiting for the perfect solution, would it be possible to have links to this item at the places in the documentation where the corrections should be made (Library Reference 2.1, Quick Reference page 19)? It could save an hour of experimentation for each new user of this feature. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2004-06-21 12:23 Message: Logged In: YES user_id=676422 I like the example, but the new explanation still leaves the impression that super() returns a class ( or something that acts like a class). This is what made super() so difficult to figure out the first time I tried it. The 'super' object returned by the function appears to be a collection of references, one to the 'self' instance, and one to each of the classes in the MRO of self above 'cls'. The reason it can't be just a class is that a given super object needs to retrieve a different class each time it is used, depending on what method is provided. The only thing lacking in the example is motivation for why we need super(B,self).meth(arg) instead of just calling C.meth (self,arg). I have a longer example and some motivation on page 16 in my OOP chapter at http://ece.arizona.edu/~edatools/Python/PythonOOP.doc but that may be too long if what we need here is a "man page" explanation. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-21 10:50 Message: Logged In: YES user_id=764593 Would an expanded example also help? I'm not sure I like my own wording yet, but ... I propose it as a straw man. """super returns the next parent class[1] class A(object): pass class B(A): def meth(self, arg): super(B, self).meth(arg) class C(A): pass class D(B, C): pass d=D() d.meth() In this case, the super(B, self) call will actually return a reference to class C. Class C is not a parent of class B, but it is the next parent for this particular instance d of class B. [1] Actually, a super class mimicing the parent class. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 From noreply at sourceforge.net Wed Jan 19 08:21:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 08:21:16 2005 Subject: [ python-Bugs-1064535 ] IDLE doesn't start again when saving empty key set Message-ID: Bugs item #1064535, was opened at 2004-11-11 10:06 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1064535&group_id=5470 Category: IDLE Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't start again when saving empty key set Initial Comment: To reproduce: - Start IDLE - Go to Options/Configure IDLE/Keys - Click in "Save as New..." *without selecting anything before* - Enter any name in the textbox. - Ok/Apply/Ok - Close IDLE. IDLE doesn't start again. Workaround: - delete the user's .idlerc/config-main.cfg file Python 2.3.4 Windows 2000 pro Spanish version. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-19 02:21 Message: Logged In: YES user_id=149084 Backported to 2.3.5 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-11-16 16:33 Message: Logged In: YES user_id=149084 configDialog.py 1.60 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2004-11-11 10:41 Message: Logged In: YES user_id=112690 The same behaviour is happening if you select a key from the list before saving. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1064535&group_id=5470 From noreply at sourceforge.net Wed Jan 19 08:24:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 08:24:52 2005 Subject: [ python-Bugs-1008998 ] vertical bar typeset horizontal in docs Message-ID: Bugs item #1008998, was opened at 2004-08-13 18:30 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008998&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alan (aisaac0) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: vertical bar typeset horizontal in docs Initial Comment: I noticed a bug in the PDF version of the Python 2.3 docs. The PDF production tries to typeset the vertical bar '|' in textmode. An example of this problem is the documentation for set union, which looks like s--t instead of s|t. To typeset the vertical bar either i. use $|$ ii. use \texttt{|} or iii. change the encoding ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-19 02:24 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libsets.tex revisions 1.16, 1.15.4.1, 1.11.16.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008998&group_id=5470 From noreply at sourceforge.net Wed Jan 19 14:45:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 14:45:18 2005 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-14 16:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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: Tim Peters (tim_one) Date: 2005-01-19 08: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 00: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 00: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 10: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 Wed Jan 19 14:51:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 14:51:43 2005 Subject: [ python-Bugs-1102649 ] pickle files should be opened in binary mode Message-ID: Bugs item #1102649, was opened at 2005-01-15 08:58 Message generated for change (Comment added) made by sjmachin 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: John Machin (sjmachin) Date: 2005-01-20 00: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-20 00: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 16: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 16: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-17 02: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 Wed Jan 19 16:04:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 16:04:33 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 16: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=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Wed Jan 19 17:56:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 17:57:00 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 10:04 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-19 11:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Wed Jan 19 23:28:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 23:28:39 2005 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-27 00:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-19 23:28 Message: Logged In: YES user_id=21627 I don't think the patch is right. If somebody explicitly invokes sys.stdout.close(), this should have the same effect as invoking fclose(stdout) in C. It currently doesn't, but with meyering's patch from 2004-12-02 10:20, it still doesn't, so the patch is incorrect. It might be better to explicitly invoke fclose() if the file object has no associated f_close function. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-20 00:38 Message: Logged In: YES user_id=203860 Tim, these bugs are quite difficult to trigger, but they can hide any kind of file error and lose arbitrarily large amounts of data. Here, the following program will run indefinitely: full = open('/dev/full', 'w') while 1: print >>full, 'x' * 1023 print >>full It seems to be essential that both the character that fills the file buffer (here it is 1024 bytes long) and the next are generated implicitly by print - otherwise the write error will be detected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-19 23:24 Message: Logged In: YES user_id=31435 Sorry, don't care enough to spend time on it (not a bug I've had, not one I expect to have, don't care if it never changes). Suggest not using /dev/full as an output device . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 01:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-07 00:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 00:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 10:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 11:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 11:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Thu Jan 20 01:52:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 01:52:41 2005 Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0 Message-ID: Bugs item #1105699, was opened at 2005-01-19 19:52 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=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 From noreply at sourceforge.net Thu Jan 20 05:19:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 05:19:14 2005 Subject: [ python-Bugs-1105706 ] incorrect constant names in curses window objects page Message-ID: Bugs item #1105706, was opened at 2005-01-19 23:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105706&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: dcrosta (dcrosta) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect constant names in curses window objects page Initial Comment: The documentation for the border() function in the curses "Window Objects" page (http://www.python.org/doc/2.3.4/lib/curses-window-objects.html) says that ACS_BRCORNER and ACS_BLCORNER are the defaults for the lower left and right corners, respectively. The curses "Constants" page (http://www.python.org/doc/2.3.4/lib/node218.html) has the correct names, ACS_LRCORNER and ACS_LLCORNER, respectively. My system: Python 2.3.4 on Gentoo GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105706&group_id=5470 From noreply at sourceforge.net Thu Jan 20 08:35:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 08:35:08 2005 Subject: [ python-Bugs-1105770 ] null source chars handled oddly Message-ID: Bugs item #1105770, was opened at 2005-01-19 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: null source chars handled oddly Initial Comment: When null characters appear in the source, outside literals, tokenize seems to either: skip the null character and the next two following characters; or ignore the remainder of the line, including the newline character. (To see the invalid characters, use vim, or an editor that displays control characters when needed.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470 From noreply at sourceforge.net Thu Jan 20 10:24:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 10:24:27 2005 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 23:02 Message generated for change (Comment added) made by meyering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2005-01-20 09:24 Message: Logged In: YES user_id=41497 Hi Martin, I would have done that, but sys.stdout.close is already defined *not* to close stdout. Here's the relevant FAQ: 1.4.7 Why doesn't closing sys.stdout (stdin, stderr) really close it? http://www.python.org/doc/faq/library.html#id28 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-19 22:28 Message: Logged In: YES user_id=21627 I don't think the patch is right. If somebody explicitly invokes sys.stdout.close(), this should have the same effect as invoking fclose(stdout) in C. It currently doesn't, but with meyering's patch from 2004-12-02 10:20, it still doesn't, so the patch is incorrect. It might be better to explicitly invoke fclose() if the file object has no associated f_close function. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-19 23:38 Message: Logged In: YES user_id=203860 Tim, these bugs are quite difficult to trigger, but they can hide any kind of file error and lose arbitrarily large amounts of data. Here, the following program will run indefinitely: full = open('/dev/full', 'w') while 1: print >>full, 'x' * 1023 print >>full It seems to be essential that both the character that fills the file buffer (here it is 1024 bytes long) and the next are generated implicitly by print - otherwise the write error will be detected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-19 22:24 Message: Logged In: YES user_id=31435 Sorry, don't care enough to spend time on it (not a bug I've had, not one I expect to have, don't care if it never changes). Suggest not using /dev/full as an output device . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 21:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 00:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-06 23:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 23:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 09:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Thu Jan 20 11:15:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 11:15:46 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 16:04 Message generated for change (Comment added) made by yohell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: YoHell (yohell) Date: 2005-01-20 11:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 17:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Thu Jan 20 14:08:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 14:08:43 2005 Subject: [ python-Bugs-1105950 ] bug with idle's stdout when executing load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 14: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=1105950&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: imperialfists (imperialfists) Assigned to: Nobody/Anonymous (nobody) Summary: bug with idle's stdout when executing load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:04:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:04:09 2005 Subject: [ python-Bugs-1105998 ] os.stat int/float oddity Message-ID: Bugs item #1105998, was opened at 2005-01-20 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=1105998&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat int/float oddity Initial Comment: Since the last change to posixmodule.c(Revision 2.332) by Martin, test_os.py fails on my Linux box. The reason is that when an os.stat object is accessed through obj.attr or obj[index], they do not always represent the same type. Take, for example, st_atime, st_ctime and st_mtime. With Martin's change, if they're accessed like stat_obj.st_atime, it returns a float value. On the other hand, stat_obj[stat.ST_ATIME] still remains to return an integer value. Here is the result of running test_os.py(abbreviated) :: test_tempnam (__main__.TemporaryFileTests) ... ok test_tmpfile (__main__.TemporaryFileTests) ... ok test_tmpnam (__main__.TemporaryFileTests) ... ok test_stat_attributes (__main__.StatAttributeTests) ... FAIL [snip] ========================================== ============================ FAIL: test_stat_attributes (__main__.StatAttributeTests) ------------------------------------------------------- --------------- Traceback (most recent call last): File "./test_os.py", line 115, in test_stat_attributes result[getattr(stat, name)]) AssertionError: 1106224156.927747 != 1106224156 ------------------------------------------------------- --------------- Ran 23 tests in 0.032s FAILED (failures=1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:04:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:04:25 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 10:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 05:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 11:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:05:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:05:44 2005 Subject: [ python-Bugs-1105998 ] os.stat int/float oddity Message-ID: Bugs item #1105998, was opened at 2005-01-20 23:04 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Martin v. L?wis (loewis) Summary: os.stat int/float oddity Initial Comment: Since the last change to posixmodule.c(Revision 2.332) by Martin, test_os.py fails on my Linux box. The reason is that when an os.stat object is accessed through obj.attr or obj[index], they do not always represent the same type. Take, for example, st_atime, st_ctime and st_mtime. With Martin's change, if they're accessed like stat_obj.st_atime, it returns a float value. On the other hand, stat_obj[stat.ST_ATIME] still remains to return an integer value. Here is the result of running test_os.py(abbreviated) :: test_tempnam (__main__.TemporaryFileTests) ... ok test_tmpfile (__main__.TemporaryFileTests) ... ok test_tmpnam (__main__.TemporaryFileTests) ... ok test_stat_attributes (__main__.StatAttributeTests) ... FAIL [snip] ========================================== ============================ FAIL: test_stat_attributes (__main__.StatAttributeTests) ------------------------------------------------------- --------------- Traceback (most recent call last): File "./test_os.py", line 115, in test_stat_attributes result[getattr(stat, name)]) AssertionError: 1106224156.927747 != 1106224156 ------------------------------------------------------- --------------- Ran 23 tests in 0.032s FAILED (failures=1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:28:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:28:30 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 10:04 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Nobody/Anonymous (nobody) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 09:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 05:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 11:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:50:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:50:12 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 10:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) >Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 09:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 05:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 11:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:52:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:52:19 2005 Subject: [ python-Feature Requests-1104021 ] wishlist: os.feed_urandom(input) Message-ID: Feature Requests item #1104021, was opened at 2005-01-17 11:56 Message generated for change (Settings changed) made by rhettinger 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 From noreply at sourceforge.net Thu Jan 20 15:59:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 15:59:29 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 16:04 Message generated for change (Comment added) made by yohell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: YoHell (yohell) Date: 2005-01-20 15:59 Message: Logged In: YES user_id=1008220 Brilliant, guys! Thanks again for a superb scripting language, and with documentation to match! Take care! /Joel Hedlund ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 15:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 11:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 17:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Thu Jan 20 16:18:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 16:19:02 2005 Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0 Message-ID: Bugs item #1105699, was opened at 2005-01-20 00:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-01-20 15:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 From noreply at sourceforge.net Thu Jan 20 16:42:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 16:42:47 2005 Subject: [ python-Bugs-1106057 ] README of 2.4 source download says 2.4a3 Message-ID: Bugs item #1106057, was opened at 2005-01-20 16: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=1106057&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (rogererens) Assigned to: Nobody/Anonymous (nobody) Summary: README of 2.4 source download says 2.4a3 Initial Comment: When using the links http://www.python.org/ftp/python/2.4/Python-2.4.tgz or http://www.python.org/ftp/python/2.4/Python-2.4.tar.bz2 I get to see Python2.4-a3 in the README. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 From noreply at sourceforge.net Thu Jan 20 21:55:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 21:55:57 2005 Subject: [ python-Bugs-1106262 ] semaphore errors from Python 2.3.x on AIX 5.2 Message-ID: Bugs item #1106262, was opened at 2005-01-20 11: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=1106262&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: semaphore errors from Python 2.3.x on AIX 5.2 Initial Comment: Newer versions of the AIX 5.2 libc implement POSIX semaphores and thus define _POSIX_SEMAPHORES in . However, when building Python 2.3.x (and I'm sure any other version with sem_init()), a few semaphore errors are encountered: building 'pcre' extension ./Modules/ld_so_aix gcc -bI:Modules/python.exp -L/opt/TWWfsw/python232/lib/support -Wl,-brtl -Wl,-blibpath:/opt/TWWfsw/python232/lib/support:/usr/lib build/temp.aix-5.2-2.3/pcremodule.o build/temp.aix-5.2-2.3/pypcre.o -L/opt/TWWfsw/python232/lib -o build/lib.aix-5.2-2.3/pcre.so sem_trywait: Permission denied sem_wait: Permission denied sem_post: Permission denied I ran the Python process under truss and saw that the sem_init() from Python/thread_pthread.h worked successfully. fork() was then called and a sem_trywait() operation (probably from PyThread_acquire_lock()) was called. From the sem_init() man page (http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/libs/basetrf2/sem_init.htm): If the pshared parameter has a nonzero value, the semaphore is shared between processes. In this case, any process that can access the sem parameter can use it for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. Only the sem parameter itself may be used for performing synchronization. If the pshared parameter is zero, the semaphore is shared between threads of the process. Any thread in this process can use the sem parameter for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. The use of the semaphore by threads other than those created in the same process returns an error. Setting the 2nd value of sem_init to 1 (was 0) solved the problem. However, I don't know if this is wise for security. Another solution is to set HAVE_BROKEN_POSIX_SEMAPHORES for "AIX/5" like for "SunOS/5.8". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&group_id=5470 From noreply at sourceforge.net Thu Jan 20 23:06:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 23:06:54 2005 Subject: [ python-Bugs-1106316 ] slightly easier way to debug from the exception handler Message-ID: Bugs item #1106316, was opened at 2005-01-20 20: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=1106316&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 From noreply at sourceforge.net Thu Jan 20 23:49:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 23:49:20 2005 Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0 Message-ID: Bugs item #1105699, was opened at 2005-01-19 19:52 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-20 10:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 From noreply at sourceforge.net Thu Jan 20 23:51:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 20 23:51:35 2005 Subject: [ python-Bugs-1106316 ] slightly easier way to debug from the exception handler Message-ID: Bugs item #1106316, was opened at 2005-01-20 17:06 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:51 Message: Logged In: YES user_id=139309 Why put this in pdb.post_mortem() if we can just put it in pdb.pm()? pdb.pm() seems to already be for this purpose (except it currently only works from the interactive interpreter as you mention). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 From noreply at sourceforge.net Fri Jan 21 00:13:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 00:13:10 2005 Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0 Message-ID: Bugs item #1105699, was opened at 2005-01-19 19:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-20 18:13 Message: Logged In: YES user_id=31435 The warning almost certainly means that there's no declaration of struct winsize in scope when these externs are declared. That's bad, because C doesn't guarantee that all pointers are the same size (although they are on all Python platforms I'm aware of). Some quality time with Google suggested that other projects wormed around this by #include'ing instead of , because the former but not the latter #include's where the winsize struct was defined. Beats me -- ain't a Windows problem . ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-20 10:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 From noreply at sourceforge.net Fri Jan 21 09:45:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 09:46:01 2005 Subject: [ python-Bugs-1105950 ] bug with idle's stdout when executing load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 14:08 Message generated for change (Comment added) made by imperialfists You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: imperialfists (imperialfists) Assigned to: Nobody/Anonymous (nobody) Summary: bug with idle's stdout when executing load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- >Comment By: imperialfists (imperialfists) Date: 2005-01-21 09:45 Message: Logged In: YES user_id=1201021 Also i find a file named 'c' in my current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Fri Jan 21 10:42:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 10:42:53 2005 Subject: [ python-Bugs-1106572 ] os.makedirs() ignores mode parameter Message-ID: Bugs item #1106572, was opened at 2005-01-21 04: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=1106572&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() ignores mode parameter Initial Comment: os.makedirs('foo/x', 0777) does not create the directories with permissions g+rwx,u+rwx,o+rwx but instead: >>> import os >>> os.makedirs('foo/xx', 0777) >>> [2]+ Stopped python2.3 ajung@hrs2dev2:~/sandboxes/haufecms/instance/Products/HaufeCMS: ls -la foo insgesamt 12 drwxr-xr-x 3 ajung ajung 4096 2005-01-21 10:39 . drwxr-xr-x 19 ajung ajung 4096 2005-01-21 10:39 .. drwxr-xr-x 2 ajung ajung 4096 2005-01-21 10:39 xx This happens with Python 2.3.4 on Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 From noreply at sourceforge.net Fri Jan 21 14:20:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 14:20:40 2005 Subject: [ python-Bugs-1106316 ] slightly easier way to debug from the exception handler Message-ID: Bugs item #1106316, was opened at 2005-01-20 20:06 Message generated for change (Comment added) made by rochael You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... ---------------------------------------------------------------------- >Comment By: Leonardo Rochael Almeida (rochael) Date: 2005-01-21 11:20 Message: Logged In: YES user_id=200267 I don't have any particular reason to prefer post_mortem() to pm(). The knowledgeable Python maintainers surely are better equiped than I am to know if pm() looking beyond sys.last_traceback is a worse break of assumptions than post_mortem() having it's only parameter being optional or the other way around :-) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 20:51 Message: Logged In: YES user_id=139309 Why put this in pdb.post_mortem() if we can just put it in pdb.pm()? pdb.pm() seems to already be for this purpose (except it currently only works from the interactive interpreter as you mention). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 From noreply at sourceforge.net Fri Jan 21 14:30:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 14:30:08 2005 Subject: [ python-Bugs-1106694 ] split() takes no keyword arguments Message-ID: Bugs item #1106694, was opened at 2005-01-21 13:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Vinz (boukthor) Assigned to: Nobody/Anonymous (nobody) Summary: split() takes no keyword arguments Initial Comment: I'm running python 2.4 on a Linux box (Mandrake cooker 10.2). Since the string functions have been implemented as method of string instances, there's little use for the string module (except for constants). However, the behaviour of the 'split' method is slightly different from the one in the string module : it does not accept keyword arguments. This is annoying because the default separator argument ('any whitespace') cannot be provided manually (at least I couldn't find a way to do it) and that means that you can not use the default separator while specifying a maxsplit argument (if you specify maxsplit, you need to give a separator manually because it comes first in the arg list), unless you use "string.split" (and "import string") syntax. Examples : >>> "foo bar\tbaz\nqux".split() ['foo', 'bar', 'baz', 'qux'] >>> string.split("foo bar\tbaz\nqux") ['foo', 'bar', 'baz', 'qux'] >>> "foo bar\tbaz\nqux".split(" \t\n") # this is ok, just illustrating that you cannot emulate the default behaviour if you provide a separator manually ['foo bar\tbaz\nqux'] >>> string.split("foo bar\tbaz\nqux", maxsplit=2) # what I want to do ['foo', 'bar', 'baz\nqux'] >>> "foo bar\tbaz\nqux".split(maxsplit=2) # what I get Traceback (most recent call last): File "", line 1, in ? TypeError: split() takes no keyword arguments >>> "foo bar\tbaz\nqux".split(2) # cannot skip the sep arg Traceback (most recent call last): File "", line 1, in ? TypeError: expected a character buffer object ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470 From noreply at sourceforge.net Fri Jan 21 20:14:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 21 20:15:27 2005 Subject: [ python-Bugs-1088039 ] CGIHTTPServer: directories/scripts with spaces in their name Message-ID: Bugs item #1088039, was opened at 2004-12-19 19:31 Message generated for change (Comment added) made by ivorocha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088039&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: LT (sweetleon) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer: directories/scripts with spaces in their name Initial Comment: It looks like we're not properly quoting the path the script, and when the script or its directory has a space in its name - quite common on Windoze - it doesn't work. Here's the output: host - - [19/Dec/2004 11:07:01] command: C:\Python24\python.exe -u c:\Documents a nd Settings\User\My Documents\project\cgi-bin\webpage.py "" host - - [19/Dec/2004 11:07:01] C:\Python24\python.exe: can't open file 'c:\Docum ents': [Errno 2] No such file or directory ibm - - [19/Dec/2004 11:07:02] CGI script exit status 0x2 ibm - - [19/Dec/2004 11:07:02] code 404, message File not found ---------------------------------------------------------------------- Comment By: silicio (ivorocha) Date: 2005-01-21 19:14 Message: Logged In: YES user_id=1202006 It's the same problem found in (Request ID 696846). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088039&group_id=5470 From noreply at sourceforge.net Sat Jan 22 11:30:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 22 11:30:07 2005 Subject: [ python-Bugs-904498 ] threading docs, start error should be specified Message-ID: Bugs item #904498, was opened at 2004-02-26 07:00 Message generated for change (Comment added) made by alanvgreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: threading docs, start error should be specified Initial Comment: The docs say it is an error to start a threading thread more than once, but they do not specify exactly what exception will be raised. Apparently it is always AssertionError (though an expert should verify this). It would be very helpful to document the exception because there is no other documented way to tell if a threading thread has been started than to try to start it. I posted to the dev group on 2003-02-24 about this and Aahz asked me to file a doc bug. So here it is. I suggest the info go in the Thread object docs, in the documentation for "start". ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-22 21:30 Message: Logged In: YES user_id=1174944 The actual wording in the documentation is: "This must be called at most once per thread object." To me this implies that the effect of calling start() twice is not defined. There is an assert statement in the implementation of Thread.start(), but - like all assert statements - its behaviour is dependent upon the value of the builtin __debug__ variable. Looking through the rest of the threading module, the documentation could be tightened up, particularly with respect to which behaviours are and aren't defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470 From noreply at sourceforge.net Sat Jan 22 12:07:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 22 12:07:24 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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Jack Jansen (jackjansen) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1107258&group_id=5470 From noreply at sourceforge.net Sat Jan 22 20:03:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 22 20:03:43 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 bcannon 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: 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 Sun Jan 23 06:46:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 06:46:41 2005 Subject: [ python-Bugs-912943 ] 7.5.6 Thread Objects is too vague Message-ID: Bugs item #912943, was opened at 2004-03-10 06:16 Message generated for change (Comment added) made by alanvgreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: 7.5.6 Thread Objects is too vague Initial Comment: Some items which could be improved.... "Once the thread's activity is started, the thread is considered 'alive' and 'active' (these concepts are almost, but not quite exactly, the same; their definition is intentionally somewhat vague)." This is a bit silly. Either these attributes are intended to be exposed to users or they're not. If they are, they should be well defined. If not, they shouldn't be mentioned at all. "If the subclass overrides the constructor, it must make sure to invoke the base class constructor (Thread.__init__()) before doing anything else to the thread." This is misleading. You need to call "Thread.__init__ (self)", i.e. pass along the self argument. At least I think you do :-) "join([timeout]) ... When the timeout argument is present and not None, it should be a floating point number specifying a timeout for the operation in seconds (or fractions thereof)." What happens if you pass None? Does it wait forever? Is this any different from not passing any argument at all? What happens if a timeout occurs? Is there any way to differentiate between a timeout and a normal return? "A thread can be join()ed many times." Presumably only if all but the last call timed out? Or maybe not? If you get a normal return (i.e. not a timeout) from join(), and then call join() again, what happens? Does it just return immediately with no error? ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-23 16:46 Message: Logged In: YES user_id=1174944 Submitted Patch 1107656 which addresses the 'alive' and 'active' issue. It does this by deprecating the isAlive() method and adding an isActive method instead. The patch also updates the documentation to talk about threads being 'active' rather than 'alive and active'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470 From noreply at sourceforge.net Sun Jan 23 10:29:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 10:29:58 2005 Subject: [ python-Bugs-1105998 ] os.stat int/float oddity Message-ID: Bugs item #1105998, was opened at 2005-01-20 15:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: os.stat int/float oddity Initial Comment: Since the last change to posixmodule.c(Revision 2.332) by Martin, test_os.py fails on my Linux box. The reason is that when an os.stat object is accessed through obj.attr or obj[index], they do not always represent the same type. Take, for example, st_atime, st_ctime and st_mtime. With Martin's change, if they're accessed like stat_obj.st_atime, it returns a float value. On the other hand, stat_obj[stat.ST_ATIME] still remains to return an integer value. Here is the result of running test_os.py(abbreviated) :: test_tempnam (__main__.TemporaryFileTests) ... ok test_tmpfile (__main__.TemporaryFileTests) ... ok test_tmpnam (__main__.TemporaryFileTests) ... ok test_stat_attributes (__main__.StatAttributeTests) ... FAIL [snip] ========================================== ============================ FAIL: test_stat_attributes (__main__.StatAttributeTests) ------------------------------------------------------- --------------- Traceback (most recent call last): File "./test_os.py", line 115, in test_stat_attributes result[getattr(stat, name)]) AssertionError: 1106224156.927747 != 1106224156 ------------------------------------------------------- --------------- Ran 23 tests in 0.032s FAILED (failures=1) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-23 10:29 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in test_os.py 1.28 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 From noreply at sourceforge.net Sun Jan 23 10:51:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 10:53:25 2005 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-27 00:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-23 10:51 Message: Logged In: YES user_id=21627 Thanks for the report and the patch. Committed as NEWS 1.1232 sysmodule.c 2.127 NEWS 1.1193.2.15 sysmodule.c 2.126.2.1 NEWS 1.831.4.164 sysmodule.c 2.120.6.2 ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2005-01-20 10:24 Message: Logged In: YES user_id=41497 Hi Martin, I would have done that, but sys.stdout.close is already defined *not* to close stdout. Here's the relevant FAQ: 1.4.7 Why doesn't closing sys.stdout (stdin, stderr) really close it? http://www.python.org/doc/faq/library.html#id28 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-19 23:28 Message: Logged In: YES user_id=21627 I don't think the patch is right. If somebody explicitly invokes sys.stdout.close(), this should have the same effect as invoking fclose(stdout) in C. It currently doesn't, but with meyering's patch from 2004-12-02 10:20, it still doesn't, so the patch is incorrect. It might be better to explicitly invoke fclose() if the file object has no associated f_close function. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-20 00:38 Message: Logged In: YES user_id=203860 Tim, these bugs are quite difficult to trigger, but they can hide any kind of file error and lose arbitrarily large amounts of data. Here, the following program will run indefinitely: full = open('/dev/full', 'w') while 1: print >>full, 'x' * 1023 print >>full It seems to be essential that both the character that fills the file buffer (here it is 1024 bytes long) and the next are generated implicitly by print - otherwise the write error will be detected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-19 23:24 Message: Logged In: YES user_id=31435 Sorry, don't care enough to spend time on it (not a bug I've had, not one I expect to have, don't care if it never changes). Suggest not using /dev/full as an output device . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 01:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-07 00:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 00:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 10:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 11:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 11:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Sun Jan 23 21:38:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 23 21:38:38 2005 Subject: [ python-Bugs-1105950 ] bug with idle's stdout when executing load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 08:08 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: imperialfists (imperialfists) >Assigned to: Kurt B. Kaiser (kbk) Summary: bug with idle's stdout when executing load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-21 03:45 Message: Logged In: YES user_id=1201021 Also i find a file named 'c' in my current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Mon Jan 24 01:10:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 01:11:00 2005 Subject: [ python-Bugs-1105950 ] bug with idle's stdout when executing load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 08:08 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: imperialfists (imperialfists) Assigned to: Kurt B. Kaiser (kbk) Summary: bug with idle's stdout when executing load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-23 19:10 Message: Logged In: YES user_id=149084 These low level imp module functions don't just import, they reload() the module. This destroys the redirection of stdin, stdout, stderr that IDLE has set up to work with Tkinter. Using IDLE without its subprocess, and with verbose output: hydra /home/kbk/PYSRC/Lib/idlelib$ ../../python -v ./PyShell.py -n # installing zipimport hook import zipimport # builtin # installed zipimport hook [...] In the IDLE shell: IDLE 1.2a0 ==== No Subprocess ==== >>> import sys >>> sys.stdout <__main__.PseudoFile object at 0x42feac> >>> reload(sys) >>> sys.stdout >>> And on the console: [...] import sys # previously loaded (sys) ', mode 'w' at 0xfa068> imp.load_source() is incompatible with IDLE. Please use the high level import statements. I didn't find any extra files. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-21 03:45 Message: Logged In: YES user_id=1201021 Also i find a file named 'c' in my current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Mon Jan 24 03:09:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 03:09:04 2005 Subject: [ python-Bugs-1108060 ] "\0" not listed as a valid escape in the lang reference Message-ID: Bugs item #1108060, was opened at 2005-01-24 13: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=1108060&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "\0" not listed as a valid escape in the lang reference Initial Comment: According to table in http://docs.python.org/ref/strings.html, the list of valid escape sequences in strings does not include \0. It appears that the parser actually allows \n for values of n in the range 0-7, but this is not documented. Many people with exposure to C expect \0 to be valid (and it does work, after all!). A quick grep on my system finds many libraries use \0 in string literals, including: - Twisted - HTMLgen - PIL - numarray - Reportlab - and of course the standard library: tarfile, gzip, pystone, binhex, and others. I suggest the documentation be updated to officially support \0 as a valid escape. I don't care as much about \1 through to \7... I was surprised they worked (and then surprised that \8 and \9 didn't), and I think they might as well be deprecated, but I don't care much either way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108060&group_id=5470 From noreply at sourceforge.net Mon Jan 24 03:50:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 03:50:57 2005 Subject: [ python-Bugs-1105950 ] bug with idle's stdout when executing load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 14:08 Message generated for change (Comment added) made by imperialfists You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: imperialfists (imperialfists) Assigned to: Kurt B. Kaiser (kbk) Summary: bug with idle's stdout when executing load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- >Comment By: imperialfists (imperialfists) Date: 2005-01-24 03:50 Message: Logged In: YES user_id=1201021 I did not always find a file named c either, it was more of a random occurance, than something reliably reproducable. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-24 01:10 Message: Logged In: YES user_id=149084 These low level imp module functions don't just import, they reload() the module. This destroys the redirection of stdin, stdout, stderr that IDLE has set up to work with Tkinter. Using IDLE without its subprocess, and with verbose output: hydra /home/kbk/PYSRC/Lib/idlelib$ ../../python -v ./PyShell.py -n # installing zipimport hook import zipimport # builtin # installed zipimport hook [...] In the IDLE shell: IDLE 1.2a0 ==== No Subprocess ==== >>> import sys >>> sys.stdout <__main__.PseudoFile object at 0x42feac> >>> reload(sys) >>> sys.stdout >>> And on the console: [...] import sys # previously loaded (sys) ', mode 'w' at 0xfa068> imp.load_source() is incompatible with IDLE. Please use the high level import statements. I didn't find any extra files. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-21 09:45 Message: Logged In: YES user_id=1201021 Also i find a file named 'c' in my current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Mon Jan 24 03:55:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 03:55:32 2005 Subject: [ python-Bugs-1105950 ] idle's stdout is redirected when executing imp.load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 14:08 Message generated for change (Settings changed) made by imperialfists You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: imperialfists (imperialfists) Assigned to: Kurt B. Kaiser (kbk) >Summary: idle's stdout is redirected when executing imp.load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-24 03:50 Message: Logged In: YES user_id=1201021 I did not always find a file named c either, it was more of a random occurance, than something reliably reproducable. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-24 01:10 Message: Logged In: YES user_id=149084 These low level imp module functions don't just import, they reload() the module. This destroys the redirection of stdin, stdout, stderr that IDLE has set up to work with Tkinter. Using IDLE without its subprocess, and with verbose output: hydra /home/kbk/PYSRC/Lib/idlelib$ ../../python -v ./PyShell.py -n # installing zipimport hook import zipimport # builtin # installed zipimport hook [...] In the IDLE shell: IDLE 1.2a0 ==== No Subprocess ==== >>> import sys >>> sys.stdout <__main__.PseudoFile object at 0x42feac> >>> reload(sys) >>> sys.stdout >>> And on the console: [...] import sys # previously loaded (sys) ', mode 'w' at 0xfa068> imp.load_source() is incompatible with IDLE. Please use the high level import statements. I didn't find any extra files. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-21 09:45 Message: Logged In: YES user_id=1201021 Also i find a file named 'c' in my current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Mon Jan 24 03:59:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 03:59:21 2005 Subject: [ python-Bugs-1105950 ] idle's stdout is redirected when executing imp.load_source Message-ID: Bugs item #1105950, was opened at 2005-01-20 14:08 Message generated for change (Settings changed) made by imperialfists You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 Category: IDLE >Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: imperialfists (imperialfists) Assigned to: Kurt B. Kaiser (kbk) Summary: idle's stdout is redirected when executing imp.load_source Initial Comment: There is a bug in idle caused by load_source, which switches the stdout of idle to something else. Here is what I did: Python 2.3.4 (#1, Nov 2 2004, 11:18:38) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 [...i leave this out...] IDLE 1.0.3 >>> from sys import stdout >>> print stdout >>> print 'a' a >>> from imp import load_source >>> print 'a' a >>> print stdout >>> m = load_source('bug.py', 'bug.py', open('bug.py')) >>> print 'a' >>> print stdout >>> the file 'bug.py' contains the following line: from types import * meanwhile i see this on my terminal: a when i type "import bug" or "from bug import *" everything works fine. This bug also works (at least for me) if I start idle from the the "Run Command" dialog under kde, instead of the terminal. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-24 03:50 Message: Logged In: YES user_id=1201021 I did not always find a file named c either, it was more of a random occurance, than something reliably reproducable. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-24 01:10 Message: Logged In: YES user_id=149084 These low level imp module functions don't just import, they reload() the module. This destroys the redirection of stdin, stdout, stderr that IDLE has set up to work with Tkinter. Using IDLE without its subprocess, and with verbose output: hydra /home/kbk/PYSRC/Lib/idlelib$ ../../python -v ./PyShell.py -n # installing zipimport hook import zipimport # builtin # installed zipimport hook [...] In the IDLE shell: IDLE 1.2a0 ==== No Subprocess ==== >>> import sys >>> sys.stdout <__main__.PseudoFile object at 0x42feac> >>> reload(sys) >>> sys.stdout >>> And on the console: [...] import sys # previously loaded (sys) ', mode 'w' at 0xfa068> imp.load_source() is incompatible with IDLE. Please use the high level import statements. I didn't find any extra files. ---------------------------------------------------------------------- Comment By: imperialfists (imperialfists) Date: 2005-01-21 09:45 Message: Logged In: YES user_id=1201021 Also i find a file named 'c' in my current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470 From noreply at sourceforge.net Mon Jan 24 04:21:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 04:21:52 2005 Subject: [ python-Bugs-1108060 ] "\0" not listed as a valid escape in the lang reference Message-ID: Bugs item #1108060, was opened at 2005-01-23 21:09 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108060&group_id=5470 Category: Documentation >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "\0" not listed as a valid escape in the lang reference Initial Comment: According to table in http://docs.python.org/ref/strings.html, the list of valid escape sequences in strings does not include \0. It appears that the parser actually allows \n for values of n in the range 0-7, but this is not documented. Many people with exposure to C expect \0 to be valid (and it does work, after all!). A quick grep on my system finds many libraries use \0 in string literals, including: - Twisted - HTMLgen - PIL - numarray - Reportlab - and of course the standard library: tarfile, gzip, pystone, binhex, and others. I suggest the documentation be updated to officially support \0 as a valid escape. I don't care as much about \1 through to \7... I was surprised they worked (and then surprised that \8 and \9 didn't), and I think they might as well be deprecated, but I don't care much either way. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-23 22:21 Message: Logged In: YES user_id=31435 Look at the table of escapes again, especially the line with footnotes 3 and 5; that line documents the octal escapes, including all cases you've mentioned here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108060&group_id=5470 From noreply at sourceforge.net Mon Jan 24 05:02:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 05:02:20 2005 Subject: [ python-Bugs-1108060 ] "\0" not listed as a valid escape in the lang reference Message-ID: Bugs item #1108060, was opened at 2005-01-24 13:09 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108060&group_id=5470 Category: Documentation Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: "\0" not listed as a valid escape in the lang reference Initial Comment: According to table in http://docs.python.org/ref/strings.html, the list of valid escape sequences in strings does not include \0. It appears that the parser actually allows \n for values of n in the range 0-7, but this is not documented. Many people with exposure to C expect \0 to be valid (and it does work, after all!). A quick grep on my system finds many libraries use \0 in string literals, including: - Twisted - HTMLgen - PIL - numarray - Reportlab - and of course the standard library: tarfile, gzip, pystone, binhex, and others. I suggest the documentation be updated to officially support \0 as a valid escape. I don't care as much about \1 through to \7... I was surprised they worked (and then surprised that \8 and \9 didn't), and I think they might as well be deprecated, but I don't care much either way. ---------------------------------------------------------------------- >Comment By: Andrew Bennetts (spiv) Date: 2005-01-24 15:02 Message: Logged In: YES user_id=50945 So it does. I suck. Thanks Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-24 14:21 Message: Logged In: YES user_id=31435 Look at the table of escapes again, especially the line with footnotes 3 and 5; that line documents the octal escapes, including all cases you've mentioned here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108060&group_id=5470 From noreply at sourceforge.net Mon Jan 24 08:15:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 08:15:24 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 10:04 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-01-24 02:15 Message: Logged In: YES user_id=593130 To me, the removal of whitespace at the ends (stripping) is consistent with the removal (or collapsing) of extra whitespace in between so that .split() does not return empty words anywhere. Consider: >>> ',1,,2,'.split(',') ['', '1', '', '2', ''] If ' 1 2 '.split() were to return null strings at the beginning and end of the list, then to be consistent, it should also put one in the middle. One can get this by being explicit (mixed WS can be handled by translation): >>> ' 1 2 '.split(' ') ['', '1', '', '2', ''] Having said this, I also agree that the extra words proposed by jj are helpful. BUG?? In 2.2, splitting an empty or whitespace only string produces an empty list [], not a list with a null word ['']. >>> ''.split() [] >>> ' '.split() [] which is what I see as consistent with the rest of the no-null- word behavior. Has this changed since? (Yes, must upgrade.) I could find no indication of such change in either the tracker or CVS. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 09:59 Message: Logged In: YES user_id=1008220 Brilliant, guys! Thanks again for a superb scripting language, and with documentation to match! Take care! /Joel Hedlund ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 09:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 05:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 11:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Mon Jan 24 12:43:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 12:43:50 2005 Subject: [ python-Bugs-968430 ] error flattening complex smime signed message Message-ID: Bugs item #968430, was opened at 2004-06-07 22:34 Message generated for change (Comment added) made by shevek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovico Magnocavallo (ludo) Assigned to: Nobody/Anonymous (nobody) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 12:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:34:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:34:52 2005 Subject: [ python-Bugs-1106694 ] split() takes no keyword arguments Message-ID: Bugs item #1106694, was opened at 2005-01-21 14:30 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Vinz (boukthor) Assigned to: Nobody/Anonymous (nobody) Summary: split() takes no keyword arguments Initial Comment: I'm running python 2.4 on a Linux box (Mandrake cooker 10.2). Since the string functions have been implemented as method of string instances, there's little use for the string module (except for constants). However, the behaviour of the 'split' method is slightly different from the one in the string module : it does not accept keyword arguments. This is annoying because the default separator argument ('any whitespace') cannot be provided manually (at least I couldn't find a way to do it) and that means that you can not use the default separator while specifying a maxsplit argument (if you specify maxsplit, you need to give a separator manually because it comes first in the arg list), unless you use "string.split" (and "import string") syntax. Examples : >>> "foo bar\tbaz\nqux".split() ['foo', 'bar', 'baz', 'qux'] >>> string.split("foo bar\tbaz\nqux") ['foo', 'bar', 'baz', 'qux'] >>> "foo bar\tbaz\nqux".split(" \t\n") # this is ok, just illustrating that you cannot emulate the default behaviour if you provide a separator manually ['foo bar\tbaz\nqux'] >>> string.split("foo bar\tbaz\nqux", maxsplit=2) # what I want to do ['foo', 'bar', 'baz\nqux'] >>> "foo bar\tbaz\nqux".split(maxsplit=2) # what I get Traceback (most recent call last): File "", line 1, in ? TypeError: split() takes no keyword arguments >>> "foo bar\tbaz\nqux".split(2) # cannot skip the sep arg Traceback (most recent call last): File "", line 1, in ? TypeError: expected a character buffer object ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:34 Message: Logged In: YES user_id=9205 Specifying None as separator gives you (as documented) the split-on-mulitple-whitespace behaviour. This applies to both string.split() and the split() string method. So skipping the separator arg is not needed. However, I agree to your wish that the string method split() should accept the "maxsplit" as a keyword argument. It is more backward compatible to the old string.split() function that way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:48:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:48:08 2005 Subject: [ python-Bugs-1106572 ] os.makedirs() ignores mode parameter Message-ID: Bugs item #1106572, was opened at 2005-01-21 10:42 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() ignores mode parameter Initial Comment: os.makedirs('foo/x', 0777) does not create the directories with permissions g+rwx,u+rwx,o+rwx but instead: >>> import os >>> os.makedirs('foo/xx', 0777) >>> [2]+ Stopped python2.3 ajung@hrs2dev2:~/sandboxes/haufecms/instance/Products/HaufeCMS: ls -la foo insgesamt 12 drwxr-xr-x 3 ajung ajung 4096 2005-01-21 10:39 . drwxr-xr-x 19 ajung ajung 4096 2005-01-21 10:39 .. drwxr-xr-x 2 ajung ajung 4096 2005-01-21 10:39 xx This happens with Python 2.3.4 on Linux ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:48 Message: Logged In: YES user_id=9205 What is the current process umask? The resulting directory mode will always be (mode & ~umask & 0777). To be sure that os.makedirs() will use the given mode without modification, you have to execute os.umask(0) beforehand. So this bug is probably invalid if you forgot to set your umask accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 From noreply at sourceforge.net Mon Jan 24 13:51:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 13:51:25 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 16:04 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: YoHell (yohell) Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:51 Message: Logged In: YES user_id=9205 This should probably also be added to rsplit()? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-01-24 08:15 Message: Logged In: YES user_id=593130 To me, the removal of whitespace at the ends (stripping) is consistent with the removal (or collapsing) of extra whitespace in between so that .split() does not return empty words anywhere. Consider: >>> ',1,,2,'.split(',') ['', '1', '', '2', ''] If ' 1 2 '.split() were to return null strings at the beginning and end of the list, then to be consistent, it should also put one in the middle. One can get this by being explicit (mixed WS can be handled by translation): >>> ' 1 2 '.split(' ') ['', '1', '', '2', ''] Having said this, I also agree that the extra words proposed by jj are helpful. BUG?? In 2.2, splitting an empty or whitespace only string produces an empty list [], not a list with a null word ['']. >>> ''.split() [] >>> ' '.split() [] which is what I see as consistent with the rest of the no-null- word behavior. Has this changed since? (Yes, must upgrade.) I could find no indication of such change in either the tracker or CVS. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 15:59 Message: Logged In: YES user_id=1008220 Brilliant, guys! Thanks again for a superb scripting language, and with documentation to match! Take care! /Joel Hedlund ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 15:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 11:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 17:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Mon Jan 24 18:35:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 18:35:57 2005 Subject: [ python-Bugs-1108490 ] broken link in tkinter docs Message-ID: Bugs item #1108490, was opened at 2005-01-24 09:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: broken link in tkinter docs Initial Comment: "Compound" link on http://www.python.org/doc/current/lib/node721.html is broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 From noreply at sourceforge.net Mon Jan 24 20:47:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 24 20:47:31 2005 Subject: [ python-Bugs-904498 ] threading docs, start error should be specified Message-ID: Bugs item #904498, was opened at 2004-02-25 12:00 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: threading docs, start error should be specified Initial Comment: The docs say it is an error to start a threading thread more than once, but they do not specify exactly what exception will be raised. Apparently it is always AssertionError (though an expert should verify this). It would be very helpful to document the exception because there is no other documented way to tell if a threading thread has been started than to try to start it. I posted to the dev group on 2003-02-24 about this and Aahz asked me to file a doc bug. So here it is. I suggest the info go in the Thread object docs, in the documentation for "start". ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2005-01-24 11:47 Message: Logged In: YES user_id=431773 There is still the problem that the threading module presents no reasonable way to tell if a thread is safe to start (i.e. whether or not it has already been started). A standard documented exception is one way to handle this (AssertionError is clearly not the best choice). A method or attribute would be even better, but would require a change in interface. Right now one has to keep a separate state flag, which is risky. ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-22 02:30 Message: Logged In: YES user_id=1174944 The actual wording in the documentation is: "This must be called at most once per thread object." To me this implies that the effect of calling start() twice is not defined. There is an assert statement in the implementation of Thread.start(), but - like all assert statements - its behaviour is dependent upon the value of the builtin __debug__ variable. Looking through the rest of the threading module, the documentation could be tightened up, particularly with respect to which behaviours are and aren't defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470 From noreply at sourceforge.net Tue Jan 25 00:48:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 00:49:01 2005 Subject: [ python-Bugs-968430 ] error flattening complex smime signed message Message-ID: Bugs item #968430, was opened at 2004-06-07 16:34 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovico Magnocavallo (ludo) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 06:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 From noreply at sourceforge.net Tue Jan 25 10:04:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 10:04:07 2005 Subject: [ python-Bugs-1108948 ] Cookie.py produces invalid code Message-ID: Bugs item #1108948, was opened at 2005-01-25 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=1108948&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie.py produces invalid code Initial Comment: The code in js_output in the Morsel class in Cookie.py produces invalid code, the scripting language should be specified by mimetype and not by language as per http://www.w3.org/TR/html401/interact/scripts.html also, the javascript line is missing an ending semi-colon attached a "patch" (new version of the function in question) present at least in 2.3 but still broken in current cvs A related matter: the existing documentation is poor, only after a substantial amount of code reading and googling I found out how to set attributes such as expires and path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108948&group_id=5470 From noreply at sourceforge.net Tue Jan 25 10:37:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 10:37:49 2005 Subject: [ python-Bugs-968430 ] error flattening complex smime signed message Message-ID: Bugs item #968430, was opened at 2004-06-07 22:34 Message generated for change (Comment added) made by shevek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovico Magnocavallo (ludo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="----381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-25 10:37 Message: Logged In: YES user_id=42389 In case it is any help, I tried to find the problem in the source. I don't speak python, so I can't fix anything, but I do speak C, so it's quite readable. :-) It seems to me that the problem is in Lib/email/Message.py, in particular in _parseparam and _get_params_preserve. Both these functions call strip() on the object several times (which seems a bit overdone anyway ;-) ), which I presume removes all whitespace around them. I think the whitespace should somehow be saved (not stripping will probably break many programs, so that's not a good idea), so it can be used again when the header is written. set_param should of course also fill this value, so new params get a defined separation (although the empty string is quite acceptable). How this should be implemented I gladly leave to someone who actually speaks Python. :-) ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 12:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 From noreply at sourceforge.net Tue Jan 25 11:33:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 11:33:56 2005 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 10:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: YoHell (yohell) Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:51 Message: Logged In: YES user_id=9205 This should probably also be added to rsplit()? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-01-24 02:15 Message: Logged In: YES user_id=593130 To me, the removal of whitespace at the ends (stripping) is consistent with the removal (or collapsing) of extra whitespace in between so that .split() does not return empty words anywhere. Consider: >>> ',1,,2,'.split(',') ['', '1', '', '2', ''] If ' 1 2 '.split() were to return null strings at the beginning and end of the list, then to be consistent, it should also put one in the middle. One can get this by being explicit (mixed WS can be handled by translation): >>> ' 1 2 '.split(' ') ['', '1', '', '2', ''] Having said this, I also agree that the extra words proposed by jj are helpful. BUG?? In 2.2, splitting an empty or whitespace only string produces an empty list [], not a list with a null word ['']. >>> ''.split() [] >>> ' '.split() [] which is what I see as consistent with the rest of the no-null- word behavior. Has this changed since? (Yes, must upgrade.) I could find no indication of such change in either the tracker or CVS. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 09:59 Message: Logged In: YES user_id=1008220 Brilliant, guys! Thanks again for a superb scripting language, and with documentation to match! Take care! /Joel Hedlund ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 09:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 09:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 05:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 11:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Tue Jan 25 11:42:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 11:42:14 2005 Subject: [ python-Bugs-1106694 ] split() takes no keyword arguments Message-ID: Bugs item #1106694, was opened at 2005-01-21 08:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470 Category: Python Interpreter Core Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Vinz (boukthor) Assigned to: Nobody/Anonymous (nobody) Summary: split() takes no keyword arguments Initial Comment: I'm running python 2.4 on a Linux box (Mandrake cooker 10.2). Since the string functions have been implemented as method of string instances, there's little use for the string module (except for constants). However, the behaviour of the 'split' method is slightly different from the one in the string module : it does not accept keyword arguments. This is annoying because the default separator argument ('any whitespace') cannot be provided manually (at least I couldn't find a way to do it) and that means that you can not use the default separator while specifying a maxsplit argument (if you specify maxsplit, you need to give a separator manually because it comes first in the arg list), unless you use "string.split" (and "import string") syntax. Examples : >>> "foo bar\tbaz\nqux".split() ['foo', 'bar', 'baz', 'qux'] >>> string.split("foo bar\tbaz\nqux") ['foo', 'bar', 'baz', 'qux'] >>> "foo bar\tbaz\nqux".split(" \t\n") # this is ok, just illustrating that you cannot emulate the default behaviour if you provide a separator manually ['foo bar\tbaz\nqux'] >>> string.split("foo bar\tbaz\nqux", maxsplit=2) # what I want to do ['foo', 'bar', 'baz\nqux'] >>> "foo bar\tbaz\nqux".split(maxsplit=2) # what I get Traceback (most recent call last): File "", line 1, in ? TypeError: split() takes no keyword arguments >>> "foo bar\tbaz\nqux".split(2) # cannot skip the sep arg Traceback (most recent call last): File "", line 1, in ? TypeError: expected a character buffer object ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-25 05:42 Message: Logged In: YES user_id=80475 As Calvin points out, the docs for str.split are clear about being able to write None to get the default any whitespace option. As a for making maxsplit a keyword argument, that might have been considered many years ago when string methods were introduced. At this point, that is ancient history and not worth mucking-up the API by introducing yet another inter-version incompatability (works in Py2.5 but not in Py2.2, 2.3, or 2.4). ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:34 Message: Logged In: YES user_id=9205 Specifying None as separator gives you (as documented) the split-on-mulitple-whitespace behaviour. This applies to both string.split() and the split() string method. So skipping the separator arg is not needed. However, I agree to your wish that the string method split() should accept the "maxsplit" as a keyword argument. It is more backward compatible to the old string.split() function that way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470 From noreply at sourceforge.net Tue Jan 25 11:44:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 11:44:15 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 (Tracker Item Submitted) made by Item Submitter 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 From noreply at sourceforge.net Tue Jan 25 17:28:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 17:28:57 2005 Subject: [ python-Bugs-741806 ] test_long failure Message-ID: Bugs item #741806, was opened at 2003-05-22 15:32 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Neal Norwitz (nnorwitz) Summary: test_long failure Initial Comment: $ python Lib/test/test_long.pyc long / * % divmod Karatsuba long bit-operation identities long str/hex/oct/atol long miscellaneous operations auto-convert int->long on overflow long->float overflow Traceback (most recent call last): File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 442, in ? test_float_overflow() File "/mnt/Python-2.3b1/Lib/test/test_long.py", line 394, in test_float_overflow eval(test, namespace) File "<string>", line 0, in ? ValueError: invalid literal for float(): 12345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345123451234512345 $ This happens on Tru64Unix 5.1A, cc/cxx compiled binaries. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-01-25 16:28 Message: Logged In: YES user_id=987664 This is broken for gcc-3.4.3 on Tru64 5.1. Using the vendor cc works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-26 14:14 Message: Logged In: YES user_id=33168 Checked in as: * configure 1.402 * configure.in 1.413 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 16:44 Message: Logged In: YES user_id=33168 This problem has a tentative solution. Please test the patch in http://python.org/sf/719359 Scroll to the bottom and click Download on the osf-opts.patch line. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-24 11:40 Message: Logged In: YES user_id=21627 >From http://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=47386&aid=719359 ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-23 08:44 Message: Logged In: YES user_id=696559 Hmm, I see tthe patch in list of patches, but how to download it? :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:08 Message: Logged In: YES user_id=33168 Patch 719359 should fix this problem. Can you test this patch? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-05-22 15:54 Message: Logged In: YES user_id=696559 ${ac_dA}SIZEOF_LONG${ac_dB}SIZEOF_LONG${ac_dC}8${ac_dD} ${ac_dA}HAVE_LONG_LONG${ac_dB}HAVE_LONG_LONG${ac_dC}1${ac_dD} ${ac_dA}SIZEOF_LONG_LONG${ac_dB}SIZEOF_LONG_LONG${ac_dC}8${ac_dD} ${ac_uA}SIZEOF_LONG${ac_uB}SIZEOF_LONG${ac_uC}8${ac_uD} ${ac_uA}HAVE_LONG_LONG${ac_uB}HAVE_LONG_LONG${ac_uC}1${ac_uD} ${ac_uA}SIZEOF_LONG_LONG${ac_uB}SIZEOF_LONG_LONG${ac_uC}8${ac_uD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741806&group_id=5470 From noreply at sourceforge.net Tue Jan 25 17:29:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 17:29:59 2005 Subject: [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after test_openpty Message-ID: Bugs item #713169, was opened at 2003-04-01 07:35 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: test_pty fails on HP-UX and AIX when run after test_openpty Initial Comment: Here is the output from test_pty.py: capulet:dist/src > ./python Lib/test/test_pty.py Calling master_open() Got master_fd '3', slave_name '/dev/pts/0' Calling slave_open('/dev/pts/0') Got slave_fd '4' Traceback (most recent call last): File "Lib/test/test_pty.py", line 58, in ? test_basic_pty() File "Lib/test/test_pty.py", line 29, in test_basic_pty if not os.isatty(slave_fd): File "Lib/test/test_pty.py", line 50, in handle_sig raise TestFailed, "isatty hung" test.test_support.TestFailed: isatty hung This was running Python 2.3a2 (downloaded from CVS on Sunday 30th March) built on HP-UX11i. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-01-25 16:29 Message: Logged In: YES user_id=987664 This happens with Python 2.4 on Tru64Unix V5.1 when compiling using gcc-3.4.3, but not if you use the vendor cc. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-07-12 08:30 Message: Logged In: YES user_id=200117 This still happens with Python-2.4.0a1 on HP-UX11i ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-03-10 17:22 Message: Logged In: YES user_id=994239 I'm running into this problem under both AIX 4.3.3 and 5.1. Is this going to cause a problem if I put python into produciton, or is it "safe" to ignore it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-01 16:31 Message: Logged In: YES user_id=33168 Actually, there is a 'fix' which is really a work-around the problem. You can disable os.openpty() in pty.master_open. I added a raise OSError at line 50 (before os.openpty()). This allows the test to pass. I think Martin and I agreed that globally disabling wasn't the best solution. That would probably be in some patch. Also, just in case it isn't clear--if you run test_pty BEFORE test_openpty, both tests pass. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-01 16:02 Message: Logged In: YES user_id=33168 I fixed the test hanging, but not the actual bug. The bug appears when running test_pty after test_openpty. There's some interaction, but I don't know what it is. The problem happens on AIX also. I searched through some man pages, but nothing leapt out at me. I think I tried googling for the answer to no avail. Any insight or ideas would be helpful. This may have started when adding /dev/ptmx (ptc for AIX) support. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-01 10:26 Message: Logged In: YES user_id=6656 Neal? I thought you thought this was fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470 From noreply at sourceforge.net Tue Jan 25 22:31:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 22:31:46 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 (Comment added) made by mcherm 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: Nobody/Anonymous (nobody) 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 Wed Jan 26 02:20:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 02:20:30 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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 From noreply at sourceforge.net Wed Jan 26 05:28:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 05:28:24 2005 Subject: [ python-Bugs-1109602 ] Need some setup.py sanity Message-ID: Bugs item #1109602, was opened at 2005-01-25 22:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109602&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Need some setup.py sanity Initial Comment: Python's setup.py has grown way out of control. I'm trying to build and install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a non-standard place and I can't figure out the incantation to tell setup.py to look where they are installed. I have tried: * setting LDFLAGS and CPPFLAGS on the make and configure command lines * running "setup.py --help" and "setup.py build --help" * reading the setup.py source It's not at all obvious to me from any of this if there is any way to point setup.py at a non-standard place. Over time setup.py has grown into the Python equivalent of a configure script, but there's been precious little refactoring, so there is stuff all over the place to add this directory on that platform or try different ad hoc solutions for various external packages based upon common installation practices. I think it's time to rethink the function and organization of setup.py. This might be an excellent sprint topic for PyCon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109602&group_id=5470 From noreply at sourceforge.net Wed Jan 26 08:20:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 08:20:59 2005 Subject: [ python-Bugs-1109659 ] distutils argument parsing is bogus Message-ID: Bugs item #1109659, was opened at 2005-01-26 18: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=1109659&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: distutils argument parsing is bogus Initial Comment: setup.py --dry-run install does what you'd expect. setup.py install --dry-run silently ignores the dry-run flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109659&group_id=5470 From noreply at sourceforge.net Wed Jan 26 10:15:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 10:15: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-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 Jan 26 14:22:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 14:22:50 2005 Subject: [ python-Bugs-1106572 ] os.makedirs() ignores mode parameter Message-ID: Bugs item #1106572, was opened at 2005-01-21 04:42 Message generated for change (Comment added) made by ajung You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() ignores mode parameter Initial Comment: os.makedirs('foo/x', 0777) does not create the directories with permissions g+rwx,u+rwx,o+rwx but instead: >>> import os >>> os.makedirs('foo/xx', 0777) >>> [2]+ Stopped python2.3 ajung@hrs2dev2:~/sandboxes/haufecms/instance/Products/HaufeCMS: ls -la foo insgesamt 12 drwxr-xr-x 3 ajung ajung 4096 2005-01-21 10:39 . drwxr-xr-x 19 ajung ajung 4096 2005-01-21 10:39 .. drwxr-xr-x 2 ajung ajung 4096 2005-01-21 10:39 xx This happens with Python 2.3.4 on Linux ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2005-01-26 08:22 Message: Logged In: YES user_id=11084 umask(0) does the job. In this case the documentation is completely misleading. The API reads as the 'mode' parameter is *the* umask. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 07:48 Message: Logged In: YES user_id=9205 What is the current process umask? The resulting directory mode will always be (mode & ~umask & 0777). To be sure that os.makedirs() will use the given mode without modification, you have to execute os.umask(0) beforehand. So this bug is probably invalid if you forgot to set your umask accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470 From noreply at sourceforge.net Wed Jan 26 16:52:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 16:53:01 2005 Subject: [ python-Bugs-1109963 ] bdist_wininst ignores build_lib from build command Message-ID: Bugs item #1109963, was opened at 2005-01-26 08:52 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=1109963&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst ignores build_lib from build command Initial Comment: As of Python 2.4, some code got added to the bdist_wininst command to override the build_lib option on the build command. I had successfully been using the following command which now fails: D:\Python24\python.exe setup.py build --force --compiler=mingw32 --build-lib D:\Anthony\Build\Dev\cx_Oracle\HEAD\9i-py24\win32 --build-temp D:\Anthony\Build\Dev\cx_Oracle\HEAD\9i-py24\win32 bdist_wininst --bdist-dir D:\Anthony\Build\Dev\cx_Oracle\HEAD\9i-py24\win32\temp --dist-dir D:\Anthony\Build\Dev\cx_Oracle\HEAD\9i-py24\win32 Here is the offending code from the run() method of the bdist_wininst command: if self.distribution.has_ext_modules(): # If we are building an installer for a Python version other # than the one we are currently running, then we need to ensure # our build_lib reflects the other Python version rather than ours. # Note that for target_version!=sys.version, we must have skipped the # build step, so there is no issue with enforcing the build of this # version. target_version = self.target_version if not target_version: assert self.skip_build, "Should have already checked this" target_version = sys.version[0:3] plat_specifier = ".%s-%s" % (get_platform(), target_version) build = self.get_finalized_command('build') build.build_lib = os.path.join(build.build_base, 'lib' + plat_specifier) The last line is the problem here. If I comment it out, the problem goes away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109963&group_id=5470 From noreply at sourceforge.net Wed Jan 26 17:24:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 17:24:50 2005 Subject: [ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2 Message-ID: Bugs item #1110007, was opened at 2005-01-26 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=1110007&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 From noreply at sourceforge.net Wed Jan 26 17:28:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 17:28:43 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 11: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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 From noreply at sourceforge.net Wed Jan 26 18:18:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 18:18:12 2005 Subject: [ python-Bugs-1110055 ] recursion core dumps Message-ID: Bugs item #1110055, was opened at 2005-01-26 18: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=1110055&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 30000 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: jacob@pauling:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 30000'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 From noreply at sourceforge.net Wed Jan 26 22:21:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 22:21:25 2005 Subject: [ python-Bugs-1101667 ] popen3 on windows loses environment variables Message-ID: Bugs item #1101667, was opened at 2005-01-13 07:33 Message generated for change (Comment added) made by ompeag You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 on windows loses environment variables Initial Comment: see the following test code: #test_popen3_1.py import os FILENAME='c:\temp\test_popen3_2.py' os.environ['FOOBAR']='foobar' print os.environ['FOOBAR'] fs=os.popen3("c:\python24\python -u %s"% FILENAME,'b') print fs[1].read() #c:\temp\test_popen3_2.py print "from test_popen3_2.py" import os;print os.environ['FOOBAR'] Running test_popen3_1.py is expected to print out: foobar from test_popen3_2.py foobar But it doesn't print the last foobar. It correctly prints out when run on python 2.3. If the FILENAME is set to a relative path, as when you are in the c:\temp directory and the FILENAME is set to test_popen3_2.py, the code works correct. Tests run on windows XP, SP1. This bug is related to the cgi bug #1100235. ---------------------------------------------------------------------- Comment By: AGunn (ompeag) Date: 2005-01-26 14:21 Message: Logged In: YES user_id=1155133 I've tried recreating this problem and have had no luck. I've tried three versions of python: 2.3, 2.4, and the current build version (2.5 something?). I've also tried both absolute and relative paths. All tests print out the second 'foobar' just fine. I, too, am running XP, SP1. Any chance there's something special about how you are running the executables? Say from a cygwin environment or something? ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-13 07:36 Message: Logged In: YES user_id=116941 Sorry. I got confused. When FILENAME is absolute, popen3 loses the environment variables, whereas it is relative, popen3 works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 From noreply at sourceforge.net Wed Jan 26 22:42:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 22:42:09 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 13: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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110242&group_id=5470 From noreply at sourceforge.net Thu Jan 27 08:00:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 08:00:45 2005 Subject: [ python-Bugs-1101667 ] popen3 on windows loses environment variables Message-ID: Bugs item #1101667, was opened at 2005-01-13 23:33 Message generated for change (Comment added) made by juneaftn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 on windows loses environment variables Initial Comment: see the following test code: #test_popen3_1.py import os FILENAME='c:\temp\test_popen3_2.py' os.environ['FOOBAR']='foobar' print os.environ['FOOBAR'] fs=os.popen3("c:\python24\python -u %s"% FILENAME,'b') print fs[1].read() #c:\temp\test_popen3_2.py print "from test_popen3_2.py" import os;print os.environ['FOOBAR'] Running test_popen3_1.py is expected to print out: foobar from test_popen3_2.py foobar But it doesn't print the last foobar. It correctly prints out when run on python 2.3. If the FILENAME is set to a relative path, as when you are in the c:\temp directory and the FILENAME is set to test_popen3_2.py, the code works correct. Tests run on windows XP, SP1. This bug is related to the cgi bug #1100235. ---------------------------------------------------------------------- >Comment By: June Kim (juneaftn) Date: 2005-01-27 16:00 Message: Logged In: YES user_id=116941 Oh, stupid me. The full path filename included '\t'. It should've been escaped. Then the example code works with 2.3 and 2.4. The real problem seems to be with os.environ. I have reassured this problem exists on some XP SP1 boxes. The test code is... #test_popen3_1.py import os FILENAME='test_popen3_2.py' env={};env['ENVIRON_UPDATE']='123';os.environ.update(env) os.environ['ENVIRON_DIRECT_SETTING']='123' cmdline='c:\python24\python.exe -u %s'%FILENAME fs=os.popen3(cmdline,'b') print fs[1].read() #test_popen3_2.py import os if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update worked' else:print 'os.env.update failed' if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print 'os.env assignment worked' else:print 'os.env assignment failed' Put these two files in the same path and run test_popen3_1.py with python2.4 and python2.3. Following is the result I got: C:\test>\python23\python test_popen3_1.py os.env.update worked os.env assignment worked C:\test>\python24\python test_popen3_1.py os.env.update failed os.env assignment worked As you see the environment varaible that's updated with os.environ.update has failed to get passed to popen3ed process. This is the reason CGIHTTPServer.py fails to deliver QUERY_STRING and etc. -- they are updated with os.environ.update(env). ---------------------------------------------------------------------- Comment By: AGunn (ompeag) Date: 2005-01-27 06:21 Message: Logged In: YES user_id=1155133 I've tried recreating this problem and have had no luck. I've tried three versions of python: 2.3, 2.4, and the current build version (2.5 something?). I've also tried both absolute and relative paths. All tests print out the second 'foobar' just fine. I, too, am running XP, SP1. Any chance there's something special about how you are running the executables? Say from a cygwin environment or something? ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-13 23:36 Message: Logged In: YES user_id=116941 Sorry. I got confused. When FILENAME is absolute, popen3 loses the environment variables, whereas it is relative, popen3 works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 From noreply at sourceforge.net Thu Jan 27 08:16:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 08:16:27 2005 Subject: [ python-Bugs-1101667 ] popen3 on windows loses environment variables Message-ID: Bugs item #1101667, was opened at 2005-01-13 23:33 Message generated for change (Comment added) made by juneaftn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 on windows loses environment variables Initial Comment: see the following test code: #test_popen3_1.py import os FILENAME='c:\temp\test_popen3_2.py' os.environ['FOOBAR']='foobar' print os.environ['FOOBAR'] fs=os.popen3("c:\python24\python -u %s"% FILENAME,'b') print fs[1].read() #c:\temp\test_popen3_2.py print "from test_popen3_2.py" import os;print os.environ['FOOBAR'] Running test_popen3_1.py is expected to print out: foobar from test_popen3_2.py foobar But it doesn't print the last foobar. It correctly prints out when run on python 2.3. If the FILENAME is set to a relative path, as when you are in the c:\temp directory and the FILENAME is set to test_popen3_2.py, the code works correct. Tests run on windows XP, SP1. This bug is related to the cgi bug #1100235. ---------------------------------------------------------------------- >Comment By: June Kim (juneaftn) Date: 2005-01-27 16:16 Message: Logged In: YES user_id=116941 Now I got it. The reason is os.py in python2.4 has changed so that the _Environ(UserDict.IterableUserDict) has lost its update method -- there was on in python2.3. To rectify the problem you just copy and paste the update method from python2.3 os.py. --- os.py Thu Jan 27 07:09:38 2005 +++ os_new.py Thu Jan 27 07:10:44 2005 @@ -435,6 +435,9 @@ return key.upper() in self.data def get(self, key, failobj=None): return self.data.get(key.upper(), failobj) + def update(self, dict): + for k, v in dict.items(): + self[k] = v def copy(self): return dict(self) @@ -446,6 +449,9 @@ def __setitem__(self, key, item): putenv(key, item) self.data[key] = item + def update(self, dict): + for k, v in dict.items(): + self[k] = v try: unsetenv except NameError: ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-27 16:00 Message: Logged In: YES user_id=116941 Oh, stupid me. The full path filename included '\t'. It should've been escaped. Then the example code works with 2.3 and 2.4. The real problem seems to be with os.environ. I have reassured this problem exists on some XP SP1 boxes. The test code is... #test_popen3_1.py import os FILENAME='test_popen3_2.py' env={};env['ENVIRON_UPDATE']='123';os.environ.update(env) os.environ['ENVIRON_DIRECT_SETTING']='123' cmdline='c:\python24\python.exe -u %s'%FILENAME fs=os.popen3(cmdline,'b') print fs[1].read() #test_popen3_2.py import os if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update worked' else:print 'os.env.update failed' if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print 'os.env assignment worked' else:print 'os.env assignment failed' Put these two files in the same path and run test_popen3_1.py with python2.4 and python2.3. Following is the result I got: C:\test>\python23\python test_popen3_1.py os.env.update worked os.env assignment worked C:\test>\python24\python test_popen3_1.py os.env.update failed os.env assignment worked As you see the environment varaible that's updated with os.environ.update has failed to get passed to popen3ed process. This is the reason CGIHTTPServer.py fails to deliver QUERY_STRING and etc. -- they are updated with os.environ.update(env). ---------------------------------------------------------------------- Comment By: AGunn (ompeag) Date: 2005-01-27 06:21 Message: Logged In: YES user_id=1155133 I've tried recreating this problem and have had no luck. I've tried three versions of python: 2.3, 2.4, and the current build version (2.5 something?). I've also tried both absolute and relative paths. All tests print out the second 'foobar' just fine. I, too, am running XP, SP1. Any chance there's something special about how you are running the executables? Say from a cygwin environment or something? ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-13 23:36 Message: Logged In: YES user_id=116941 Sorry. I got confused. When FILENAME is absolute, popen3 loses the environment variables, whereas it is relative, popen3 works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101667&group_id=5470 From noreply at sourceforge.net Thu Jan 27 08:22:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 08:22:16 2005 Subject: [ python-Bugs-1110478 ] os.environ.update doesn't work Message-ID: Bugs item #1110478, was opened at 2005-01-27 16: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=1110478&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ.update doesn't work Initial Comment: os.environ.update doesn't really update os.environ -- it doesn't call putenv subsequently. This is the test code: #test1.py import os FILENAME='test2.py' env={};env['ENVIRON_UPDATE']='123';os.environ.update(env) os.environ['ENVIRON_DIRECT_SETTING']='123' cmdline='c:\python24\python.exe -u %s'%FILENAME fs=os.popen3(cmdline,'b') print fs[1].read() #test2.py import os if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update worked' else:print 'os.env.update failed' if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print 'os.env assignment worked' else:print 'os.env assignment failed' Run test1.py with python 2.4 on windows. The reason os.environ.update doesn't work is the update method is removed from 2.4. (It works with 2.3) Following is the patch: --- os.py Thu Jan 27 07:09:38 2005 +++ os_new.py Thu Jan 27 07:10:44 2005 @@ -435,6 +435,9 @@ return key.upper() in self.data def get(self, key, failobj=None): return self.data.get(key.upper(), failobj) + def update(self, dict): + for k, v in dict.items(): + self[k] = v def copy(self): return dict(self) @@ -446,6 +449,9 @@ def __setitem__(self, key, item): putenv(key, item) self.data[key] = item + def update(self, dict): + for k, v in dict.items(): + self[k] = v try: unsetenv except NameError: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 From noreply at sourceforge.net Thu Jan 27 08:22:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 08:23:00 2005 Subject: [ python-Bugs-1110478 ] os.environ.update doesn't work Message-ID: Bugs item #1110478, was opened at 2005-01-27 16:22 Message generated for change (Comment added) made by juneaftn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ.update doesn't work Initial Comment: os.environ.update doesn't really update os.environ -- it doesn't call putenv subsequently. This is the test code: #test1.py import os FILENAME='test2.py' env={};env['ENVIRON_UPDATE']='123';os.environ.update(env) os.environ['ENVIRON_DIRECT_SETTING']='123' cmdline='c:\python24\python.exe -u %s'%FILENAME fs=os.popen3(cmdline,'b') print fs[1].read() #test2.py import os if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update worked' else:print 'os.env.update failed' if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print 'os.env assignment worked' else:print 'os.env assignment failed' Run test1.py with python 2.4 on windows. The reason os.environ.update doesn't work is the update method is removed from 2.4. (It works with 2.3) Following is the patch: --- os.py Thu Jan 27 07:09:38 2005 +++ os_new.py Thu Jan 27 07:10:44 2005 @@ -435,6 +435,9 @@ return key.upper() in self.data def get(self, key, failobj=None): return self.data.get(key.upper(), failobj) + def update(self, dict): + for k, v in dict.items(): + self[k] = v def copy(self): return dict(self) @@ -446,6 +449,9 @@ def __setitem__(self, key, item): putenv(key, item) self.data[key] = item + def update(self, dict): + for k, v in dict.items(): + self[k] = v try: unsetenv except NameError: ---------------------------------------------------------------------- >Comment By: June Kim (juneaftn) Date: 2005-01-27 16:22 Message: Logged In: YES user_id=116941 This is the cause of the cgi bug #1100235. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 From noreply at sourceforge.net Thu Jan 27 08:24:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 08:24:40 2005 Subject: [ python-Bugs-1100235 ] Scripts started with CGIHTTPServer: missing cgi environment Message-ID: Bugs item #1100235, was opened at 2005-01-12 01:00 Message generated for change (Comment added) made by juneaftn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: pacote (pacote) Assigned to: Nobody/Anonymous (nobody) Summary: Scripts started with CGIHTTPServer: missing cgi environment Initial Comment: With Python 2.4 only (2.3 works fine). Tested on Windows 2000. In run_cgi, sys.environ is updated with cgi variables (QUERY_STRING, etc.) but it seems that this environment is not passed to the child process. On Windows os.popen3 is used but something must have changed in that function that is causing this regression. The attached patch fixes this using the subprocess module. It fixes also (I think) bug 1088039 ("directories/scripts with spaces in their name"). Supports too Python installed in a directory with a space (e.g. "Program Files"). Patch note: the subprocess test (have_subprocess) is kind of awkward: is there a better way to do this? Diff follows, complete script attached. ----- --- C:\apps\Python24\Lib\CGIHTTPServer-old.py Mon Aug 30 09:38:16 2004 +++ C:\apps\Python24\Lib\CGIHTTPServer.py Tue Jan 10 19:45:09 2005 @@ -234,18 +234,16 @@ elif self.have_popen2 or self.have_popen3: # Windows -- use popen2 or popen3 to create a subprocess + import subprocess import shutil - if self.have_popen3: - popenx = os.popen3 - else: - popenx = os.popen2 - cmdline = scriptfile + + cmdline = '"%s"' % scriptfile if self.is_python(scriptfile): interp = sys.executable if interp.lower().endswith("w.exe"): # On Windows, use python.exe, not pythonw.exe interp = interp[:-5] + interp[-4:] - cmdline = "%s -u %s" % (interp, cmdline) + cmdline = '"%s" -u %s' % (interp, cmdline) if '=' not in query and '"' not in query: cmdline = '%s "%s"' % (cmdline, query) self.log_message("command: %s", cmdline) @@ -253,11 +251,11 @@ nbytes = int(length) except (TypeError, ValueError): nbytes = 0 - files = popenx(cmdline, 'b') - fi = files[0] - fo = files[1] - if self.have_popen3: - fe = files[2] + + p = subprocess.Popen(cmdline, stdin=subprocess.PIPE, stdout=subprocess.PIPE, + stderr=subprocess.PIPE, env=os.environ) + (fi, fo, fe) = (p.stdin, p.stdout, p.stderr) + if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) @@ -267,16 +265,16 @@ break fi.close() shutil.copyfileobj(fo, self.wfile) - if self.have_popen3: - errors = fe.read() - fe.close() - if errors: - self.log_error('%s', errors) + errors = fe.read() + fe.close() + if errors: + self.log_error('%s', errors) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: self.log_message("CGI script exited OK") + del p else: # Other O.S. -- execute script in this process ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-27 16:24 Message: Logged In: YES user_id=116941 Please have a look at #1110478. The cause is in os.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470 From noreply at sourceforge.net Thu Jan 27 08:39:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 08:39:14 2005 Subject: [ python-Bugs-1110478 ] os.environ.update doesn't work Message-ID: Bugs item #1110478, was opened at 2005-01-27 16:22 Message generated for change (Comment added) made by juneaftn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ.update doesn't work Initial Comment: os.environ.update doesn't really update os.environ -- it doesn't call putenv subsequently. This is the test code: #test1.py import os FILENAME='test2.py' env={};env['ENVIRON_UPDATE']='123';os.environ.update(env) os.environ['ENVIRON_DIRECT_SETTING']='123' cmdline='c:\python24\python.exe -u %s'%FILENAME fs=os.popen3(cmdline,'b') print fs[1].read() #test2.py import os if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update worked' else:print 'os.env.update failed' if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print 'os.env assignment worked' else:print 'os.env assignment failed' Run test1.py with python 2.4 on windows. The reason os.environ.update doesn't work is the update method is removed from 2.4. (It works with 2.3) Following is the patch: --- os.py Thu Jan 27 07:09:38 2005 +++ os_new.py Thu Jan 27 07:10:44 2005 @@ -435,6 +435,9 @@ return key.upper() in self.data def get(self, key, failobj=None): return self.data.get(key.upper(), failobj) + def update(self, dict): + for k, v in dict.items(): + self[k] = v def copy(self): return dict(self) @@ -446,6 +449,9 @@ def __setitem__(self, key, item): putenv(key, item) self.data[key] = item + def update(self, dict): + for k, v in dict.items(): + self[k] = v try: unsetenv except NameError: ---------------------------------------------------------------------- >Comment By: June Kim (juneaftn) Date: 2005-01-27 16:39 Message: Logged In: YES user_id=116941 The update methods in os.py were removed in the Revision 1.75. Thu Mar 4 08:25:44 2004 UTC according to the cvs. ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-27 16:22 Message: Logged In: YES user_id=116941 This is the cause of the cgi bug #1100235. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 From noreply at sourceforge.net Thu Jan 27 14:27:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 14:27:25 2005 Subject: [ python-Bugs-1110705 ] list comprehension scope Message-ID: Bugs item #1110705, was opened at 2005-01-27 15: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=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 From noreply at sourceforge.net Thu Jan 27 14:48:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 14:48:22 2005 Subject: [ python-Bugs-1110705 ] list comprehension scope Message-ID: Bugs item #1110705, was opened at 2005-01-27 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=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 08:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 From noreply at sourceforge.net Thu Jan 27 15:11:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 15:11:13 2005 Subject: [ python-Bugs-1110705 ] list comprehension scope Message-ID: Bugs item #1110705, was opened at 2005-01-27 15:27 Message generated for change (Comment added) made by sdahlbac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined ---------------------------------------------------------------------- >Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-01-27 16:11 Message: Logged In: YES user_id=750513 Seemingly (according to: http://docs.python.org/ref/lists.html) this is indeed a bug that should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 15:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 From noreply at sourceforge.net Thu Jan 27 19:59:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 19:59:09 2005 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-27 00:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-27 19:59 Message: Logged In: YES user_id=21627 The patch turns out to be incorrect: fflushing(stdin) causes undefined behaviour, and indeed does cause problems on OS X (fflush fails, and python returns with a non-zero exit status). Reverting the close function for stdin: NEWS 1.831.4.166 sysmodule.c 2.120.6.3 NEWS 1.1193.2.16 sysmodule.c 2.126.2.2 NEWS 1.1234 sysmodule.c 2.128 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-23 10:51 Message: Logged In: YES user_id=21627 Thanks for the report and the patch. Committed as NEWS 1.1232 sysmodule.c 2.127 NEWS 1.1193.2.15 sysmodule.c 2.126.2.1 NEWS 1.831.4.164 sysmodule.c 2.120.6.2 ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2005-01-20 10:24 Message: Logged In: YES user_id=41497 Hi Martin, I would have done that, but sys.stdout.close is already defined *not* to close stdout. Here's the relevant FAQ: 1.4.7 Why doesn't closing sys.stdout (stdin, stderr) really close it? http://www.python.org/doc/faq/library.html#id28 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-19 23:28 Message: Logged In: YES user_id=21627 I don't think the patch is right. If somebody explicitly invokes sys.stdout.close(), this should have the same effect as invoking fclose(stdout) in C. It currently doesn't, but with meyering's patch from 2004-12-02 10:20, it still doesn't, so the patch is incorrect. It might be better to explicitly invoke fclose() if the file object has no associated f_close function. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-20 00:38 Message: Logged In: YES user_id=203860 Tim, these bugs are quite difficult to trigger, but they can hide any kind of file error and lose arbitrarily large amounts of data. Here, the following program will run indefinitely: full = open('/dev/full', 'w') while 1: print >>full, 'x' * 1023 print >>full It seems to be essential that both the character that fills the file buffer (here it is 1024 bytes long) and the next are generated implicitly by print - otherwise the write error will be detected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-19 23:24 Message: Logged In: YES user_id=31435 Sorry, don't care enough to spend time on it (not a bug I've had, not one I expect to have, don't care if it never changes). Suggest not using /dev/full as an output device . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 01:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-07 00:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 00:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 10:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 11:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 11:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Thu Jan 27 21:05:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 21:05:36 2005 Subject: [ python-Bugs-1110998 ] RLock logging mispells "success" Message-ID: Bugs item #1110998, was opened at 2005-01-27 12: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=1110998&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Bogosian (mbogosian) Assigned to: Nobody/Anonymous (nobody) Summary: RLock logging mispells "success" Initial Comment: When verbose logging is turned on for RLock objects (via the constructor), attempts to acquire the lock are logged, but spelling didn't seem to be a priority ;-) : Thread-2: <_RLock(Thread-2, 1)>.acquire(1): initial succes "succes" should be "success" This was present in my tests of 2.3 and 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110998&group_id=5470 From noreply at sourceforge.net Thu Jan 27 21:58:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 21:58:09 2005 Subject: [ python-Bugs-1029561 ] test_pep277 fails Message-ID: Bugs item #1029561, was opened at 2004-09-17 08:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marek Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: test_pep277 fails Initial Comment: Running regrtest.py: test_pep277 test test_pep277 produced unexpected output: ********************************************************************** *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ^ ------------ + ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ++++++++++++ ^ ********************************************************************** But when running just test_pep277.py: test_directory (__main__.UnicodeFileTests) ... u'\xdf-\u66e8\u66e9\u66eb' ok test_failures (__main__.UnicodeFileTests) ... ok test_listdir (__main__.UnicodeFileTests) ... ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] [u'Gr\xfc\xdf-Gott', u'abc', u'ascii', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] ok test_open (__main__.UnicodeFileTests) ... ok test_rename (__main__.UnicodeFileTests) ... ok ---------------------------------------------------------------------- Ran 5 tests in 0.109s OK ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-28 05:58 Message: Logged In: YES user_id=671362 Changes against Lib/test/test_pep277.py(Revision 1.9) and Lib/test/output/test_pep277(Revision 1.3) ironed out the problem with Python 2.4, but the same error can be seen with Python 2.3.5 RC1. Is there any chance that they're backported to 2.3 branch before 2.3.5 final gets released? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-21 12:15 Message: Logged In: YES user_id=752496 The tests (through regrtest.py and alone) pass OK to me. Using (Win2k SP4), Python 2.4b1 (#57, Oct 15 2004, 15:23:38) [MSC v.1310 32 bit (Intel)] on win32, and: >>> import locale >>> locale.getlocale() ['Spanish_Argentina', '1252'] . Facundo ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-10-18 01:06 Message: Logged In: YES user_id=358087 Fails for me on 2.4b1 on winXP ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-17 18:55 Message: Logged In: YES user_id=671362 Same for me. Fail for regrtest.py, but OK for test_277.py in isolation. (Python 2.4a3, Windows 2K SP4, locale:Japan) But my output is a bit different from yours. test test_pep277 produced unexpected output: ********************************************** ************************ *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??- sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] + ['??????', '??\x82\xf1\x84t\x83\xa1s', '?\x9eG?', 'Grus- Gott', 'abc', 'ascii', '\x82\xc9\x82\xdb\x82\xf1', '\x83\xa1\x83 \xc3\x83\xc7?-\x83\xd0\x83\xbf?', '\x84H\x84t\x84\x82 \x84p\x84r\x84\x83\x84\x84\x84r\x84\x85\x84z\x84\x84\x84u'] ********************************************** ************************ This reminds me of the next thread: * More joy with test_strptime http://mail.python.org/pipermail/python-dev/2004- July/046046.html ---------------------------------------------------------------------- Comment By: Marek Baczynski (imbaczek) Date: 2004-09-17 08:25 Message: Logged In: YES user_id=838849 Forgot: Windows XP SP1, Python 2.4a3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 From noreply at sourceforge.net Thu Jan 27 22:16:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 22:17:05 2005 Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k Message-ID: Bugs item #989338, was opened at 2004-07-12 20:11 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' ====================================================================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' ====================================================================== ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-28 06:16 Message: Logged In: YES user_id=671362 Can anyone merge this(test_unicode_file.py rev 1.16) to release23-maint branch? This is not specific to Python 2.4. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-08 04:58 Message: Logged In: YES user_id=21627 This is now fixed in test_unicode_file.py 1.16. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-07 19:12 Message: Logged In: YES user_id=21627 I'm talking about the third tab on XP regional settings; I don't know how the user interface looks in W2k. This tab says something like "language for programs which don't support Unicode". It might be that this setting is simply not available on W2k. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-03 17:23 Message: Logged In: YES user_id=115179 Martin, on other w2k pro (english) sp4 with POLISH locale set this test works as expected - "All the Unicode tests appeared to work". Both versions have the same settings for regional options - polish: On first tab (general) I have Polish location and other languages on the same tab selected: western europe and US, central europe. On last tab (6 = input locales) I have polish programmers and endglish (US). Third tab - currency ? Or this test fails on non english versions of W2K ? German ? Hungarian ? ... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-03 02:28 Message: Logged In: YES user_id=115179 same effect on non french w2k (polish locale), this persists on any python 2.x version and is rather independent from windows version - in my case it is w2k pro sp4. file created with this encoding works fine with windows commander - if that matters ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-10-15 15:14 Message: Logged In: YES user_id=21627 In control panel/regional settings, change the first *and* the third tab to English. This requires a reboot. The failure itself is harmless. test_support assumes that TESTFN_UNICODE = unicode("@test-\xe0\xf2", "latin-1") is a filename that can be represented in the default file encoding. On Windows, if the default file encoding is not CP-1252 (as it is in the Western European installations), this file name cannot be represented correctly in "mbcs". To fix this, we would need to come up with procedure to generate a file name depending on the locale. Unfortunately, such a procedure is very difficult to implement. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-10-14 17:59 Message: Logged In: YES user_id=358087 How do I switch my locale to English on winXP pro? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-14 00:31 Message: Logged In: YES user_id=29957 Sounds like a locale thing - do the people seeing the bug have the problem if they switch their locale to english? ---------------------------------------------------------------------- Comment By: Marek Baczynski (imbaczek) Date: 2004-09-17 08:30 Message: Logged In: YES user_id=838849 I have the very same errors as quiver on WinXP SP1, Python 2.4a3, NTFS, locale Polish. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-07 23:37 Message: Logged In: YES user_id=671362 I can reproduce this in Python 2.4a3 on Win 2K SP4(locale is set to Japanese). File system is NTFS. But on my box, test_single_files passes OK. Only test_equivalent_files and test_directories raise ERROR. Here is the result. test_unicode_file test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ok ============================================== ======================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 185, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_UNICODE+ext, True) File "C:\Python24\lib\test\test_unicode_file.py", line 114, in _do_directory os.chdir(chdir_name) OSError: [Errno 2] No such file or directory: u'@test-\xe0 \xf2.dir' ============================================== ======================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 176, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\Python24\lib\test\test_unicode_file.py", line 157, in _test_equivalent self._do_equivilent(filename1, filename2) File "C:\Python24\lib\test\test_unicode_file.py", line 67, in _do_equivilent os.stat(filename2)) OSError: [Errno 2] No such file or directory: u'@test-\xe0\xf2' ------------------------------------------------------------ ---------- Ran 3 tests in 0.070s FAILED (errors=2) test test_unicode_file failed -- errors occurred; run in verbose mode for details 1 test failed: test_unicode_file ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-09-07 15:56 Message: Logged In: YES user_id=358087 Yes it does :-( I have a winXP on IBM T-40. The other language that is installed is Hebrew. The problem that when encoding TESTFN_UNICODE with the file system ecoding (mbcs) the resulted string is "@test-??" which is not a legal file name on windows ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 15:31 Message: Logged In: YES user_id=80475 Does this still fail for you in Py2.4a3 ? If not, please note the result and close the bug. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-18 15:44 Message: Logged In: YES user_id=358087 File system is NTFS. winver gives: Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-16 01:55 Message: Logged In: YES user_id=21627 Are you using a FAT partition? What precise version string do you get in winver.exe? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-13 15:10 Message: Logged In: YES user_id=358087 Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro. Any other data I can send? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-13 01:35 Message: Logged In: YES user_id=31435 Peculiar -- it works fine on WinXP Pro, which ought to work the same as Win2K here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 From noreply at sourceforge.net Thu Jan 27 23:52:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 23:52:51 2005 Subject: [ python-Bugs-1110998 ] RLock logging mispells "success" Message-ID: Bugs item #1110998, was opened at 2005-01-27 12:05 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110998&group_id=5470 Category: Threads Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Bogosian (mbogosian) >Assigned to: Brett Cannon (bcannon) Summary: RLock logging mispells "success" Initial Comment: When verbose logging is turned on for RLock objects (via the constructor), attempts to acquire the lock are logged, but spelling didn't seem to be a priority ;-) : Thread-2: <_RLock(Thread-2, 1)>.acquire(1): initial succes "succes" should be "success" This was present in my tests of 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-01-27 14:52 Message: Logged In: YES user_id=357491 Fixed in rev. 1.48 for 2.5 and rev. 1.45.4.1 for 2.4 and rev. 1.38.6.5 for 2.3. Thanks, Matthew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110998&group_id=5470 From noreply at sourceforge.net Thu Jan 27 23:56:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 23:56:42 2005 Subject: [ python-Bugs-1111100 ] csv reader barfs encountering quote when quote_none is set Message-ID: Bugs item #1111100, was opened at 2005-01-27 22: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=1111100&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: washington irving (washirv) Assigned to: Nobody/Anonymous (nobody) Summary: csv reader barfs encountering quote when quote_none is set Initial Comment: I'm including a python session that I cut paste from my xterm. Essentially the problem boils down to when QUOTE_NONE is set for the csv reader, and it encounters a quote immediately after a separator, it assumes that it is in a quoted field, and keeps going till it finds the matching end quote. Either this is a bug, or the meaning of QUOTE_NONE is not clear. My patch for it is to check for QUOTE_NONE immediately after the delimiter, and if so the state machine skips to IN_FIELD state. The patch is against 2.3.3 134 wooster:~> python Python 2.3.3 (#1, Dec 30 2004, 14:12:38) [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> >>> class plain_dialect(csv.Dialect): ... delimiter="\t" ... escapechar="\" ... doublequote=False ... skipinitialspace=True ... lineterminator="\n" ... quoting=csv.QUOTE_NONE ... quotechar="'" ... >>> csv.register_dialect("plain", plain_dialect) >>> import StringIO >>> s = StringIO.StringIO() >>> w = csv.writer(s, dialect="plain") >>> w.writerow(["foo", "'bar"]) >>> s.seek(0) >>> s.read() "foo\t'bar\n" >>> s.seek(0) >>> r = csv.reader(s, dialect="plain") >>> r.next() Traceback (most recent call last): File "", line 1, in ? _csv.Error: newline inside string >>> After patching: 135 wooster:~> python Python 2.3.3 (#1, Dec 30 2004, 14:12:38) [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> class plain_dialect(csv.Dialect): ... delimiter="\t" ... escapechar="\" ... doublequote=False ... skipinitialspace=True ... lineterminator="\n" ... quoting=csv.QUOTE_NONE ... quotechar="'" ... >>> csv.register_dialect("plain", plain_dialect) >>> import StringIO >>> s = StringIO.StringIO() >>> w = csv.writer(s, dialect="plain") >>> w.writerow(["foo", "'bar"]) >>> s.seek(0) >>> s.read() "foo\t'bar\n" >>> s.seek(0) >>> r = csv.reader(s, dialect="plain") >>> r.next() ['foo', "'bar"] >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1111100&group_id=5470 From noreply at sourceforge.net Fri Jan 28 00:52:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 00:52:09 2005 Subject: [ python-Bugs-1111130 ] tkSimpleDialog broken on MacOS X (Aqua Tk) Message-ID: Bugs item #1111130, was opened at 2005-01-27 15:52 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=1111130&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkSimpleDialog broken on MacOS X (Aqua Tk) Initial Comment: On MacOS X 10.3.7 using the built-in python 2.3 and Aqua Tk 8.4.9, tkSimpleDialog.askfloat() with initialvalue specified misbehaves: - The entry box is displayed over the prompt. - Clicking on the entry box has no effect. - Clicking below the entry box (i.e. where it OUGHT to be displayed) acts as though you clicked in the entry box. If you omit the initial value then the bug does not appear. Also: on one particular unix system, similar code caused the entire Tkinter application to become unresponsive once the dialog box was dismissed. However, the parent window for that dialog was not root and I did not specify the parent argument to askfloat, so that may explain the hang. See the attached sample code for details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1111130&group_id=5470 From noreply at sourceforge.net Fri Jan 28 04:01:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 04:01:20 2005 Subject: [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 Message generated for change (Comment added) made by lpd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2005-01-27 19:01 Message: Logged In: YES user_id=8861 SourceForge apparently failed to e-mail me a notification of your follow-up, so I didn't find out about it until today (exactly 1 month from your original posting), by accident. The problem is definitely still there in 2.3.3, which is what I currently have installed. I'll download and test 2.3.4 and 2.4 tomorrow. (I hope you'll give me an extra day!) lpd ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 18:02 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-11 03:59 Message: Logged In: YES user_id=21627 It's inconsistent with the rest of Tkinter. Everything in Tkinter is an object, and so are images. If you want strings, use plain _tkinter. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-11 01:33 Message: Logged In: YES user_id=38376 "..consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life." ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 01:01 Message: Logged In: YES user_id=33229 What's wrong with simply wrapping what Tk does with an image_create method that returns a string and an image_delete method that accepts a string? It's consistent with Tk usage. You can document the proper usage of image_delete and leave the Image class for backwards compatability. Something like: def image_create(self, imgtype, cnf={}, master=None, **kw): if not master: master = Tkinter._default_root if not master: raise RuntimeError, 'Too early to create image' if kw and cnf: cnf = _cnfmerge((cnf, kw)) elif kw: cnf = kw options = () for k, v in cnf.items(): if callable(v): v = self._register(v) options = options + ('-'+k, v) return master.tk.call(('image', 'create', imgtype,) + options) def image_delete(self, imgname): try: self.tk.call('image', 'delete', imgname) except TclError: # May happen if the root was destroyed pass ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 05:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. </F> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-08 04:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 11:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-07 11:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 10:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-13 04:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 13:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-07 02:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 01:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-05 14:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 13:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-03 23:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 11:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 21:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply at sourceforge.net Fri Jan 28 17:44:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 17:44:25 2005 Subject: [ python-Bugs-718532 ] inspect, class instances and __getattr__ Message-ID: Bugs item #718532, was opened at 2003-04-09 22:01 Message generated for change (Comment added) made by sschwarzer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Raymond Hettinger (rhettinger) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. ---------------------------------------------------------------------- >Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 17:44 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 18:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 12:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-04-15 12:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 10:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 02:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 From noreply at sourceforge.net Sat Jan 29 14:34:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 14:34:29 2005 Subject: [ python-Bugs-1110478 ] os.environ.update doesn't work Message-ID: Bugs item #1110478, was opened at 2005-01-27 08:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ.update doesn't work Initial Comment: os.environ.update doesn't really update os.environ -- it doesn't call putenv subsequently. This is the test code: #test1.py import os FILENAME='test2.py' env={};env['ENVIRON_UPDATE']='123';os.environ.update(env) os.environ['ENVIRON_DIRECT_SETTING']='123' cmdline='c:\python24\python.exe -u %s'%FILENAME fs=os.popen3(cmdline,'b') print fs[1].read() #test2.py import os if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update worked' else:print 'os.env.update failed' if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print 'os.env assignment worked' else:print 'os.env assignment failed' Run test1.py with python 2.4 on windows. The reason os.environ.update doesn't work is the update method is removed from 2.4. (It works with 2.3) Following is the patch: --- os.py Thu Jan 27 07:09:38 2005 +++ os_new.py Thu Jan 27 07:10:44 2005 @@ -435,6 +435,9 @@ return key.upper() in self.data def get(self, key, failobj=None): return self.data.get(key.upper(), failobj) + def update(self, dict): + for k, v in dict.items(): + self[k] = v def copy(self): return dict(self) @@ -446,6 +449,9 @@ def __setitem__(self, key, item): putenv(key, item) self.data[key] = item + def update(self, dict): + for k, v in dict.items(): + self[k] = v try: unsetenv except NameError: ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 14:34 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in os.py 1.85 test_os.py 1.29 NEWS 1.1235 os.py 1.83.2.1 NEWS 1.1193.2.17 ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-27 08:39 Message: Logged In: YES user_id=116941 The update methods in os.py were removed in the Revision 1.75. Thu Mar 4 08:25:44 2004 UTC according to the cvs. ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-27 08:22 Message: Logged In: YES user_id=116941 This is the cause of the cgi bug #1100235. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470 From noreply at sourceforge.net Sat Jan 29 14:34:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 14:34:42 2005 Subject: [ python-Bugs-1100235 ] Scripts started with CGIHTTPServer: missing cgi environment Message-ID: Bugs item #1100235, was opened at 2005-01-11 17:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: pacote (pacote) Assigned to: Nobody/Anonymous (nobody) Summary: Scripts started with CGIHTTPServer: missing cgi environment Initial Comment: With Python 2.4 only (2.3 works fine). Tested on Windows 2000. In run_cgi, sys.environ is updated with cgi variables (QUERY_STRING, etc.) but it seems that this environment is not passed to the child process. On Windows os.popen3 is used but something must have changed in that function that is causing this regression. The attached patch fixes this using the subprocess module. It fixes also (I think) bug 1088039 ("directories/scripts with spaces in their name"). Supports too Python installed in a directory with a space (e.g. "Program Files"). Patch note: the subprocess test (have_subprocess) is kind of awkward: is there a better way to do this? Diff follows, complete script attached. ----- --- C:\apps\Python24\Lib\CGIHTTPServer-old.py Mon Aug 30 09:38:16 2004 +++ C:\apps\Python24\Lib\CGIHTTPServer.py Tue Jan 10 19:45:09 2005 @@ -234,18 +234,16 @@ elif self.have_popen2 or self.have_popen3: # Windows -- use popen2 or popen3 to create a subprocess + import subprocess import shutil - if self.have_popen3: - popenx = os.popen3 - else: - popenx = os.popen2 - cmdline = scriptfile + + cmdline = '"%s"' % scriptfile if self.is_python(scriptfile): interp = sys.executable if interp.lower().endswith("w.exe"): # On Windows, use python.exe, not pythonw.exe interp = interp[:-5] + interp[-4:] - cmdline = "%s -u %s" % (interp, cmdline) + cmdline = '"%s" -u %s' % (interp, cmdline) if '=' not in query and '"' not in query: cmdline = '%s "%s"' % (cmdline, query) self.log_message("command: %s", cmdline) @@ -253,11 +251,11 @@ nbytes = int(length) except (TypeError, ValueError): nbytes = 0 - files = popenx(cmdline, 'b') - fi = files[0] - fo = files[1] - if self.have_popen3: - fe = files[2] + + p = subprocess.Popen(cmdline, stdin=subprocess.PIPE, stdout=subprocess.PIPE, + stderr=subprocess.PIPE, env=os.environ) + (fi, fo, fe) = (p.stdin, p.stdout, p.stderr) + if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) @@ -267,16 +265,16 @@ break fi.close() shutil.copyfileobj(fo, self.wfile) - if self.have_popen3: - errors = fe.read() - fe.close() - if errors: - self.log_error('%s', errors) + errors = fe.read() + fe.close() + if errors: + self.log_error('%s', errors) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: self.log_message("CGI script exited OK") + del p else: # Other O.S. -- execute script in this process ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 14:34 Message: Logged In: YES user_id=21627 As juneaftn says, this was caused by #1110478, and is fixed in os.py 1.85 test_os.py 1.29 NEWS 1.1235 os.py 1.83.2.1 NEWS 1.1193.2.17 ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2005-01-27 08:24 Message: Logged In: YES user_id=116941 Please have a look at #1110478. The cause is in os.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470 From noreply at sourceforge.net Sat Jan 29 15:08:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 15:08:29 2005 Subject: [ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2 Message-ID: Bugs item #1110007, was opened at 2005-01-26 17:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 Category: Build >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 15:08 Message: Logged In: YES user_id=21627 This is clearly a bug in your gcc installation - perhaps some library is not up-to-date, or libstdc++ was compiled with the wrong compiler. You should report this to the FC3 developers. As a work-around, you can configure your Python --without-cxx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 From noreply at sourceforge.net Sat Jan 29 15:17:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 15:17:57 2005 Subject: [ python-Bugs-1106057 ] README of 2.4 source download says 2.4a3 Message-ID: Bugs item #1106057, was opened at 2005-01-20 16:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Roger Erens (rogererens) Assigned to: Nobody/Anonymous (nobody) Summary: README of 2.4 source download says 2.4a3 Initial Comment: When using the links http://www.python.org/ftp/python/2.4/Python-2.4.tgz or http://www.python.org/ftp/python/2.4/Python-2.4.tar.bz2 I get to see Python2.4-a3 in the README. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 15:17 Message: Logged In: YES user_id=21627 For 2.4.0, this cannot be fixed anymore. For 2.4.1, the version number in the README was changed to 2.4 in 1.184.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 From noreply at sourceforge.net Sat Jan 29 15:22:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 15:22:32 2005 Subject: [ python-Bugs-1070140 ] endianness detection fails on IRIX 5.3 Message-ID: Bugs item #1070140, was opened at 2004-11-20 20:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070140&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: endianness detection fails on IRIX 5.3 Initial Comment: Configuring python 2.3.4 on IRIX 5.3 fails as follows: checking whether byte ordering is bigendian... unknown configure: error: unknown endianness presetting ac_cv_c_bigendian=no (or yes) will help *** Error code 1 The problem is that the respective defines are in sys/ endian.h, which is not being included in the test code. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 15:22 Message: Logged In: YES user_id=21627 Unfortunately, there is not much we can do about this (with acceptable efforts); we use the AC_C_BIGENDIAN macro of autoconf which probably needs to be changed. It would be best if you could report this problem to autoconf. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070140&group_id=5470 From noreply at sourceforge.net Sat Jan 29 20:54:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 20:54:29 2005 Subject: [ python-Bugs-1110705 ] list comprehension scope Message-ID: Bugs item #1110705, was opened at 2005-01-27 05:27 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 11:54 Message: Logged In: YES user_id=341410 "this behavior is deprecated, and relying on it will not work once this bug is fixed in a future release" As we have not yet reached the future release in which this will happen, and the 'bug' is both known and documented, it will be 'fixed' when it is fixed. The reason that it has not yet been 'fixed' is because there is a nontrivial amount of code that would break if it was. I personally would call it a deprecated 'feature'. Then again, I use it more often than I should. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-01-27 06:11 Message: Logged In: YES user_id=750513 Seemingly (according to: http://docs.python.org/ref/lists.html) this is indeed a bug that should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 05:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 From noreply at sourceforge.net Sat Jan 29 20:54:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 20:55:02 2005 Subject: [ python-Bugs-1108490 ] broken link in tkinter docs Message-ID: Bugs item #1108490, was opened at 2005-01-24 18:35 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: broken link in tkinter docs Initial Comment: "Compound" link on http://www.python.org/doc/current/lib/node721.html is broken. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-29 20:54 Message: Logged In: YES user_id=469548 Fixed in maint24 and HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 From noreply at sourceforge.net Sat Jan 29 21:12:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 21:12:45 2005 Subject: [ python-Bugs-1110055 ] recursion core dumps Message-ID: Bugs item #1110055, was opened at 2005-01-26 11:18 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 30000 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: jacob@pauling:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 30000'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-01-29 14:12 Message: Logged In: YES user_id=699438 This looks like a stack overflow. There's not much python can do when the stack runs out of memory, which is why the default recursion limit is set to 1000. Also, at least in the reproducable, the number you are building is going to consume excessive amounts of memory. I ran this test (to avoid creating a giant long number) and still got the segfault. from sys import * n = 30000 setrecursionlimit(n+1) def nofact(n): if n==1: return 1 return nofact(n-1) nofact(n) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 From noreply at sourceforge.net Sat Jan 29 21:16:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 21:16:18 2005 Subject: [ python-Bugs-1110055 ] recursion core dumps Message-ID: Bugs item #1110055, was opened at 2005-01-26 09:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 30000 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: jacob@pauling:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 30000'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 12:16 Message: Logged In: YES user_id=341410 The fact that an error occurs is not surprising. Python is limited by the C stack size, which from what I understand is well below 2GB. The fact that it gets to nearly 30k levels of recursion for you is amazing to me, the most used platform (Windows) can only ever get to around 5500 levels before they get "MemoryError: stack overflow" exceptions. I believe that the reason you are getting a segfault on linux is the way the linux malloc() and free() work. Specifically, malloc() on linux will give you a pointer to memory, regardless of whether it is available. If your program has used up all of its stack space, and you need more, the pointer will be invalid. If Python happens to call a free() before you actually access the invalid pointer, everything will work. If Python doesn't call free() before you access the invalid pointer, you get a segfault. Unfortunately, there is no way that Python (or any other program on linux) can know that the pointer it has gotten from malloc() is invalid. Furthermore, as per the docs here: http://docs.python.org/lib/module-sys.html " setrecursionlimit(limit) Set the maximum depth of the Python interpreter stack to limit. This limit prevents infinite recursion from causing an overflow of the C stack and crashing Python. The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash." I would suggest that this bug be closed as "3rd party, will not fix", and suggest the OP read the documentation. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-01-29 12:12 Message: Logged In: YES user_id=699438 This looks like a stack overflow. There's not much python can do when the stack runs out of memory, which is why the default recursion limit is set to 1000. Also, at least in the reproducable, the number you are building is going to consume excessive amounts of memory. I ran this test (to avoid creating a giant long number) and still got the segfault. from sys import * n = 30000 setrecursionlimit(n+1) def nofact(n): if n==1: return 1 return nofact(n-1) nofact(n) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 From noreply at sourceforge.net Sat Jan 29 21:20:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 21:20:32 2005 Subject: [ python-Bugs-1110055 ] recursion core dumps Message-ID: Bugs item #1110055, was opened at 2005-01-26 12:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 30000 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: jacob@pauling:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 30000'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-01-29 15:20 Message: Logged In: YES user_id=31435 The docs for setrecursionlimit() are indeed already quite clear that you boost its default value at your own risk. So this isn't a bug, it's a documented limitation. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:16 Message: Logged In: YES user_id=341410 The fact that an error occurs is not surprising. Python is limited by the C stack size, which from what I understand is well below 2GB. The fact that it gets to nearly 30k levels of recursion for you is amazing to me, the most used platform (Windows) can only ever get to around 5500 levels before they get "MemoryError: stack overflow" exceptions. I believe that the reason you are getting a segfault on linux is the way the linux malloc() and free() work. Specifically, malloc() on linux will give you a pointer to memory, regardless of whether it is available. If your program has used up all of its stack space, and you need more, the pointer will be invalid. If Python happens to call a free() before you actually access the invalid pointer, everything will work. If Python doesn't call free() before you access the invalid pointer, you get a segfault. Unfortunately, there is no way that Python (or any other program on linux) can know that the pointer it has gotten from malloc() is invalid. Furthermore, as per the docs here: http://docs.python.org/lib/module-sys.html " setrecursionlimit(limit) Set the maximum depth of the Python interpreter stack to limit. This limit prevents infinite recursion from causing an overflow of the C stack and crashing Python. The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash." I would suggest that this bug be closed as "3rd party, will not fix", and suggest the OP read the documentation. ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2005-01-29 15:12 Message: Logged In: YES user_id=699438 This looks like a stack overflow. There's not much python can do when the stack runs out of memory, which is why the default recursion limit is set to 1000. Also, at least in the reproducable, the number you are building is going to consume excessive amounts of memory. I ran this test (to avoid creating a giant long number) and still got the segfault. from sys import * n = 30000 setrecursionlimit(n+1) def nofact(n): if n==1: return 1 return nofact(n-1) nofact(n) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 From noreply at sourceforge.net Sat Jan 29 21:23:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 21:23:05 2005 Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh Message-ID: Bugs item #1108992, was opened at 2005-01-25 02:44 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-01-29 12: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 01: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 Sat Jan 29 22:02:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 22:02:21 2005 Subject: [ python-Bugs-1058960 ] install_lib fails under Python 2.1 Message-ID: Bugs item #1058960, was opened at 2004-11-02 17:57 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: install_lib fails under Python 2.1 Initial Comment: distutils/command/install_lib.py references os.extsep. os.extsep is only available in pythons >= 2.2 (The result, naturally, is an uncaught AttributeError.) Here's a quick patch (though the patch is flawed if os.extsep is ever anything but '.' --- is it?) ----Begin Patch---- Index: cvs.2/distutils/command/install_lib.py --- cvs.2/distutils/command/install_lib.py Mon, 25 Oct 2004 13:00:15 -0700 dairiki (distutils/b/43_install_li 1.1 644) +++ cvs.2(w)/distutils/command/install_lib.py Tue, 02 Nov 2004 09:48:17 -0800 dairiki (distutils/b/43_install_li 1.1 644) @@ -9,7 +9,10 @@ # Extension for Python source files. -PYTHON_SOURCE_EXTENSION = os.extsep + "py" +try: + PYTHON_SOURCE_EXTENSION = os.extsep + "py" +except AttributeError: + PYTHON_SOURCE_EXTENSION = '.py' class install_lib (Command): ----End Patch---- ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 21:02 Message: Logged In: YES user_id=113328 This has been fixed in CVS HEAD, and can be closed. It is probably a backport candidate to Python 2.4 (I can't check if that has been done). It's likely too late for 2.3... ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 12:39 Message: Logged In: YES user_id=170840 A somewhat simpler version: PYTHON_SOURCE_EXTENSION = getattr(os, 'extsep', '.') + "py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 From noreply at sourceforge.net Sat Jan 29 22:50:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 22:50:39 2005 Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth Message-ID: Bugs item #1016563, was opened at 2004-08-26 08:14 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Christoph Mussenbrock (mussenbrock) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 bug in proxy auth Initial Comment: in urllib2.py: line 502 should be: ... user_pass = base64.encodestring('%s:%s' % (unquote (user), unquote(password))).strip() the '.strip()' is missing in the current version ("2.1"). this makes an additonal '\n' at the end of user_pass. So there will be an empty line in the http header, which is buggy. (see also line 645, where the .strip() is right in place!). Best regards, Christoph ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 21:50 Message: Logged In: YES user_id=113328 The change was introduced by revision 1.32 of the file, from patch 527518. There's no mention of removing strip() there, so I suspect it was an accident. The strip() is still missing in CVS HEAD. I can see the problem, in theory (base64.encodestring returns a string with a terminating newline). However, I cannot reproduce the problem. Can the original poster provide a means of verifying the problem? It may be useful as a test case. Regardless, the change seems harmless, and can probably be applied. I attach a patch against CVS HEAD: --- urllib2.py.orig 2005-01-09 05:51:49.000000000 +0000 +++ urllib2.py 2005-01-29 21:31:49.000000000 +0000 @@ -582,7 +582,8 @@ if ':' in user_pass: user, password = user_pass.split(':', 1) user_pass = base64.encodestring('%s:%s' % (unquote(user), - unquote(password))) + unquote(password)) + ).strip() req.add_header('Proxy-authorization', 'Basic ' + user_pass) host = unquote(host) req.set_proxy(host, type) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 From noreply at sourceforge.net Sat Jan 29 23:02:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 23:02:27 2005 Subject: [ python-Bugs-977250 ] Double __init__.py executing Message-ID: Bugs item #977250, was opened at 2004-06-22 07:55 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre (kuskakus) Assigned to: Nobody/Anonymous (nobody) Summary: Double __init__.py executing Initial Comment: There is some strange feature, looking like a bug. I have 'pkg' dir with 2 files: ./pkg/__init__.py print '__init__.py' ./pkg/test.py print 'test.py' import __init__ Python 2.3.4 (#53, May 25 2004, 21:17:02) >>> import pkg.test __init__.py test.py __init__.py With '-v' option: >>> import pkg.test import pkg # directory pkg # pkg\__init__.pyc matches pkg\__init__.py import pkg # precompiled from pkg\__init__.pyc __init__.py # pkg\test.pyc matches pkg\test.py import pkg.test # precompiled from pkg\test.pyc test.py # pkg\__init__.pyc matches pkg\__init__.py import pkg.__init__ # precompiled from pkg\__init__.pyc __init__.py Why __init__.py executed two times? ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 22:02 Message: Logged In: YES user_id=113328 Essentially, because pkg\__init__.py is loaded into sys.modules under *two* names. First, as pkg (as part of the process of importing pkg.test) and then as pkg.__init__ (explicitly in pkg\test.py). As the source is loaded twice, the print is executed twice. While subtle, this is not a bug. To demonstrate: >>> import sys >>> orig = set(sys.modules.keys()) >>> import pkg.test init init test >>> set(sys.modules.keys()) - orig set(['pkg.test', 'pkg', 'pkg.__init__']) You see, both pkg and pkg.__init__ are separately in sys.modules (even though they refer to the same file). In essence, it is incorrect to import __init__ directly - always import the package. If test.py had said "import pkg", you wouldn't have seen this behaviour, but nothing else would have changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 From noreply at sourceforge.net Sun Jan 30 00:41:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 00:41:08 2005 Subject: [ python-Bugs-977250 ] Double __init__.py executing Message-ID: Bugs item #977250, was opened at 2004-06-22 08:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alexandre (kuskakus) Assigned to: Nobody/Anonymous (nobody) Summary: Double __init__.py executing Initial Comment: There is some strange feature, looking like a bug. I have 'pkg' dir with 2 files: ./pkg/__init__.py print '__init__.py' ./pkg/test.py print 'test.py' import __init__ Python 2.3.4 (#53, May 25 2004, 21:17:02) >>> import pkg.test __init__.py test.py __init__.py With '-v' option: >>> import pkg.test import pkg # directory pkg # pkg\__init__.pyc matches pkg\__init__.py import pkg # precompiled from pkg\__init__.pyc __init__.py # pkg\test.pyc matches pkg\test.py import pkg.test # precompiled from pkg\test.pyc test.py # pkg\__init__.pyc matches pkg\__init__.py import pkg.__init__ # precompiled from pkg\__init__.pyc __init__.py Why __init__.py executed two times? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-30 00:41 Message: Logged In: YES user_id=21627 I agree with that analysis; closing this as invalid. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 23:02 Message: Logged In: YES user_id=113328 Essentially, because pkg\__init__.py is loaded into sys.modules under *two* names. First, as pkg (as part of the process of importing pkg.test) and then as pkg.__init__ (explicitly in pkg\test.py). As the source is loaded twice, the print is executed twice. While subtle, this is not a bug. To demonstrate: >>> import sys >>> orig = set(sys.modules.keys()) >>> import pkg.test init init test >>> set(sys.modules.keys()) - orig set(['pkg.test', 'pkg', 'pkg.__init__']) You see, both pkg and pkg.__init__ are separately in sys.modules (even though they refer to the same file). In essence, it is incorrect to import __init__ directly - always import the package. If test.py had said "import pkg", you wouldn't have seen this behaviour, but nothing else would have changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 From noreply at sourceforge.net Sun Jan 30 00:49:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 00:49:21 2005 Subject: [ python-Bugs-1058960 ] install_lib fails under Python 2.1 Message-ID: Bugs item #1058960, was opened at 2004-11-02 18:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 Category: Distutils Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: install_lib fails under Python 2.1 Initial Comment: distutils/command/install_lib.py references os.extsep. os.extsep is only available in pythons >= 2.2 (The result, naturally, is an uncaught AttributeError.) Here's a quick patch (though the patch is flawed if os.extsep is ever anything but '.' --- is it?) ----Begin Patch---- Index: cvs.2/distutils/command/install_lib.py --- cvs.2/distutils/command/install_lib.py Mon, 25 Oct 2004 13:00:15 -0700 dairiki (distutils/b/43_install_li 1.1 644) +++ cvs.2(w)/distutils/command/install_lib.py Tue, 02 Nov 2004 09:48:17 -0800 dairiki (distutils/b/43_install_li 1.1 644) @@ -9,7 +9,10 @@ # Extension for Python source files. -PYTHON_SOURCE_EXTENSION = os.extsep + "py" +try: + PYTHON_SOURCE_EXTENSION = os.extsep + "py" +except AttributeError: + PYTHON_SOURCE_EXTENSION = '.py' class install_lib (Command): ----End Patch---- ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-30 00:49 Message: Logged In: YES user_id=21627 Closing it as fixed. A backport to 2.3 would be pointless, since 2.3 does have extsep. This change only matters assuming there will be a separate distutils release some day, which is doubtful. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-01-29 22:02 Message: Logged In: YES user_id=113328 This has been fixed in CVS HEAD, and can be closed. It is probably a backport candidate to Python 2.4 (I can't check if that has been done). It's likely too late for 2.3... ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 13:39 Message: Logged In: YES user_id=170840 A somewhat simpler version: PYTHON_SOURCE_EXTENSION = getattr(os, 'extsep', '.') + "py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 From noreply at sourceforge.net Sun Jan 30 03:38:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 03:38:38 2005 Subject: [ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2 Message-ID: Bugs item #1110007, was opened at 2005-01-26 10:24 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 Category: Build Group: 3rd Party >Status: Open >Resolution: None Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? ---------------------------------------------------------------------- >Comment By: Paul Watson (liturgist) Date: 2005-01-29 20:38 Message: Logged In: YES user_id=197677 The fc3 group begs to differ with the assessment. Perhaps someone can comment on the response to Buzilla 146563. If this bug is closed again, that's fine. I do not think I would try to reopen it. https://bugzilla.redhat.com/beta/show_bug.cgi?id=146563 ------- Additional Comments From jakub@redhat.com 2005-01-29 14:12 EST ------- /usr/local/abinitio/lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6) /usr/local/abinitio/lib/libgcc_s.so.1 is not part of Fedora Core, and is older than the system libgcc_s.so.1 in /lib/. The bug is that you are thus overriding a system library with an incompatible (well, in this case likely just older) one. You need to avoid that. In this particular case I guess just rm -f /usr/local/abinitio/lib/libgcc_s* would DTRT (perhaps make a backup copy of that). But it is certainly not a bug in the distro, but a problem caused by badly packaged 3rd party software. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 08:08 Message: Logged In: YES user_id=21627 This is clearly a bug in your gcc installation - perhaps some library is not up-to-date, or libstdc++ was compiled with the wrong compiler. You should report this to the FC3 developers. As a work-around, you can configure your Python --without-cxx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 From noreply at sourceforge.net Sun Jan 30 03:51:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 03:51:43 2005 Subject: [ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2 Message-ID: Bugs item #1110007, was opened at 2005-01-26 10:24 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 Category: Build Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? ---------------------------------------------------------------------- >Comment By: Paul Watson (liturgist) Date: 2005-01-29 20:51 Message: Logged In: YES user_id=197677 My apologies. The problem was another libgcc_s.so that was installed by another third-party product, not Python. Once this was removed from LD_LIBRARY_PATH, it appears to be successful. Sorry. ---------------------------------------------------------------------- Comment By: Paul Watson (liturgist) Date: 2005-01-29 20:38 Message: Logged In: YES user_id=197677 The fc3 group begs to differ with the assessment. Perhaps someone can comment on the response to Buzilla 146563. If this bug is closed again, that's fine. I do not think I would try to reopen it. https://bugzilla.redhat.com/beta/show_bug.cgi?id=146563 ------- Additional Comments From jakub@redhat.com 2005-01-29 14:12 EST ------- /usr/local/abinitio/lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6) /usr/local/abinitio/lib/libgcc_s.so.1 is not part of Fedora Core, and is older than the system libgcc_s.so.1 in /lib/. The bug is that you are thus overriding a system library with an incompatible (well, in this case likely just older) one. You need to avoid that. In this particular case I guess just rm -f /usr/local/abinitio/lib/libgcc_s* would DTRT (perhaps make a backup copy of that). But it is certainly not a bug in the distro, but a problem caused by badly packaged 3rd party software. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-29 08:08 Message: Logged In: YES user_id=21627 This is clearly a bug in your gcc installation - perhaps some library is not up-to-date, or libstdc++ was compiled with the wrong compiler. You should report this to the FC3 developers. As a work-around, you can configure your Python --without-cxx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 From noreply at sourceforge.net Sun Jan 30 05:25:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 05:25:21 2005 Subject: [ python-Bugs-1092225 ] IDLE hangs due to subprocess Message-ID: Bugs item #1092225, was opened at 2004-12-28 10:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: ZACK (kitanek) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs due to subprocess Initial Comment: IDLE GUI hangs after some time when launched in the default mode (i.e. with the subprocess). I have noticed that the subprocess generates fast continuous stream of system calls even if the GUI is not used and not visible (moved to another desktop). Example output from strace (strace -f idle): ... [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] select(4, [3], [], [], {0, 50000} [pid 5355] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) [pid 5355] write(7, "\0", 1 [pid 5356] <... select resumed> ) = 1 (in [6]) [pid 5355] <... write resumed> ) = 1 [pid 5356] futex(0x81c7250, FUTEX_WAIT, 2, NULL [pid 5355] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5356] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable) [pid 5355] <... futex resumed> ) = 0 [pid 5356] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5355] gettimeofday( [pid 5356] <... futex resumed> ) = 0 [pid 5355] <... gettimeofday resumed> {1104246902, 467914}, {4294967236, 0}) = 0 [pid 5356] read(6, [pid 5355] gettimeofday( [pid 5356] <... read resumed> "\0", 1) = 1 [pid 5355] <... gettimeofday resumed> {1104246902, 468040}, {4294967236, 0}) = 0 [pid 5356] select(7, [6], [], [], NULL [pid 5355] select(6, [5], [], [], {0, 50000} [pid 5357] <... select resumed> ) = 0 (Timeout) [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] select(0, NULL, NULL, NULL, {0, 50000} [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 ... If IDLE is launched without the subprocess (idle -n) than it seems to run just fine without the syscall storm: futex(0x83d1fa0, FUTEX_WAIT, 200, NULL ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-29 23:25 Message: Logged In: YES user_id=149084 No response from OP. Closing as 'worksforme' ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-01 12:17 Message: Logged In: YES user_id=149084 The socket is polled by the GUI and the subprocess. What you are seeing is the normal delays and polls. Without the subprocess there is no socket and therefore no polling. Further information is needed. When IDLE "hangs", does the GUI become inactive? Can the subprocess be restarted? Is there any evidence (via ps etc.) that the system is running out of some resource? Does the problem occur if you send a continuous stream of characters to stdout? Is the interval to a "hang" always the same? ---------------------------------------------------------------------- Comment By: ZACK (kitanek) Date: 2004-12-28 10:38 Message: Logged In: YES user_id=1159448 Sorry, I forgot the system specs: Debian Linux, unstable branche (SID) Kernel 2.6.9-1-686 Python 2.3.4 (#2, Dec 3 2004, 13:53:17) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 glib-config --version = 1.2.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 From noreply at sourceforge.net Sun Jan 30 14:40:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 14:40:50 2005 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 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=1112549&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Sun Jan 30 18:02:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 18:02:40 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-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 Sun Jan 30 20:43:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 20:43:46 2005 Subject: [ python-Bugs-1108992 ] idle freezes when run over ssh Message-ID: Bugs item #1108992, was opened at 2005-01-25 02:44 Message generated for change (Comment added) made by josiahcarlson 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: Josiah Carlson (josiahcarlson) Date: 2005-01-30 11: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 09: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 12: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 01: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 Sun Jan 30 21:06:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 21:06:54 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-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 Sun Jan 30 23:56:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 23:56:08 2005 Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k Message-ID: Bugs item #989338, was opened at 2004-07-12 13:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' ====================================================================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' ====================================================================== ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-01-30 23:56 Message: Logged In: YES user_id=21627 No. A release candidate for 2.3.5 was already made; at this point, test cases should not be changed anymore. As 2.3.5 will be the last 2.3 release, backporting the change *after* 2.3.5 is pointless. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-01-27 22:16 Message: Logged In: YES user_id=671362 Can anyone merge this(test_unicode_file.py rev 1.16) to release23-maint branch? This is not specific to Python 2.4. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-07 20:58 Message: Logged In: YES user_id=21627 This is now fixed in test_unicode_file.py 1.16. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-11-07 11:12 Message: Logged In: YES user_id=21627 I'm talking about the third tab on XP regional settings; I don't know how the user interface looks in W2k. This tab says something like "language for programs which don't support Unicode". It might be that this setting is simply not available on W2k. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-03 09:23 Message: Logged In: YES user_id=115179 Martin, on other w2k pro (english) sp4 with POLISH locale set this test works as expected - "All the Unicode tests appeared to work". Both versions have the same settings for regional options - polish: On first tab (general) I have Polish location and other languages on the same tab selected: western europe and US, central europe. On last tab (6 = input locales) I have polish programmers and endglish (US). Third tab - currency ? Or this test fails on non english versions of W2K ? German ? Hungarian ? ... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-11-02 18:28 Message: Logged In: YES user_id=115179 same effect on non french w2k (polish locale), this persists on any python 2.x version and is rather independent from windows version - in my case it is w2k pro sp4. file created with this encoding works fine with windows commander - if that matters ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-10-15 08:14 Message: Logged In: YES user_id=21627 In control panel/regional settings, change the first *and* the third tab to English. This requires a reboot. The failure itself is harmless. test_support assumes that TESTFN_UNICODE = unicode("@test-\xe0\xf2", "latin-1") is a filename that can be represented in the default file encoding. On Windows, if the default file encoding is not CP-1252 (as it is in the Western European installations), this file name cannot be represented correctly in "mbcs". To fix this, we would need to come up with procedure to generate a file name depending on the locale. Unfortunately, such a procedure is very difficult to implement. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-10-14 10:59 Message: Logged In: YES user_id=358087 How do I switch my locale to English on winXP pro? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-13 17:31 Message: Logged In: YES user_id=29957 Sounds like a locale thing - do the people seeing the bug have the problem if they switch their locale to english? ---------------------------------------------------------------------- Comment By: Marek Baczynski (imbaczek) Date: 2004-09-17 01:30 Message: Logged In: YES user_id=838849 I have the very same errors as quiver on WinXP SP1, Python 2.4a3, NTFS, locale Polish. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-07 16:37 Message: Logged In: YES user_id=671362 I can reproduce this in Python 2.4a3 on Win 2K SP4(locale is set to Japanese). File system is NTFS. But on my box, test_single_files passes OK. Only test_equivalent_files and test_directories raise ERROR. Here is the result. test_unicode_file test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ok ============================================== ======================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 185, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_UNICODE+ext, True) File "C:\Python24\lib\test\test_unicode_file.py", line 114, in _do_directory os.chdir(chdir_name) OSError: [Errno 2] No such file or directory: u'@test-\xe0 \xf2.dir' ============================================== ======================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 176, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\Python24\lib\test\test_unicode_file.py", line 157, in _test_equivalent self._do_equivilent(filename1, filename2) File "C:\Python24\lib\test\test_unicode_file.py", line 67, in _do_equivilent os.stat(filename2)) OSError: [Errno 2] No such file or directory: u'@test-\xe0\xf2' ------------------------------------------------------------ ---------- Ran 3 tests in 0.070s FAILED (errors=2) test test_unicode_file failed -- errors occurred; run in verbose mode for details 1 test failed: test_unicode_file ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-09-07 08:56 Message: Logged In: YES user_id=358087 Yes it does :-( I have a winXP on IBM T-40. The other language that is installed is Hebrew. The problem that when encoding TESTFN_UNICODE with the file system ecoding (mbcs) the resulted string is "@test-??" which is not a legal file name on windows ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 08:31 Message: Logged In: YES user_id=80475 Does this still fail for you in Py2.4a3 ? If not, please note the result and close the bug. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-18 08:44 Message: Logged In: YES user_id=358087 File system is NTFS. winver gives: Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 18:55 Message: Logged In: YES user_id=21627 Are you using a FAT partition? What precise version string do you get in winver.exe? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-13 08:10 Message: Logged In: YES user_id=358087 Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro. Any other data I can send? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-12 18:35 Message: Logged In: YES user_id=31435 Peculiar -- it works fine on WinXP Pro, which ought to work the same as Win2K here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 From noreply at sourceforge.net Mon Jan 31 00:43:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 00:43:31 2005 Subject: [ python-Bugs-531205 ] Bugs in rfc822.parseaddr() Message-ID: Bugs item #531205, was opened at 2002-03-18 17:13 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Ben Gertzfield (che_fox) Summary: Bugs in rfc822.parseaddr() Initial Comment: This bug is in rfc822.parseaddr(), and thus inherited into email.Utils.parseaddr() since the latter does a straight include of the former. It has a nasty bug when the email address contains embedded spaces: it collapses the spaces: >>> from email.Utils import parseaddr >>> parseaddr('foo bar@wooz.org') ('', 'foobar@wooz.org') >>> parseaddr('<foo bar@wooz.org>') ('', 'foobar@wooz.org') Boo, hiss. Of course parseaddr() would be more involved to implement in an RFC 2822 compliant way, but it would be very cool. Note that I'm reporting this bug here instead of the mimelib project because it's actually in rfc822.py. Once solution might include fixing it in the email package only. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 12:43 Message: Logged In: YES user_id=552329 IMO, the current behaviour should be retained for the reasons outlined by Tim Roberts, or extra code should be added to strip spaces around periods and the @, and if there are others then ('', '') should be returned. The latter is probably more correct, but there doesn't seem to be any pressing reason for the former. As such, recommend closing "Won't fix". If the latter behaviour is desired, then I could work up a patch for it. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 14:29 Message: Logged In: YES user_id=752496 Reassigning it as a Py2.4 bug. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-11-09 09:49 Message: Logged In: YES user_id=113328 This issue still exists in Python 2.3.4 and Python 2.4b2. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-23 06:30 Message: Logged In: YES user_id=469548 Well, the docs say "unless the parse fails, in which case a 2-tuple of ('', '') is returned". I think it's reasonable to say that non-compliant addresses like this should fail to parse and thus that parseaddr('foo bar@wooz.org') should returns ('', '') ---------------------------------------------------------------------- Comment By: Tim Roberts (timroberts) Date: 2002-08-13 09:40 Message: Logged In: YES user_id=265762 Interesting to note that RFC 822 (but not 2822) allows spaces around any periods in the address without quoting (2822 does allow spaces around the @), and those spaces are to be removed. Section A.1.4 gives the example Wilt . Chamberlain@NBA.US and says it should be parsed as "Wilt.Chamberlain". Given that, it's hard for me to see that the current behavior should be changed at all, since there is no correct way to parse this non-compliant address. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-16 05:18 Message: Logged In: YES user_id=12800 Note further that "foo bar"@wooz.org is properly parsed. The question is, what should parseaddr() do in this non-compliant situation? I can think of a couple of things: - it could raise an exception - it could return ('', 'bar@wooz.org') - it could return ('foo', 'bar@wooz.org') - it could return ('' '"foo bar"@wooz.org') I'm not sure what the right thing to do is. I'm assigning to Ben Gertzfield to get his opinion. Ben, feel free to add a comment and re-assign the bug to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470 From noreply at sourceforge.net Mon Jan 31 00:57:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 00:57:19 2005 Subject: [ python-Bugs-768419 ] Subtle bug in os.path.realpath on Cygwin Message-ID: Bugs item #768419, was opened at 2003-07-10 00:38 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Subtle bug in os.path.realpath on Cygwin Initial Comment: Cygwin allows mounting directories within other mount points. This can cause os.path.realpath to expand some symlinks that it shouldn't. For example: $ cd / $ mkdir X $ mkdir X/Y $ ln -s X Z $ mount C:/ /Z/Y $ ls Z/Y [...contents of C:\...] $ ls X/Y [empty directory] $ python -c "import os; print os.path.realpath('Z/Y')" /X/Y [bad because /X/Y is empty yet the original Z/Y has files] In Cygwin, the correct answer would be either 'C:\' or '/cygdrive/c/'. Conceivably this problem can happen in UNIces other than Cygwin. It would be rather annoying to fix, because it would require looking at the mount table. But I thought I would mention it anyway... ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 12:57 Message: Logged In: YES user_id=552329 I agree with Sjoerd - this is a Cygwin bug, not a Python one. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-07-10 01:33 Message: Logged In: YES user_id=43607 I'd think this is rather a Cygwin bug than a Python bug. Before the mount, /X/Y and /Z/Y refer to the same directory, and on Unix they have the same device/inode combination. And that combination is the all-important factor when doing a mount on that directory. If you do this on Unix (I used an NFS mount instead of the mount shown in the report), both /X/Y and /Z/Y contain the mounted directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470 From noreply at sourceforge.net Mon Jan 31 01:15:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 01:15:24 2005 Subject: [ python-Bugs-803413 ] uu.decode prints to stderr Message-ID: Bugs item #803413, was opened at 2003-09-10 08:31 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803413&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sami Hangaslammi (shang) Assigned to: Nobody/Anonymous (nobody) Summary: uu.decode prints to stderr Initial Comment: Python 2.3 final The standard library function uu.decode prints a warning message to stderr if there is an error when decoding the file. This feels like an incorrect behaviour for a library function. The warning message can be supressed by providing a quiet=True parameter, but this is not currently documented. The relevant line in uu.py is 138 ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 13:15 Message: Logged In: YES user_id=552329 Printing to stderr outside of debugging is uncommon for the standard library, but there are other modules (ftplib, asyncore) that do it. In this case, it only happens when there is an error (which can be recovered from), so printing to stderr seems fairly appropriate. An alternative would be to call warnings.warn(), although by default that will have the same effect. Documenting the 'quiet' parameter seems reasonable, however, and would be a simple change to libuu.tex. I can produce such a patch, if desired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803413&group_id=5470 From noreply at sourceforge.net Mon Jan 31 01:25:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 01:25:19 2005 Subject: [ python-Bugs-989333 ] Empty curses module is loaded in win32 Message-ID: Bugs item #989333, was opened at 2004-07-12 23:00 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Empty curses module is loaded in win32 Initial Comment: When doing "import curses" an empty curses module is loaded. I think that since curses is not supported in win32 that an ImportError should be raised (like in 2.3) ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 13:25 Message: Logged In: YES user_id=552329 I do not get this behaviour (I get the expected ImportError): C:\>c:\python22\python Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python23\python Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python24\python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? File "c:\python24\lib\curses\__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses What version of Python is this with? Do you possibly have a curses.pyc that shouldn't be there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 From noreply at sourceforge.net Mon Jan 31 01:42:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 01:42:24 2005 Subject: [ python-Bugs-1090076 ] Defaults in ConfigParser.get overrides section values Message-ID: Bugs item #1090076, was opened at 2004-12-23 11:23 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: Defaults in ConfigParser.get overrides section values Initial Comment: ConfigParser.get has an optional argument vars that - according to the docstring- "which must be a dictionary whose contents overrides any pre-existing defaults." I understand that it overrides the default values, but should not override an actual value existing in the file. That is, given this contents: [DEFAULT] key1=default1 [section] key2=value2 vars={'key1:vars1','key2:vars2'} cfg.get('section','key1',0,vars) gives 'vars1' (ok) cfg.get('section','key2',0,vars) gives 'vars2' (wrong, should be 'value2', since key2 is actually in the section and no default is needed). To correct this behavior, simply move this two lines of code up in ConfigParser.get (ConfigParser.py), just below the first line and before the first try/except: # Update with the entry specific variables if vars is not None: d.update(vars) ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 13:42 Message: Logged In: YES user_id=552329 This is indeed what happens. However, changing this could break existing code, so an alternative fix would be to change the documentation to "overrides any pre-existing values.". I am not sure what the desired behaviour is - if it is what is current, then recommend updating the documentation. If the desired behaviour is what the documentation currently says, then recommend applying the above patch (although the code is not exactly the same anymore, the effect is). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470 From noreply at sourceforge.net Mon Jan 31 01:58:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 01:58:26 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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470 From noreply at sourceforge.net Mon Jan 31 04:46:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 04:46:47 2005 Subject: [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE Message-ID: Bugs item #783887, was opened at 2003-08-05 22:00 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 Category: IDLE >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Andy Huibers (ahuibers) Assigned to: Kurt B. Kaiser (kbk) Summary: Tab / Space Configuration Does Not Work in IDLE Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-30 22:46 Message: Logged In: YES user_id=149084 Removed Tab indentation selection from the Options dialog. Not appropriate for IDLE. Tab indentation default may still be configured 'manually' by modifying config-main.def but that's for experts. You can switch on tabs for individual Edit windows using the Format menu. (Note: the Tab indent option was never finished and never operable) Changing the 'screen' indent width in the Options menu will now be effective if you aren't using tabs (it's always 8 if you are using tabs). Thanks for the patch and the reminder. ---------------------------------------------------------------------- Comment By: Nanjundi (nanjundi) Date: 2005-01-17 15:07 Message: Logged In: YES user_id=1199110 I got the error. I am using Python 2.3.4. Hitting TAB in the editor advances the cursor by "4" spaces irrespective of the "indent width" in Configure idle...-> Fonts/Tab -> choose indentation size: I did a quick and dirty fix. I had to modify the Line# 915 in file Python23/Lib/idlelib/EditorWindow.py Requires restart of IDLE for the change to take effect. [Before] indentwidth = 3 [After] indentwidth = idleConf.GetOption('main','Indent','num-spaces', default=4,type='int') ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-09-05 18:26 Message: Logged In: YES user_id=149084 I can reproduce this on XP and Linux. Of course, everyone should use 4 spaces :) ---------------------------------------------------------------------- Comment By: Andy Huibers (ahuibers) Date: 2003-08-06 14:09 Message: Logged In: YES user_id=838612 Mmm.. I re-installed the Windows Python-2.3 installer EXE on a fresh PC and I have the problem, even when I hit "Apply" and "OK". It is not a big deal of course, but would be nice if it worked.. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 00:17 Message: Logged In: YES user_id=80475 I cannot reproduce the problem. This may be a silly question, but did you click Apply after changing the setting? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply at sourceforge.net Mon Jan 31 05:55:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 05:55:22 2005 Subject: [ python-Bugs-1112949 ] ioctl has problems on 64 bit machines Message-ID: Bugs item #1112949, was opened at 2005-01-31 15: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=1112949&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stephen Norris (stephennorris) Assigned to: Nobody/Anonymous (nobody) Summary: ioctl has problems on 64 bit machines Initial Comment: fcntly.ioctl takes an int as the second argument. If the value passed is a large 32 bit quantity (0x80046601 for example - EXT2_IOC_GETFLAGS) then I get: Traceback (most recent call last): File "CommSecure-CVS/Operations/checkSpace.py", line 73, in ? main(sys.argv[1:]) File "CommSecure-CVS/Operations/checkSpace.py", line 25, in main os.path.walk(file, doDirectory, total) File "/usr/lib64/python2.3/posixpath.py", line 282, in walk func(arg, top, names) File "CommSecure-CVS/Operations/checkSpace.py", line 61, in doDirectory flags = fcntl.ioctl(fd, EXT3_IOC_GETFLAGS, " ") OverflowError: signed integer is greater than maximum My _guess_ here is that the code is checking against 32 bit quantities rather than 64 bit when converting to the C data type? Platform is Linux, Fedora Core 3 on AMD Opteron. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470 From noreply at sourceforge.net Mon Jan 31 06:18:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 06:18:44 2005 Subject: [ python-Bugs-1112955 ] move_file()'s return value when dry_run=1 unclear Message-ID: Bugs item #1112955, was opened at 2005-01-31 06: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=1112955&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eelis (eelis) Assigned to: Nobody/Anonymous (nobody) Summary: move_file()'s return value when dry_run=1 unclear Initial Comment: distutils.file_util.move_file has the following signature: move_file(src, dst, verbose=0, dry_run=0) Unfortunately, the purpose of the dry_run parameter is not described in the documentation. However, it's obvious that one effect of specifying dry_run=1 should be that the file is not actually moved. Less obvious is how dry_run=1 affects move_file's return value, which the documentation describes as follows: "Returns the new full name of the file." Should the dry_run parameter be allowed to affect the return value? My guess is that it shouldn't, but it does (on win32 and linux): # given a file named foo and a directory named bar move_file('foo', 'bar', 0, 1) #-> 'bar' move_file('foo', 'bar', 0, 0) #-> 'bar/foo' A quick look at the source code showed that: if isdir(dst): dst = os.path.join(dst, basename(src)) is executed _before_: if dry_run: return dst which causes the discrepancy. Is this a bug, or should the return value of move_file when dry_run=1 be considered unreliable? If the latter is the case, perhaps it should be documented explicitly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112955&group_id=5470 From noreply at sourceforge.net Mon Jan 31 07:26:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 07:26:18 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 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 Mon Jan 31 08:13:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 08:13:25 2005 Subject: [ python-Bugs-989333 ] Empty curses module is loaded in win32 Message-ID: Bugs item #989333, was opened at 2004-07-12 14:00 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Empty curses module is loaded in win32 Initial Comment: When doing "import curses" an empty curses module is loaded. I think that since curses is not supported in win32 that an ImportError should be raised (like in 2.3) ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2005-01-31 09:13 Message: Logged In: YES user_id=358087 Currently I have 2.4 installed and I also get an ImportError. Looks likes something went wrong with my 2.3 installation. Closing the bug. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-01-31 02:25 Message: Logged In: YES user_id=552329 I do not get this behaviour (I get the expected ImportError): C:\>c:\python22\python Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python23\python Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? ImportError: No module named curses C:\>c:\python24\python Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import curses Traceback (most recent call last): File "", line 1, in ? File "c:\python24\lib\curses\__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses What version of Python is this with? Do you possibly have a curses.pyc that shouldn't be there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470 From noreply at sourceforge.net Mon Jan 31 16:43:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 16:44:00 2005 Subject: [ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0 Message-ID: Bugs item #1105699, was opened at 2005-01-20 00:52 Message generated for change (Comment added) made by rjk1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); ---------------------------------------------------------------------- Comment By: Richard Kettlewell (rjk1002) Date: 2005-01-31 15:43 Message: Logged In: YES user_id=217390 C does guarantee that all struct pointers share the same *representation* (section 6.2.5 of C99). That's not what the compiler is complaining about here. Rather, a struct declared inside a parameter list is restricted in scope to that parameter list, and so is not the same structure as one declared outside it, even if the tag is the same. The solution is to forward-declare the struct (as an incomplete type, i.e. just "struct winsize;") before any of the declarations that use it. Then the struct tag will mean the same thing in every scope. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-20 23:13 Message: Logged In: YES user_id=31435 The warning almost certainly means that there's no declaration of struct winsize in scope when these externs are declared. That's bad, because C doesn't guarantee that all pointers are the same size (although they are on all Python platforms I'm aware of). Some quality time with Google suggested that other projects wormed around this by #include'ing instead of , because the former but not the latter #include's where the winsize struct was defined. Beats me -- ain't a Windows problem . ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 22:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-20 15:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 From noreply at sourceforge.net Mon Jan 31 17:01:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 17:01:15 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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 From noreply at sourceforge.net Mon Jan 31 17:27:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 17:27:57 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-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 Mon Jan 31 17:46:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 17:46:20 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-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 Mon Jan 31 18:12:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 18:12:14 2005 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-01-31 17:12 Message: Logged In: YES user_id=6656 Finally fixed this (odd definition of "tomorrow", I know...) Misc/NEWS revision 1.1236 Objects/stringobject.py revision 2.227 Modules/posixmodule.c revision 2.333 Sorry for the wait... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-05 10:30 Message: Logged In: YES user_id=6656 I'm waiting until I'm not behind a modem at my parents' house :) Tomorrow. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-05 00:39 Message: Logged In: YES user_id=80475 No, I simply tried the OP's example and reported its behavior on my system. If you don't want to create a new test file, try adding this on to test_subprocess. Yes, I read the patch. Yes, I forgot you added the assertion already. So are you going commit or wait for an engraved invitation? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 21:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 20:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 04:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 23:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Mon Jan 31 18:53:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 18:54:01 2005 Subject: [ python-Bugs-1113328 ] OSATerminology still semi-broken Message-ID: Bugs item #1113328, was opened at 2005-01-31 17:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113328&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: OSATerminology still semi-broken Initial Comment: OSATerminology.GetSysTerminology() is broken as it calls OSAGetAppTerminology instead of OSAGetSysTerminology. Attached diff fixes this bug, and additionally patches both functions to ignore any modeFlags arguments passed by user as this value should always be kOSAModeNull. Some minor additions and improvements to commenting and docstrings too. Tested and working on Python 2.3.3, OS 10.2.8. See also bug #884085, patch #979784. (Note that this patch supercedes #979784.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113328&group_id=5470 From noreply at sourceforge.net Mon Jan 31 22:46:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 31 22:46:51 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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113484&group_id=5470