From noreply at sourceforge.net Wed Aug 1 15:56:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 06:56:10 -0700 Subject: [ python-Bugs-1765375 ] setup.py trashes LDFLAGS Message-ID: Bugs item #1765375, was opened at 2007-08-01 15: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=1765375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Harald Koenig (h_koenig) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py trashes LDFLAGS Initial Comment: the regexp below will trash the library path in this line in Makefile LDFLAGS = -L/foo/lib -Wl,-rpath,/foo/lib -L/bar/lib -Wl,-rpath,/bar/lib to -L/foo/libWl,-rpath,/foo/lib -L/bar/libWl,-rpath,/bar/lib which renders this library paths broken and useless for building python modules. the following patch seems to work fine for my setup on various plattforms: --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- --- Python-2.5.1/setup.py~ 2007-08-01 15:19:27.000000000 +0200 +++ Python-2.5.1/setup.py 2007-08-01 15:19:48.000000000 +0200 @@ -267,7 +267,7 @@ # strip out double-dashes first so that we don't end up with # substituting "--Long" to "-Long" and thus lead to "ong" being # used for a library directory. - env_val = re.sub(r'(^|\s+)-(-|(?!%s))' % arg_name[1], '', env_val) + env_val = re.sub(r'(^|\s+)-(-|(?!%s))' % arg_name[1], ' ', env_val) parser = optparse.OptionParser() # Make sure that allowing args interspersed with options is # allowed --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1765375&group_id=5470 From noreply at sourceforge.net Wed Aug 1 19:05:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 10:05:56 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 15:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Wed Aug 1 19:37:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 10:37:48 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 15:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Wed Aug 1 23:52:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 14:52:41 -0700 Subject: [ python-Feature Requests-1764638 ] add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP Message-ID: Feature Requests item #1764638, was opened at 2007-07-31 17:12 Message generated for change (Comment added) made by doublep You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Pogonyshev (doublep) Assigned to: Nobody/Anonymous (nobody) Summary: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP Initial Comment: In disassembled code of Python functions I often see stuff like this: 421 JUMP_IF_FALSE 14 (to 438) 424 POP_TOP 1178 ... 435 JUMP_FORWARD 1 (to 439) >> 438 POP_TOP >> 439 END_FINALLY Note how both branches of execution after JUMP_IF_FALSE do POP_TOP. This causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass the POP_TOP command. I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and JUMP_IF_TRUE_AND_POP. Their semantics would be the same as that of existing JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once, after checking whether to jump. This would simplify the above code to just 421 JUMP_IF_FALSE_AND_POP 14 (to 438) 1178 ... >> 438 END_FINALLY This shortens bytecode by 5 bytes and both execution branches, by 1 and 2 commands correspondingly. I'm willing to create a patch, if this sounds like a worthwile improvement. Maybe it is better to skip 2.6 and target it for 3000 instead. ---------------------------------------------------------------------- >Comment By: Paul Pogonyshev (doublep) Date: 2007-08-02 00:52 Message: Logged In: YES user_id=1203127 Originator: YES I have made first stab at this. It shows about 2% speedup on pystone, even though peephole optimizer does no related optimizations for new bytecodes yet. Note that having separate entries in ceval.c's switch() for the new bytecodes is essential. Perhaps because they are also used for prediction, not sure. File Added: new-bytecodes.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470 From noreply at sourceforge.net Thu Aug 2 01:08:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 16:08:02 -0700 Subject: [ python-Bugs-1759997 ] poll() on cygwin sometimes fails [PATCH] Message-ID: Bugs item #1759997, was opened at 2007-07-25 00:58 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759997&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Warner (warner) Assigned to: Nobody/Anonymous (nobody) Summary: poll() on cygwin sometimes fails [PATCH] Initial Comment: While trying to track down a problem with our application (http://allmydata.org) running under cygwin, I discovered that the select.poll() object sometimes returns completely bogus data. poll() returns a list of tuples of (fd, revent), but fds are supposed to be small integers, and revents are a bitmask of POLLIN/POLLOUT flags. In my tests, I saw poll() return a list that started out looking normal, but the last half of the list contained fds and revents values like fd=0x7672a646, revent=0xd819. It turns out that under cygwin-1.5.24 (which I believe is a pretty recent version), the poll() call sometimes violates the POSIX specification, and provides a return value which is different than the number of pollfd structures that have non-zero .revents fields (generally larger). This causes the implementation of poll_poll() (in Modules/selectmodule.c) to read beyond the end of the pollfd array, copying random memory into the python list it is building, causing the bogus values I observed during my tests. These bogus values were mostly ignored, because the Twisted pollreactor that I was using noticed that the fd didn't correspond to any previously-registered file descriptor. It was only when the bogus fd happened to coincide with a real one (and when that indicated that a TCP listening socket became writable, which should never happen) that an exception was raised. The attached patch (against 2.5.1) works around the problem by manually counting the number of non-zero .revents, rather than relying upon the return value from poll(). This version passes test_poll on both linux and cygwin. cheers, -Brian Warner ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2007-08-01 23:08 Message: Logged In: YES user_id=52562 Originator: NO FYI, this is the issue ticket on the allmydata.org Tahoe project: http://allmydata.org/trac/tahoe/ticket/31 I've written a patch for cygwin poll and am now testing it before submitting it to the cygwin developers. ---------------------------------------------------------------------- Comment By: Brian Warner (warner) Date: 2007-07-27 23:25 Message: Logged In: YES user_id=24186 Originator: YES We've begun the process: zooko is working on a patch for cygwin and is working with them to figure out how to compile the thing. We've not yet explained the poll() bug to them in detail (wanting to have a patch in hand first). I'll report back once we get some word from them about how likely it is this problem will be fixed on the cygwin side. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-07-25 05:53 Message: Logged In: YES user_id=33168 Originator: NO Has this problem been reported to cygwin? Have they fixed the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759997&group_id=5470 From noreply at sourceforge.net Thu Aug 2 02:45:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 17:45:16 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-05 18:19 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-01 20:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 13:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 13:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 01:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Thu Aug 2 05:15:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 20:15:42 -0700 Subject: [ python-Bugs-1725899 ] decimal sqrt method doesn't use round-half-even Message-ID: Bugs item #1725899, was opened at 2007-05-25 19:52 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Facundo Batista (facundobatista) Summary: decimal sqrt method doesn't use round-half-even Initial Comment: According to version 1.66 of Cowlishaw's `General Decimal Arithmetic Specification' the square-root operation in the decimal module should round using the round-half-even algorithm (regardless of the rounding setting in the current context). It doesn't appear to do so: >>> from decimal import * >>> getcontext().prec = 6 >>> Decimal(9123455**2).sqrt() Decimal("9.12345E+6") The exact value of this square root is exactly halfway between two representable Decimals, so using round-half-even with 6 digits I'd expect the answer to be rounded to the neighboring representable Decimal with *even* last digit---that is, Decimal("9.12346E+6") This bug only seems to occur when the number of significant digits in the argument exceeds the current precision (indeed, if the number of sig. digits in the argument is less than or equal to the current precision then it's impossible for the square root to be halfway between two representable floats). It seems to me that this is a minor bug that will occur rarely and is unlikely to have any serious effect even when it does occur; however, it does seem to be a deviation from the specification. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-08-02 00:15 Message: Logged In: YES user_id=752496 Originator: NO Fixed in the revisions 56654 to 56656, in the decimal-branch, using patches generated by Mark, thanks! ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 15:57 Message: Logged In: YES user_id=703403 Originator: YES See patch 1741308. I'll contact Mike Cowlishaw to verify that the reference implementation really is buggy. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-06-22 13:06 Message: Logged In: YES user_id=31435 Originator: NO Of course you're right, the spec does say inputs shouldn't be rounded. And that last example is horrendous: sqrt should definitely be monotonic (a floating function f is "monotonic" if it guarantees f(x) >= f(y) whenever x >= y; you found x and y such that x > y but sqrt(x) < sqrt(y) -- ouch!). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 03:35 Message: Logged In: YES user_id=703403 Originator: YES One more result. This is definitely getting suspicious now--I'll submit my patch. >>> from decimal import * >>> getcontext().prec = 3 >>> Decimal(11772).sqrt() Decimal("109") >>> Decimal(11774).sqrt() Decimal("108") ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-06-22 03:16 Message: Logged In: YES user_id=703403 Originator: YES Some more strange results for sqrt(): with Emax = 9, Emin = -9 and prec = 3: 1. In the following, should the Subnormal and Underflow flags be set? The result before rounding is subnormal, even though the post-rounding result is not, and the spec seems to say that those flags should be set in this situation. But Cowlishaw's reference implementation (version 3.50) doesn't set these flags. (If 9.998 is replaced by 9.99 then the flags *are* set, which seems inconsistent.) >>> Decimal("9.998E-19").sqrt() Decimal("1.00E-9") >>> getcontext() Context(prec=3, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9, capitals=1, flags=[Rounded, Inexact], traps=[DivisionByZero, Overflow, InvalidOperation]) 2. As I understand the spec, the following result is incorrect: >>> Decimal("1.12E-19").sqrt() Decimal("3.4E-10") (The true value of the square root is 3.34664...e-10, which should surely be rounded to 3.3E-10, not 3.4E-10?). But again, Cowlishaw's reference implementation also gives 3.4E-10. 3. Similarly for the following >>> Decimal("4.21E-20").sqrt() Decimal("2.0E-10") The answer should, I think, be 2.1E-10; here the reference implementation also gives 2.1E-10. 4. And I can't justify this one at all... >>> Decimal("1.01001").sqrt() Decimal("1.01") Shouldn't this be 1.00? But again Python agrees with the reference implementation. Either all this is pretty mixed up, or I'm fundamentally misunderstanding things. I have a patch that I think fixes all these bugs; if there's any agreement that they really are bugs then I'll post it. Can anyone shed any light on the above results? ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-05-25 20:30 Message: Logged In: YES user_id=703403 Originator: YES I don't think inputs should be rounded; note 1 near the start of the `Arithmetic Operations' section of the specification says: "Operands may have more than precision digits and are not rounded before use." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2007-05-25 20:24 Message: Logged In: YES user_id=31435 Originator: NO Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1725899&group_id=5470 From noreply at sourceforge.net Thu Aug 2 06:24:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 21:24:17 -0700 Subject: [ python-Feature Requests-1764638 ] add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP Message-ID: Feature Requests item #1764638, was opened at 2007-07-31 09:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Pogonyshev (doublep) >Assigned to: Raymond Hettinger (rhettinger) Summary: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP Initial Comment: In disassembled code of Python functions I often see stuff like this: 421 JUMP_IF_FALSE 14 (to 438) 424 POP_TOP 1178 ... 435 JUMP_FORWARD 1 (to 439) >> 438 POP_TOP >> 439 END_FINALLY Note how both branches of execution after JUMP_IF_FALSE do POP_TOP. This causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass the POP_TOP command. I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and JUMP_IF_TRUE_AND_POP. Their semantics would be the same as that of existing JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once, after checking whether to jump. This would simplify the above code to just 421 JUMP_IF_FALSE_AND_POP 14 (to 438) 1178 ... >> 438 END_FINALLY This shortens bytecode by 5 bytes and both execution branches, by 1 and 2 commands correspondingly. I'm willing to create a patch, if this sounds like a worthwile improvement. Maybe it is better to skip 2.6 and target it for 3000 instead. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-08-01 23:24 Message: Logged In: YES user_id=80475 Originator: NO This was looked at and rejected long ago. The main reasons were that the new code would interfere with and complicate other byte code optimizations. Also, the need was mitigated almost entirely by the predict macros. ---------------------------------------------------------------------- Comment By: Paul Pogonyshev (doublep) Date: 2007-08-01 16:52 Message: Logged In: YES user_id=1203127 Originator: YES I have made first stab at this. It shows about 2% speedup on pystone, even though peephole optimizer does no related optimizations for new bytecodes yet. Note that having separate entries in ceval.c's switch() for the new bytecodes is essential. Perhaps because they are also used for prediction, not sure. File Added: new-bytecodes.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470 From noreply at sourceforge.net Thu Aug 2 06:25:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 21:25:51 -0700 Subject: [ python-Feature Requests-1726697 ] add operator.fst and snd functions Message-ID: Feature Requests item #1726697, was opened at 2007-05-27 22:49 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726697&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add operator.fst and snd functions Initial Comment: operator.itemgetter is a general but clumsy abstraction. Almost all the time when I use it, it's either to get the first or the second item of a tuple. I think that use case is common enough that it's worth including them in the operator module: fst = itemgetter(0) snd = itemgetter(1) I end up putting the above definitions in my programs very frequently and it would be nice if I could stop ;) fst and snd are mathematical names abbreviating "first" and "second" in some areas of math, like sin and cos abbreviate "sine" and "cosine". The names fst and snd are also used in Haskell and *ML. However, calling them "first" and "second" might be stylistically preferable to some Python users and would also be ok. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-27 23:49 Message: Logged In: YES user_id=80475 Originator: NO -1 That would provide too many ways to do it. It is more important to learn how to use one way correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1726697&group_id=5470 From noreply at sourceforge.net Thu Aug 2 06:26:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Aug 2007 21:26:56 -0700 Subject: [ python-Feature Requests-1728488 ] -q (quiet) option for python interpreter Message-ID: Feature Requests item #1728488, was opened at 2007-05-30 13:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: I'd like to suggest the new option for python: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. Why: I often use python as a calculator, for a couple-lines calculations, and would prefer to avoid having printed these three lines. There is a similar option in e.g. gdb. AFAICS the implementation would require small changes in Modules/main.c, Misc/python.man and probably in other docs. If it would be accepted, I can do it. Marcin ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-08-01 23:26 Message: Logged In: YES user_id=80475 Originator: NO +1 I think this would be nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 From noreply at sourceforge.net Thu Aug 2 11:15:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 02:15:08 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 00:19 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2007-08-02 11:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 02:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 19:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 19:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 07:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Thu Aug 2 13:42:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 04:42:46 -0700 Subject: [ python-Bugs-1764761 ] Decimal comparison with None fails in Windows Message-ID: Bugs item #1764761, was opened at 2007-07-31 13:34 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: pablohoffman.com (pablohoffman) >Assigned to: Facundo Batista (facundobatista) Summary: Decimal comparison with None fails in Windows Initial Comment: The version used to test this was: Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) In Linux: >>> from decimal import Decimal >>> Decimal('1') < None False >>> In Windows: >>> from decimal import Decimal >>> Decimal('1') < None True >>> This is probably a Windows bug since both platforms do: >>> 1 < None False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764761&group_id=5470 From noreply at sourceforge.net Thu Aug 2 21:54:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 12:54:04 -0700 Subject: [ python-Bugs-1766421 ] poll() returns "status code", not "return code" Message-ID: Bugs item #1766421, was opened at 2007-08-02 19: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=1766421&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: sjbrown (ezide_com) Assigned to: Nobody/Anonymous (nobody) Summary: poll() returns "status code", not "return code" Initial Comment: http://docs.python.org/lib/popen3-objects.html poll() documentation should say that it returns the "status code" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1766421&group_id=5470 From noreply at sourceforge.net Fri Aug 3 04:06:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 19:06:52 -0700 Subject: [ python-Feature Requests-1728488 ] -q (quiet) option for python interpreter Message-ID: Feature Requests item #1728488, was opened at 2007-05-31 00:14 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: I'd like to suggest the new option for python: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. Why: I often use python as a calculator, for a couple-lines calculations, and would prefer to avoid having printed these three lines. There is a similar option in e.g. gdb. AFAICS the implementation would require small changes in Modules/main.c, Misc/python.man and probably in other docs. If it would be accepted, I can do it. Marcin ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-03 07:36 Message: Logged In: YES user_id=942711 Originator: NO +1 for this option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-08-02 09:56 Message: Logged In: YES user_id=80475 Originator: NO +1 I think this would be nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 From noreply at sourceforge.net Fri Aug 3 04:59:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Aug 2007 19:59:41 -0700 Subject: [ python-Bugs-1764761 ] Decimal comparison with None fails in Windows Message-ID: Bugs item #1764761, was opened at 2007-07-31 13:34 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: pablohoffman.com (pablohoffman) Assigned to: Facundo Batista (facundobatista) Summary: Decimal comparison with None fails in Windows Initial Comment: The version used to test this was: Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) In Linux: >>> from decimal import Decimal >>> Decimal('1') < None False >>> In Windows: >>> from decimal import Decimal >>> Decimal('1') < None True >>> This is probably a Windows bug since both platforms do: >>> 1 < None False ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-08-02 23:59 Message: Logged In: YES user_id=752496 Originator: NO Solved, the problem was that __cmp__ was returning NotImplemented, which is not allowed (is not defined, that's why the different behaviour in different systems). The solution was commited in revision 56682, in the decimal branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764761&group_id=5470 From noreply at sourceforge.net Fri Aug 3 13:19:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 04:19:38 -0700 Subject: [ python-Bugs-1760423 ] No docs for list comparison Message-ID: Bugs item #1760423, was opened at 2007-07-25 15:39 Message generated for change (Comment added) made by m_n_summerfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: No docs for list comparison Initial Comment: AFAICT there is no documentation for the behaviour of <, > or == for sequences. == is perhaps obvious but it would be worth noting that < and > for lists and strings does a lexicographical comparison on the list elements or string characters. ---------------------------------------------------------------------- Comment By: Mark Summerfield (m_n_summerfield) Date: 2007-08-03 11:19 Message: Logged In: YES user_id=1856376 Originator: NO I've added a note plus a cross-reference to the comparisons coverage in the language reference. This won't appear until Python 2.6 though. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2007-07-27 12:52 Message: Logged In: YES user_id=49695 Originator: YES Yes, that is what I was looking for. It seems a strange place for the information. Could this be cross-referenced from the Library Reference? I never even thought to look for it in the Language Ref. Other list operations are documented in http://docs.python.org/lib/typesseq.html and this page discusses comparison of library types in general: http://docs.python.org/lib/comparisons.html I think it would be worth either repeating or linking to the information from the language ref on either of these pages. Thanks, Kent ---------------------------------------------------------------------- Comment By: Carsten Haese (chaese) Date: 2007-07-27 12:29 Message: Logged In: YES user_id=99003 Originator: NO http://docs.python.org/ref/comparisons.html works for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 From noreply at sourceforge.net Fri Aug 3 13:36:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 04:36:03 -0700 Subject: [ python-Bugs-1760423 ] No docs for list comparison Message-ID: Bugs item #1760423, was opened at 2007-07-25 15:39 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: No docs for list comparison Initial Comment: AFAICT there is no documentation for the behaviour of <, > or == for sequences. == is perhaps obvious but it would be worth noting that < and > for lists and strings does a lexicographical comparison on the list elements or string characters. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 11:36 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 56698. ---------------------------------------------------------------------- Comment By: Mark Summerfield (m_n_summerfield) Date: 2007-08-03 11:19 Message: Logged In: YES user_id=1856376 Originator: NO I've added a note plus a cross-reference to the comparisons coverage in the language reference. This won't appear until Python 2.6 though. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2007-07-27 12:52 Message: Logged In: YES user_id=49695 Originator: YES Yes, that is what I was looking for. It seems a strange place for the information. Could this be cross-referenced from the Library Reference? I never even thought to look for it in the Language Ref. Other list operations are documented in http://docs.python.org/lib/typesseq.html and this page discusses comparison of library types in general: http://docs.python.org/lib/comparisons.html I think it would be worth either repeating or linking to the information from the language ref on either of these pages. Thanks, Kent ---------------------------------------------------------------------- Comment By: Carsten Haese (chaese) Date: 2007-07-27 12:29 Message: Logged In: YES user_id=99003 Originator: NO http://docs.python.org/ref/comparisons.html works for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1760423&group_id=5470 From noreply at sourceforge.net Fri Aug 3 20:02:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 11:02:26 -0700 Subject: [ python-Bugs-1767242 ] os.chmod failure Message-ID: Bugs item #1767242, was opened at 2007-08-03 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=1767242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Heck (rgheck) Assigned to: Nobody/Anonymous (nobody) Summary: os.chmod failure Initial Comment: When running on Linux and accessing a FAT partition, os.chmod fails with otherwise sensible partitions: >>> os.chmod("/media/IHP-100/Test.lyx", 400) >>> os.chmod("/media/IHP-100/Test.lyx", 600) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx' The only thing that seems to be allowed is `4'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:14:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:14:31 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 19:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 10:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 15:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:26:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:26:27 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made threadsafe. To be truely threadsafe it also needs to make sure that _active contains only abandoned popen instances so that _cleanup() doesn't have it's inst.poll() calls collide with other threads that are still using those popen instances. This can be done by havin the popen instances added to _active only by Popen.__del__(), and only removed by _cleanup() when they are done. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 19:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 10:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 15:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:37:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:37:29 -0700 Subject: [ python-Bugs-1754642 ] subprocess.Popen.wait fails sporadically with threads Message-ID: Bugs item #1754642, was opened at 2007-07-16 19:26 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1754642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Geoffrey Bache (gjb1002) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen.wait fails sporadically with threads Initial Comment: When several threads are using the subprocess module I occasionally get stack traces that look like out, err = process.communicate() File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes See the fixed bug at https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 The problem I am observing seems to match the one described there in the "related modules" part. After discovering that bug, I downloaded the test program attached to it and discovered that I got the errors described from time to time. I am using Python 2.4.3 on Red Hat EL4 and Python 2.4.4 on Red Hat EL3, and both have this error. I reattach my tweaked version of that test program. The only basic difference is that testing subprocess is the default option and the default number of threads increased to 50 as this seemed to mean it occurred more often. I have reproduced the original popen2 problem once on Python 2.4.4 but it's much more infrequent, and not a problem in practice for me. See the comment at the top of that script for details of expected behaviour etc. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-16 19:32 Message: Logged In: YES user_id=769182 Originator: YES Hmm, seems someone else reported this during the weekend. Looks rather similar to bug 1753891... I let someone else mark as duplicate if they want. Can't harm to have two different test programs for an indeterministic problem :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1754642&group_id=5470 From noreply at sourceforge.net Fri Aug 3 21:37:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 12:37:37 -0700 Subject: [ python-Bugs-1753891 ] subprocess raising "No Child Process" OSError Message-ID: Bugs item #1753891, was opened at 2007-07-14 13:06 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: slowfood (slowfood) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess raising "No Child Process" OSError Initial Comment: The program below demostrates a "No Child Process" OSError on a multi-cpu systems. This is extracted from a large system where we are trying to manage many sub-processes, some of which end up having little/no real work to do so they return very fast, here emulated by having the sub-process be an invocation of: Executable="/bin/sleep 0" Seems like some race condition, since if you make the child process take some time (sleep 0.1) the frequency of errors decreeses. Error only shows up when there are more threads than have real CPU's by at least a factor of two, on dual core machines up NumThreads to 18 to get the failures. Same error on both Python 2.4.3 with: Linux 2.6.18-gentoo-r3 Gentoo and Python 2.4.4 with: Linux 2.6.20-gentoo-r8 Any help appreciated - = = = ===== Start code example =========== % python subprocess_noChildErr.py Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "testCaseA.py", line 14, in run subprocess.call(Executable.split()) File "/usr/lib64/python2.4/subprocess.py", line 413, in call return Popen(*args, **kwargs).wait() File "/usr/lib64/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Test finished % cat subprocess_noChildErr.py import subprocess, threading # Params Executable="/bin/sleep 0" NumThreads = 18 NumIterations = 10 class TestClass(threading.Thread): def __init__(self, threadNum): self.threadNum = threadNum threading.Thread.__init__(self) def run(self): for i in range(NumIterations): subprocess.call(Executable.split()) def test(): allThreads = [] for i in range(NumThreads): allThreads.append(TestClass(i)) for i in range(NumThreads): allThreads[i].start() for i in range(NumThreads): allThreads[i].join() print "Test finished" if __name__ == '__main__': test() % python -V Python 2.4.4 % uname -a Linux 2.6.20-gentoo-r8 #2 SMP PREEMPT Sun Jul 1 13:22:56 PDT 2007 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux % % date Fri Jul 13 19:26:44 PDT 2007 % = = = ===== End code example =========== ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:01:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:01:16 -0700 Subject: [ python-Bugs-1753891 ] subprocess raising "No Child Process" OSError Message-ID: Bugs item #1753891, was opened at 2007-07-13 20:06 Message generated for change (Comment added) made by slowfood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open >Resolution: Duplicate Priority: 5 Private: No Submitted By: slowfood (slowfood) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess raising "No Child Process" OSError Initial Comment: The program below demostrates a "No Child Process" OSError on a multi-cpu systems. This is extracted from a large system where we are trying to manage many sub-processes, some of which end up having little/no real work to do so they return very fast, here emulated by having the sub-process be an invocation of: Executable="/bin/sleep 0" Seems like some race condition, since if you make the child process take some time (sleep 0.1) the frequency of errors decreeses. Error only shows up when there are more threads than have real CPU's by at least a factor of two, on dual core machines up NumThreads to 18 to get the failures. Same error on both Python 2.4.3 with: Linux 2.6.18-gentoo-r3 Gentoo and Python 2.4.4 with: Linux 2.6.20-gentoo-r8 Any help appreciated - = = = ===== Start code example =========== % python subprocess_noChildErr.py Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "testCaseA.py", line 14, in run subprocess.call(Executable.split()) File "/usr/lib64/python2.4/subprocess.py", line 413, in call return Popen(*args, **kwargs).wait() File "/usr/lib64/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Test finished % cat subprocess_noChildErr.py import subprocess, threading # Params Executable="/bin/sleep 0" NumThreads = 18 NumIterations = 10 class TestClass(threading.Thread): def __init__(self, threadNum): self.threadNum = threadNum threading.Thread.__init__(self) def run(self): for i in range(NumIterations): subprocess.call(Executable.split()) def test(): allThreads = [] for i in range(NumThreads): allThreads.append(TestClass(i)) for i in range(NumThreads): allThreads[i].start() for i in range(NumThreads): allThreads[i].join() print "Test finished" if __name__ == '__main__': test() % python -V Python 2.4.4 % uname -a Linux 2.6.20-gentoo-r8 #2 SMP PREEMPT Sun Jul 1 13:22:56 PDT 2007 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux % % date Fri Jul 13 19:26:44 PDT 2007 % = = = ===== End code example =========== ---------------------------------------------------------------------- >Comment By: slowfood (slowfood) Date: 2007-08-03 13:01 Message: Logged In: YES user_id=1844537 Originator: YES I agree with abo that this looks to be a dup of 1731717, will try to mark it as such. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 12:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:07:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:07:55 -0700 Subject: [ python-Bugs-1753891 ] subprocess raising "No Child Process" OSError Message-ID: Bugs item #1753891, was opened at 2007-07-13 20:06 Message generated for change (Comment added) made by slowfood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Private: No Submitted By: slowfood (slowfood) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess raising "No Child Process" OSError Initial Comment: The program below demostrates a "No Child Process" OSError on a multi-cpu systems. This is extracted from a large system where we are trying to manage many sub-processes, some of which end up having little/no real work to do so they return very fast, here emulated by having the sub-process be an invocation of: Executable="/bin/sleep 0" Seems like some race condition, since if you make the child process take some time (sleep 0.1) the frequency of errors decreeses. Error only shows up when there are more threads than have real CPU's by at least a factor of two, on dual core machines up NumThreads to 18 to get the failures. Same error on both Python 2.4.3 with: Linux 2.6.18-gentoo-r3 Gentoo and Python 2.4.4 with: Linux 2.6.20-gentoo-r8 Any help appreciated - = = = ===== Start code example =========== % python subprocess_noChildErr.py Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "testCaseA.py", line 14, in run subprocess.call(Executable.split()) File "/usr/lib64/python2.4/subprocess.py", line 413, in call return Popen(*args, **kwargs).wait() File "/usr/lib64/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Test finished % cat subprocess_noChildErr.py import subprocess, threading # Params Executable="/bin/sleep 0" NumThreads = 18 NumIterations = 10 class TestClass(threading.Thread): def __init__(self, threadNum): self.threadNum = threadNum threading.Thread.__init__(self) def run(self): for i in range(NumIterations): subprocess.call(Executable.split()) def test(): allThreads = [] for i in range(NumThreads): allThreads.append(TestClass(i)) for i in range(NumThreads): allThreads[i].start() for i in range(NumThreads): allThreads[i].join() print "Test finished" if __name__ == '__main__': test() % python -V Python 2.4.4 % uname -a Linux 2.6.20-gentoo-r8 #2 SMP PREEMPT Sun Jul 1 13:22:56 PDT 2007 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux % % date Fri Jul 13 19:26:44 PDT 2007 % = = = ===== End code example =========== ---------------------------------------------------------------------- >Comment By: slowfood (slowfood) Date: 2007-08-03 13:07 Message: Logged In: YES user_id=1844537 Originator: YES Managed to mark it as a duplicate, but not able to tie it to 1731717. Sorry - ;;slowfood ---------------------------------------------------------------------- Comment By: slowfood (slowfood) Date: 2007-08-03 13:01 Message: Logged In: YES user_id=1844537 Originator: YES I agree with abo that this looks to be a dup of 1731717, will try to mark it as such. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 12:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:11:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:11:57 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-05 18:19 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 16:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 15:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made threadsafe. To be truely threadsafe it also needs to make sure that _active contains only abandoned popen instances so that _cleanup() doesn't have it's inst.poll() calls collide with other threads that are still using those popen instances. This can be done by havin the popen instances added to _active only by Popen.__del__(), and only removed by _cleanup() when they are done. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 15:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 05:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-01 20:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 13:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 13:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 01:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:25:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:25:45 -0700 Subject: [ python-Bugs-1767242 ] os.chmod failure Message-ID: Bugs item #1767242, was opened at 2007-08-03 18:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Richard Heck (rgheck) Assigned to: Nobody/Anonymous (nobody) Summary: os.chmod failure Initial Comment: When running on Linux and accessing a FAT partition, os.chmod fails with otherwise sensible partitions: >>> os.chmod("/media/IHP-100/Test.lyx", 400) >>> os.chmod("/media/IHP-100/Test.lyx", 600) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx' The only thing that seems to be allowed is `4'. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 20:25 Message: Logged In: YES user_id=849994 Originator: NO Why do you think this is Python's fault? os.chmod() is only a very thin wrapper around the OS' chmod(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:26:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:26:16 -0700 Subject: [ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns Message-ID: Bugs item #1762972, was opened at 2007-07-28 23:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) >Assigned to: Guido van Rossum (gvanrossum) Summary: 'exec' does not accept what 'open' returns Initial Comment: Since the move over to io.py 'exec' no longer accepts what 'open' returns. Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 16:26 Message: Logged In: YES user_id=6380 Originator: NO Arguably we don't need this feature any more. The only reasonable way to implement it would be to slurp the entire contents of the file into a string and then exec that. The caller might as well do this. Alternatively one could use execfile() (which takes a filename instead of a stream). The only advantage of using exec() might be that it would deal with encoding declarations transparantly; but we should probably have a way to handle those somewhere in the library anyway, as it's also necessary for other tools (e.g. modulefinder.py, pyclbr.py and linecache.py). Alternatively I'm not so sure that we will need to support encoding declarations forever -- I'm hoping that at some point UTF-8 and BOM+UTF-16 will take over the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:37:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:37:31 -0700 Subject: [ python-Bugs-1753395 ] struni: assertion in Windows debug build Message-ID: Bugs item #1753395, was opened at 2007-07-13 07:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: struni: assertion in Windows debug build Initial Comment: When running Lib/test/test_descr.py with a Windows debug build, I get an assertion in the MS runtime lib, in the isalpha(*p) call, file typeobject.c, line 1582. The value of '*p' at the time of the call is 4660. The assertion reported is: File: istype.c Line: 68 Expression; (unsigned)(c + 1) <= 256 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 16:37 Message: Logged In: YES user_id=6380 Originator: NO I wonder if the test "i > 255" wasn't meant to be "*p > 255"? Please try that, and submit if it works. Looks like Walter Doerwald introduced this bug in r55892. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 From noreply at sourceforge.net Fri Aug 3 22:39:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 13:39:07 -0700 Subject: [ python-Bugs-1767242 ] os.chmod failure Message-ID: Bugs item #1767242, was opened at 2007-08-03 14:02 Message generated for change (Comment added) made by rgheck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Heck (rgheck) Assigned to: Nobody/Anonymous (nobody) Summary: os.chmod failure Initial Comment: When running on Linux and accessing a FAT partition, os.chmod fails with otherwise sensible partitions: >>> os.chmod("/media/IHP-100/Test.lyx", 400) >>> os.chmod("/media/IHP-100/Test.lyx", 600) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx' The only thing that seems to be allowed is `4'. ---------------------------------------------------------------------- >Comment By: Richard Heck (rgheck) Date: 2007-08-03 16:39 Message: Logged In: YES user_id=1072146 Originator: YES Well, the shell's chmod doesn't return an error. [rgheck at rghstudy scripts]$ chmod 600 /media/IHP-100/Test.lyx [rgheck at rghstudy scripts]$ echo $? 0 [rgheck at rghstudy scripts]$ chmod 400 /media/IHP-100/Test.lyx [rgheck at rghstudy scripts]$ echo $? 0 [rgheck at rghstudy scripts]$ chmod 700 /media/IHP-100/Test.lyx [rgheck at rghstudy scripts]$ echo $? 0 [rgheck at rghstudy scripts]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:00) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.chmod("/media/IHP-100/Test.lyx", 400) >>> os.chmod("/media/IHP-100/Test.lyx", 600) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx' I don't know what would happen in C, say. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 16:25 Message: Logged In: YES user_id=849994 Originator: NO Why do you think this is Python's fault? os.chmod() is only a very thin wrapper around the OS' chmod(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 From noreply at sourceforge.net Fri Aug 3 23:09:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 14:09:50 -0700 Subject: [ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns Message-ID: Bugs item #1762972, was opened at 2007-07-28 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: 'exec' does not accept what 'open' returns Initial Comment: Since the move over to io.py 'exec' no longer accepts what 'open' returns. Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-08-03 14:09 Message: Logged In: YES user_id=357491 Originator: YES I am fine with ditching the feature and forcing people to deal with the encoding issues externally to 'exec', although as you pointed out dealing with any -*- encoding marker might be a pain without some library help (although doesn't the parser pick up on this and handle those nasty details?). As for execfile, PEP 3100 has it listed for removal in favour of moving people over to using 'exec'. The main thing is trying to come up with an easy solution for replacing 'reload' with a reasonable one-liner when debugging at the interpreter. And yes, I hope encoding declarations can go away and the world either lives with just UTF-8 or BOM+UTF-16 (I really wish we could just require this for all Python source files and start towards this, but I know some people would flip out over that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 13:26 Message: Logged In: YES user_id=6380 Originator: NO Arguably we don't need this feature any more. The only reasonable way to implement it would be to slurp the entire contents of the file into a string and then exec that. The caller might as well do this. Alternatively one could use execfile() (which takes a filename instead of a stream). The only advantage of using exec() might be that it would deal with encoding declarations transparantly; but we should probably have a way to handle those somewhere in the library anyway, as it's also necessary for other tools (e.g. modulefinder.py, pyclbr.py and linecache.py). Alternatively I'm not so sure that we will need to support encoding declarations forever -- I'm hoping that at some point UTF-8 and BOM+UTF-16 will take over the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 From noreply at sourceforge.net Fri Aug 3 23:14:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 14:14:42 -0700 Subject: [ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns Message-ID: Bugs item #1762972, was opened at 2007-07-28 23:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: 'exec' does not accept what 'open' returns Initial Comment: Since the move over to io.py 'exec' no longer accepts what 'open' returns. Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 17:14 Message: Logged In: YES user_id=6380 Originator: NO OK, let's ditch it (i.e. status quo) and also ditch execfile. The one-liner you're looking for is *almost* exec(open(M.__file__).read(), M.__dict__) (where M stands for any already imported module), except for the nastiness that if m.__file__ ends with .pyc or .pyo you'd have to strip the last character. (And to do this right you'd need help from the imp module because those extensions may vary by platform -- e.g. I know of a company that patches their Pythons to use .pyc24.) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-08-03 17:09 Message: Logged In: YES user_id=357491 Originator: YES I am fine with ditching the feature and forcing people to deal with the encoding issues externally to 'exec', although as you pointed out dealing with any -*- encoding marker might be a pain without some library help (although doesn't the parser pick up on this and handle those nasty details?). As for execfile, PEP 3100 has it listed for removal in favour of moving people over to using 'exec'. The main thing is trying to come up with an easy solution for replacing 'reload' with a reasonable one-liner when debugging at the interpreter. And yes, I hope encoding declarations can go away and the world either lives with just UTF-8 or BOM+UTF-16 (I really wish we could just require this for all Python source files and start towards this, but I know some people would flip out over that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 16:26 Message: Logged In: YES user_id=6380 Originator: NO Arguably we don't need this feature any more. The only reasonable way to implement it would be to slurp the entire contents of the file into a string and then exec that. The caller might as well do this. Alternatively one could use execfile() (which takes a filename instead of a stream). The only advantage of using exec() might be that it would deal with encoding declarations transparantly; but we should probably have a way to handle those somewhere in the library anyway, as it's also necessary for other tools (e.g. modulefinder.py, pyclbr.py and linecache.py). Alternatively I'm not so sure that we will need to support encoding declarations forever -- I'm hoping that at some point UTF-8 and BOM+UTF-16 will take over the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 From noreply at sourceforge.net Fri Aug 3 23:29:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 14:29:41 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 07:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much "thread safe" as "thread robust". I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back if it is still not finished. However, as it is now it looks like it is fixed... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-04 06:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made threadsafe. To be truely threadsafe it also needs to make sure that _active contains only abandoned popen instances so that _cleanup() doesn't have it's inst.poll() calls collide with other threads that are still using those popen instances. This can be done by havin the popen instances added to _active only by Popen.__del__(), and only removed by _cleanup() when they are done. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 19:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 10:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 15:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Fri Aug 3 23:42:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 14:42:31 -0700 Subject: [ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns Message-ID: Bugs item #1762972, was opened at 2007-07-28 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: 'exec' does not accept what 'open' returns Initial Comment: Since the move over to io.py 'exec' no longer accepts what 'open' returns. Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-08-03 14:42 Message: Logged In: YES user_id=357491 Originator: YES Hrm. Well then we can either add something like __source_file__ to modules, put 'reload' into the imp module (or on module objects as a method), or have a function in imp (or as a method on modules) that returns the source path (if it exists). But having to do:: M.__file__.rsplit('.', 1) + filter((lambda x : x[2] == imp.PY_SOURCE), imp.get_suffixes())[0] seems like a lot to memorize (let alone type in), especially since there is even no error checking that the path is even to a source or bytecode file to start with or that you end up with. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 14:14 Message: Logged In: YES user_id=6380 Originator: NO OK, let's ditch it (i.e. status quo) and also ditch execfile. The one-liner you're looking for is *almost* exec(open(M.__file__).read(), M.__dict__) (where M stands for any already imported module), except for the nastiness that if m.__file__ ends with .pyc or .pyo you'd have to strip the last character. (And to do this right you'd need help from the imp module because those extensions may vary by platform -- e.g. I know of a company that patches their Pythons to use .pyc24.) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-08-03 14:09 Message: Logged In: YES user_id=357491 Originator: YES I am fine with ditching the feature and forcing people to deal with the encoding issues externally to 'exec', although as you pointed out dealing with any -*- encoding marker might be a pain without some library help (although doesn't the parser pick up on this and handle those nasty details?). As for execfile, PEP 3100 has it listed for removal in favour of moving people over to using 'exec'. The main thing is trying to come up with an easy solution for replacing 'reload' with a reasonable one-liner when debugging at the interpreter. And yes, I hope encoding declarations can go away and the world either lives with just UTF-8 or BOM+UTF-16 (I really wish we could just require this for all Python source files and start towards this, but I know some people would flip out over that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 13:26 Message: Logged In: YES user_id=6380 Originator: NO Arguably we don't need this feature any more. The only reasonable way to implement it would be to slurp the entire contents of the file into a string and then exec that. The caller might as well do this. Alternatively one could use execfile() (which takes a filename instead of a stream). The only advantage of using exec() might be that it would deal with encoding declarations transparantly; but we should probably have a way to handle those somewhere in the library anyway, as it's also necessary for other tools (e.g. modulefinder.py, pyclbr.py and linecache.py). Alternatively I'm not so sure that we will need to support encoding declarations forever -- I'm hoping that at some point UTF-8 and BOM+UTF-16 will take over the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 From noreply at sourceforge.net Fri Aug 3 23:53:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 14:53:08 -0700 Subject: [ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns Message-ID: Bugs item #1762972, was opened at 2007-07-28 23:24 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: 'exec' does not accept what 'open' returns Initial Comment: Since the move over to io.py 'exec' no longer accepts what 'open' returns. Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 17:53 Message: Logged In: YES user_id=6380 Originator: NO Or we can change the semantics of __file__ to always point to the source file. I think that's acceptable behavior -- the current behavior seems more of a pain than necessary. I also think that adding imp.reload() makes sense; I was just saying yesterday to a few fellow-Googler-Python-developers that I was already missing reload(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-08-03 17:42 Message: Logged In: YES user_id=357491 Originator: YES Hrm. Well then we can either add something like __source_file__ to modules, put 'reload' into the imp module (or on module objects as a method), or have a function in imp (or as a method on modules) that returns the source path (if it exists). But having to do:: M.__file__.rsplit('.', 1) + filter((lambda x : x[2] == imp.PY_SOURCE), imp.get_suffixes())[0] seems like a lot to memorize (let alone type in), especially since there is even no error checking that the path is even to a source or bytecode file to start with or that you end up with. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 17:14 Message: Logged In: YES user_id=6380 Originator: NO OK, let's ditch it (i.e. status quo) and also ditch execfile. The one-liner you're looking for is *almost* exec(open(M.__file__).read(), M.__dict__) (where M stands for any already imported module), except for the nastiness that if m.__file__ ends with .pyc or .pyo you'd have to strip the last character. (And to do this right you'd need help from the imp module because those extensions may vary by platform -- e.g. I know of a company that patches their Pythons to use .pyc24.) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-08-03 17:09 Message: Logged In: YES user_id=357491 Originator: YES I am fine with ditching the feature and forcing people to deal with the encoding issues externally to 'exec', although as you pointed out dealing with any -*- encoding marker might be a pain without some library help (although doesn't the parser pick up on this and handle those nasty details?). As for execfile, PEP 3100 has it listed for removal in favour of moving people over to using 'exec'. The main thing is trying to come up with an easy solution for replacing 'reload' with a reasonable one-liner when debugging at the interpreter. And yes, I hope encoding declarations can go away and the world either lives with just UTF-8 or BOM+UTF-16 (I really wish we could just require this for all Python source files and start towards this, but I know some people would flip out over that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 16:26 Message: Logged In: YES user_id=6380 Originator: NO Arguably we don't need this feature any more. The only reasonable way to implement it would be to slurp the entire contents of the file into a string and then exec that. The caller might as well do this. Alternatively one could use execfile() (which takes a filename instead of a stream). The only advantage of using exec() might be that it would deal with encoding declarations transparantly; but we should probably have a way to handle those somewhere in the library anyway, as it's also necessary for other tools (e.g. modulefinder.py, pyclbr.py and linecache.py). Alternatively I'm not so sure that we will need to support encoding declarations forever -- I'm hoping that at some point UTF-8 and BOM+UTF-16 will take over the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 From noreply at sourceforge.net Sat Aug 4 00:48:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 15:48:45 -0700 Subject: [ python-Bugs-1767363 ] String.capwords() does not capitalize first word Message-ID: Bugs item #1767363, was opened at 2007-08-03 15:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Saatvik Agarwal (saatvik) Assigned to: Nobody/Anonymous (nobody) Summary: String.capwords() does not capitalize first word Initial Comment: Perhaps not the right category...nothing major but I noticed that string.capwords does not capitalize the first character of the first word of the string. Email: legolas at stanford.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767363&group_id=5470 From noreply at sourceforge.net Sat Aug 4 00:50:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 15:50:00 -0700 Subject: [ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns Message-ID: Bugs item #1762972, was opened at 2007-07-28 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: 'exec' does not accept what 'open' returns Initial Comment: Since the move over to io.py 'exec' no longer accepts what 'open' returns. Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-08-03 15:50 Message: Logged In: YES user_id=357491 Originator: YES Agreed on both, although what to do when there is no source but only bytecode? Just say that __file__ will point to the source if available, otherwise to the bytecode? That seems reasonable to me. And imp.reload sounds good. This whole bug report started because 'reload' was gone and I was trying to figure out the best way to replace its loss. I know I am short on time and thus have no clue if I can help on these. Should we add these to PEP 3100 so we don't forget, or do you think you might get to this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 14:53 Message: Logged In: YES user_id=6380 Originator: NO Or we can change the semantics of __file__ to always point to the source file. I think that's acceptable behavior -- the current behavior seems more of a pain than necessary. I also think that adding imp.reload() makes sense; I was just saying yesterday to a few fellow-Googler-Python-developers that I was already missing reload(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-08-03 14:42 Message: Logged In: YES user_id=357491 Originator: YES Hrm. Well then we can either add something like __source_file__ to modules, put 'reload' into the imp module (or on module objects as a method), or have a function in imp (or as a method on modules) that returns the source path (if it exists). But having to do:: M.__file__.rsplit('.', 1) + filter((lambda x : x[2] == imp.PY_SOURCE), imp.get_suffixes())[0] seems like a lot to memorize (let alone type in), especially since there is even no error checking that the path is even to a source or bytecode file to start with or that you end up with. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 14:14 Message: Logged In: YES user_id=6380 Originator: NO OK, let's ditch it (i.e. status quo) and also ditch execfile. The one-liner you're looking for is *almost* exec(open(M.__file__).read(), M.__dict__) (where M stands for any already imported module), except for the nastiness that if m.__file__ ends with .pyc or .pyo you'd have to strip the last character. (And to do this right you'd need help from the imp module because those extensions may vary by platform -- e.g. I know of a company that patches their Pythons to use .pyc24.) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-08-03 14:09 Message: Logged In: YES user_id=357491 Originator: YES I am fine with ditching the feature and forcing people to deal with the encoding issues externally to 'exec', although as you pointed out dealing with any -*- encoding marker might be a pain without some library help (although doesn't the parser pick up on this and handle those nasty details?). As for execfile, PEP 3100 has it listed for removal in favour of moving people over to using 'exec'. The main thing is trying to come up with an easy solution for replacing 'reload' with a reasonable one-liner when debugging at the interpreter. And yes, I hope encoding declarations can go away and the world either lives with just UTF-8 or BOM+UTF-16 (I really wish we could just require this for all Python source files and start towards this, but I know some people would flip out over that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 13:26 Message: Logged In: YES user_id=6380 Originator: NO Arguably we don't need this feature any more. The only reasonable way to implement it would be to slurp the entire contents of the file into a string and then exec that. The caller might as well do this. Alternatively one could use execfile() (which takes a filename instead of a stream). The only advantage of using exec() might be that it would deal with encoding declarations transparantly; but we should probably have a way to handle those somewhere in the library anyway, as it's also necessary for other tools (e.g. modulefinder.py, pyclbr.py and linecache.py). Alternatively I'm not so sure that we will need to support encoding declarations forever -- I'm hoping that at some point UTF-8 and BOM+UTF-16 will take over the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470 From noreply at sourceforge.net Sat Aug 4 01:09:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 16:09:05 -0700 Subject: [ python-Bugs-1767363 ] String.capwords() does not capitalize first word Message-ID: Bugs item #1767363, was opened at 2007-08-03 15:48 Message generated for change (Settings changed) made by saatvik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open >Resolution: Invalid Priority: 5 Private: No Submitted By: Saatvik Agarwal (saatvik) Assigned to: Nobody/Anonymous (nobody) Summary: String.capwords() does not capitalize first word Initial Comment: Perhaps not the right category...nothing major but I noticed that string.capwords does not capitalize the first character of the first word of the string. Email: legolas at stanford.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767363&group_id=5470 From noreply at sourceforge.net Sat Aug 4 08:50:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Aug 2007 23:50:20 -0700 Subject: [ python-Bugs-1767363 ] String.capwords() does not capitalize first word Message-ID: Bugs item #1767363, was opened at 2007-08-03 22:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Saatvik Agarwal (saatvik) Assigned to: Nobody/Anonymous (nobody) Summary: String.capwords() does not capitalize first word Initial Comment: Perhaps not the right category...nothing major but I noticed that string.capwords does not capitalize the first character of the first word of the string. Email: legolas at stanford.edu ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-04 06:50 Message: Logged In: YES user_id=849994 Originator: NO Note that for byte strings, only letters in [a-z] will be correctly upcased. If you want it to handle arbitrary letters correctly, use unicode strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767363&group_id=5470 From noreply at sourceforge.net Sat Aug 4 09:24:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 00:24:23 -0700 Subject: [ python-Bugs-1754642 ] subprocess.Popen.wait fails sporadically with threads Message-ID: Bugs item #1754642, was opened at 2007-07-16 09:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1754642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Geoffrey Bache (gjb1002) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen.wait fails sporadically with threads Initial Comment: When several threads are using the subprocess module I occasionally get stack traces that look like out, err = process.communicate() File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes See the fixed bug at https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 The problem I am observing seems to match the one described there in the "related modules" part. After discovering that bug, I downloaded the test program attached to it and discovered that I got the errors described from time to time. I am using Python 2.4.3 on Red Hat EL4 and Python 2.4.4 on Red Hat EL3, and both have this error. I reattach my tweaked version of that test program. The only basic difference is that testing subprocess is the default option and the default number of threads increased to 50 as this seemed to mean it occurred more often. I have reproduced the original popen2 problem once on Python 2.4.4 but it's much more infrequent, and not a problem in practice for me. See the comment at the top of that script for details of expected behaviour etc. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-04 07:24 Message: Logged In: YES user_id=849994 Originator: NO Duplicate of #1731717. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 19:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-16 09:32 Message: Logged In: YES user_id=769182 Originator: YES Hmm, seems someone else reported this during the weekend. Looks rather similar to bug 1753891... I let someone else mark as duplicate if they want. Can't harm to have two different test programs for an indeterministic problem :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1754642&group_id=5470 From noreply at sourceforge.net Sat Aug 4 09:25:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 00:25:32 -0700 Subject: [ python-Bugs-1753891 ] subprocess raising "No Child Process" OSError Message-ID: Bugs item #1753891, was opened at 2007-07-14 03:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: Duplicate Priority: 5 Private: No Submitted By: slowfood (slowfood) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess raising "No Child Process" OSError Initial Comment: The program below demostrates a "No Child Process" OSError on a multi-cpu systems. This is extracted from a large system where we are trying to manage many sub-processes, some of which end up having little/no real work to do so they return very fast, here emulated by having the sub-process be an invocation of: Executable="/bin/sleep 0" Seems like some race condition, since if you make the child process take some time (sleep 0.1) the frequency of errors decreeses. Error only shows up when there are more threads than have real CPU's by at least a factor of two, on dual core machines up NumThreads to 18 to get the failures. Same error on both Python 2.4.3 with: Linux 2.6.18-gentoo-r3 Gentoo and Python 2.4.4 with: Linux 2.6.20-gentoo-r8 Any help appreciated - = = = ===== Start code example =========== % python subprocess_noChildErr.py Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "testCaseA.py", line 14, in run subprocess.call(Executable.split()) File "/usr/lib64/python2.4/subprocess.py", line 413, in call return Popen(*args, **kwargs).wait() File "/usr/lib64/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Test finished % cat subprocess_noChildErr.py import subprocess, threading # Params Executable="/bin/sleep 0" NumThreads = 18 NumIterations = 10 class TestClass(threading.Thread): def __init__(self, threadNum): self.threadNum = threadNum threading.Thread.__init__(self) def run(self): for i in range(NumIterations): subprocess.call(Executable.split()) def test(): allThreads = [] for i in range(NumThreads): allThreads.append(TestClass(i)) for i in range(NumThreads): allThreads[i].start() for i in range(NumThreads): allThreads[i].join() print "Test finished" if __name__ == '__main__': test() % python -V Python 2.4.4 % uname -a Linux 2.6.20-gentoo-r8 #2 SMP PREEMPT Sun Jul 1 13:22:56 PDT 2007 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux % % date Fri Jul 13 19:26:44 PDT 2007 % = = = ===== End code example =========== ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-04 07:25 Message: Logged In: YES user_id=849994 Originator: NO Closing too. Tying bugs is not supported by SF. ---------------------------------------------------------------------- Comment By: slowfood (slowfood) Date: 2007-08-03 20:07 Message: Logged In: YES user_id=1844537 Originator: YES Managed to mark it as a duplicate, but not able to tie it to 1731717. Sorry - ;;slowfood ---------------------------------------------------------------------- Comment By: slowfood (slowfood) Date: 2007-08-03 20:01 Message: Logged In: YES user_id=1844537 Originator: YES I agree with abo that this looks to be a dup of 1731717, will try to mark it as such. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 19:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 From noreply at sourceforge.net Sat Aug 4 09:26:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 00:26:20 -0700 Subject: [ python-Bugs-1753891 ] subprocess raising "No Child Process" OSError Message-ID: Bugs item #1753891, was opened at 2007-07-14 03:06 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 >Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: slowfood (slowfood) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess raising "No Child Process" OSError Initial Comment: The program below demostrates a "No Child Process" OSError on a multi-cpu systems. This is extracted from a large system where we are trying to manage many sub-processes, some of which end up having little/no real work to do so they return very fast, here emulated by having the sub-process be an invocation of: Executable="/bin/sleep 0" Seems like some race condition, since if you make the child process take some time (sleep 0.1) the frequency of errors decreeses. Error only shows up when there are more threads than have real CPU's by at least a factor of two, on dual core machines up NumThreads to 18 to get the failures. Same error on both Python 2.4.3 with: Linux 2.6.18-gentoo-r3 Gentoo and Python 2.4.4 with: Linux 2.6.20-gentoo-r8 Any help appreciated - = = = ===== Start code example =========== % python subprocess_noChildErr.py Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "testCaseA.py", line 14, in run subprocess.call(Executable.split()) File "/usr/lib64/python2.4/subprocess.py", line 413, in call return Popen(*args, **kwargs).wait() File "/usr/lib64/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Test finished % cat subprocess_noChildErr.py import subprocess, threading # Params Executable="/bin/sleep 0" NumThreads = 18 NumIterations = 10 class TestClass(threading.Thread): def __init__(self, threadNum): self.threadNum = threadNum threading.Thread.__init__(self) def run(self): for i in range(NumIterations): subprocess.call(Executable.split()) def test(): allThreads = [] for i in range(NumThreads): allThreads.append(TestClass(i)) for i in range(NumThreads): allThreads[i].start() for i in range(NumThreads): allThreads[i].join() print "Test finished" if __name__ == '__main__': test() % python -V Python 2.4.4 % uname -a Linux 2.6.20-gentoo-r8 #2 SMP PREEMPT Sun Jul 1 13:22:56 PDT 2007 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux % % date Fri Jul 13 19:26:44 PDT 2007 % = = = ===== End code example =========== ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-04 07:25 Message: Logged In: YES user_id=849994 Originator: NO Closing too. Tying bugs is not supported by SF. ---------------------------------------------------------------------- Comment By: slowfood (slowfood) Date: 2007-08-03 20:07 Message: Logged In: YES user_id=1844537 Originator: YES Managed to mark it as a duplicate, but not able to tie it to 1731717. Sorry - ;;slowfood ---------------------------------------------------------------------- Comment By: slowfood (slowfood) Date: 2007-08-03 20:01 Message: Logged In: YES user_id=1844537 Originator: YES I agree with abo that this looks to be a dup of 1731717, will try to mark it as such. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 19:37 Message: Logged In: YES user_id=10273 Originator: NO Bugs 1754642 and 1753891 both look like duplicates of bug 1731717 to me. I suggest marking them both as dups of 1731717 because that one has info on the race-condition that causes this and discussions on how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753891&group_id=5470 From noreply at sourceforge.net Sat Aug 4 09:42:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 00:42:10 -0700 Subject: [ python-Bugs-1753395 ] struni: assertion in Windows debug build Message-ID: Bugs item #1753395, was opened at 2007-07-13 13:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: struni: assertion in Windows debug build Initial Comment: When running Lib/test/test_descr.py with a Windows debug build, I get an assertion in the MS runtime lib, in the isalpha(*p) call, file typeobject.c, line 1582. The value of '*p' at the time of the call is 4660. The assertion reported is: File: istype.c Line: 68 Expression; (unsigned)(c + 1) <= 256 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-08-04 09:42 Message: Logged In: YES user_id=89016 Originator: NO Right, this should have been *p > 255, even better would be *p > 127. Thomas, can you try that on Windows? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 22:37 Message: Logged In: YES user_id=6380 Originator: NO I wonder if the test "i > 255" wasn't meant to be "*p > 255"? Please try that, and submit if it works. Looks like Walter Doerwald introduced this bug in r55892. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 From noreply at sourceforge.net Sat Aug 4 11:21:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 02:21:27 -0700 Subject: [ python-Bugs-1767511 ] SocketServer.DatagramRequestHandler Message-ID: Bugs item #1767511, was opened at 2007-08-04 11: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=1767511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alzheimer (alzheimer) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.DatagramRequestHandler Initial Comment: I seem to have misunderstood SocketServer completely, maybe someone can tell me if I was using the wrong thing after all. I wanted to implement an UDP protocol in Python. For sending and receiving UDP packets, I chose SocketServer.UDPSocketServer along with the DatagramRequestHandler. It is probably implied, but did not become clear to me just by reading the documentation, that apparently a server is meant to send back a packet for every packet it receives, no matter what. Which in turn means that you can't have servers talk to other servers, because they'd be sending packets back and forth endlessly then. At least, that's what the DatagramRequestHandler is doing. It issues a socket.sendto in its finish() routine. Took me a while to find out where all the empty packets where coming from... Does it make sense at all for an UDP server to do this? Sure, it works for simple protocols that do nothing but query/answer. But it's really useless for anything else. The documentation could be more verbose on this behaviour, in any case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767511&group_id=5470 From noreply at sourceforge.net Sat Aug 4 18:44:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 09:44:20 -0700 Subject: [ python-Bugs-1753395 ] struni: assertion in Windows debug build Message-ID: Bugs item #1753395, was opened at 2007-07-13 07:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Heller (theller) >Assigned to: Martin v. L?wis (loewis) Summary: struni: assertion in Windows debug build Initial Comment: When running Lib/test/test_descr.py with a Windows debug build, I get an assertion in the MS runtime lib, in the isalpha(*p) call, file typeobject.c, line 1582. The value of '*p' at the time of the call is 4660. The assertion reported is: File: istype.c Line: 68 Expression; (unsigned)(c + 1) <= 256 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-04 12:44 Message: Logged In: YES user_id=6380 Originator: NO I've committed the *p > 127 patch. Committed revision 56737. However, we'll need to change this again now that we accept Unicode identifiers. Assigning to MvL. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-08-04 03:42 Message: Logged In: YES user_id=89016 Originator: NO Right, this should have been *p > 255, even better would be *p > 127. Thomas, can you try that on Windows? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 16:37 Message: Logged In: YES user_id=6380 Originator: NO I wonder if the test "i > 255" wasn't meant to be "*p > 255"? Please try that, and submit if it works. Looks like Walter Doerwald introduced this bug in r55892. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 From noreply at sourceforge.net Sat Aug 4 22:58:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Aug 2007 13:58:00 -0700 Subject: [ python-Bugs-1753395 ] struni: assertion in Windows debug build Message-ID: Bugs item #1753395, was opened at 2007-07-13 13:35 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: struni: assertion in Windows debug build Initial Comment: When running Lib/test/test_descr.py with a Windows debug build, I get an assertion in the MS runtime lib, in the isalpha(*p) call, file typeobject.c, line 1582. The value of '*p' at the time of the call is 4660. The assertion reported is: File: istype.c Line: 68 Expression; (unsigned)(c + 1) <= 256 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-08-04 22:58 Message: Logged In: YES user_id=11105 Originator: YES I confirm that the assertion in the windows debug build is gone now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-04 18:44 Message: Logged In: YES user_id=6380 Originator: NO I've committed the *p > 127 patch. Committed revision 56737. However, we'll need to change this again now that we accept Unicode identifiers. Assigning to MvL. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-08-04 09:42 Message: Logged In: YES user_id=89016 Originator: NO Right, this should have been *p > 255, even better would be *p > 127. Thomas, can you try that on Windows? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 22:37 Message: Logged In: YES user_id=6380 Originator: NO I wonder if the test "i > 255" wasn't meant to be "*p > 255"? Please try that, and submit if it works. Looks like Walter Doerwald introduced this bug in r55892. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1753395&group_id=5470 From noreply at sourceforge.net Sun Aug 5 10:36:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 01:36:16 -0700 Subject: [ python-Bugs-1759845 ] subprocess.call fails with unicode strings in command line Message-ID: Bugs item #1759845, was opened at 2007-07-25 04:24 Message generated for change (Comment added) made by brotch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt (mclausch) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.call fails with unicode strings in command line Initial Comment: On Windows, subprocess.call() fails with an exception if either the executable or any of the arguments contain upper level characters. See below: >>> cmd = [ u'test_\xc5_exec.bat', u'arg1', u'arg2' ] >>> subprocess.call(cmd) Traceback (most recent call last): File "", line 1, in File "C:\Python25\lib\subprocess.py", line 443, in call return Popen(*popenargs, **kwargs).wait() File "C:\Python25\lib\subprocess.py", line 593, in __init__ errread, errwrite) File "C:\Python25\lib\subprocess.py", line 815, in _execute_child startupinfo) UnicodeEncodeError: 'ascii' codec can't encode character u'\xc5' in position 5: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: brotchie (brotch) Date: 2007-08-05 18:36 Message: Logged In: YES user_id=1860608 Originator: NO Python's default character coding is 'ascii' which can't convert unicode > 127 into chars. Forcing the unicode string to encode as 'iso-8859-1' eg. subprocess.call(cmd.encode('iso-8859-1')) resolves the problem and runs the correct command. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759845&group_id=5470 From noreply at sourceforge.net Sun Aug 5 17:01:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 08:01:57 -0700 Subject: [ python-Bugs-1767933 ] Badly formed XML using etree and utf-16 Message-ID: Bugs item #1767933, was opened at 2007-08-05 18:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: BugoK (bugok) Assigned to: Nobody/Anonymous (nobody) Summary: Badly formed XML using etree and utf-16 Initial Comment: Hello, The bug occurs when writing an XML file using the UTF-16 encoding. The problem is that the etree encodes every string to utf-16 by itself - meaning, inserting the 0xfffe BOM before every string (tag, text, attribute name, etc.), causing a badly formed utf=16 strings. A possible solution, which was offered by a co-worker of mine, was to use a utf-16 writer (from codecs.getwriter('utf-16') to write the file. Best, BugoK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 From noreply at sourceforge.net Sun Aug 5 17:07:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 08:07:55 -0700 Subject: [ python-Bugs-1767933 ] Badly formed XML using etree and utf-16 Message-ID: Bugs item #1767933, was opened at 2007-08-05 18:01 Message generated for change (Settings changed) made by bugok You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: XML Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: BugoK (bugok) Assigned to: Nobody/Anonymous (nobody) Summary: Badly formed XML using etree and utf-16 Initial Comment: Hello, The bug occurs when writing an XML file using the UTF-16 encoding. The problem is that the etree encodes every string to utf-16 by itself - meaning, inserting the 0xfffe BOM before every string (tag, text, attribute name, etc.), causing a badly formed utf=16 strings. A possible solution, which was offered by a co-worker of mine, was to use a utf-16 writer (from codecs.getwriter('utf-16') to write the file. Best, BugoK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 From noreply at sourceforge.net Mon Aug 6 07:14:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Aug 2007 22:14:26 -0700 Subject: [ python-Bugs-1768121 ] Byte code WITH_CLEANUP missing, MAKE_CLOSURE wrong Message-ID: Bugs item #1768121, was opened at 2007-08-05 22:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Byte code WITH_CLEANUP missing, MAKE_CLOSURE wrong Initial Comment: In section 30.10.1, WITH_CLEANUP is missing. The description of MAKE_CLOSURE is wrong: it says that the closure cells are the next N items on the stack below TOS, but in fact the closure cells are an N-element tuple at TOS1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768121&group_id=5470 From noreply at sourceforge.net Mon Aug 6 19:18:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 10:18:01 -0700 Subject: [ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject? Message-ID: Bugs item #1645148, was opened at 2007-01-26 11:04 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIME renderer: wrong header line break with long subject? Initial Comment: >>> from email.MIMEText import MIMEText >>> o=MIMEText('hello') >>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 ' >>> o.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\ nhello' >>> The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 without space between 89 in usual mail readers. Is this an error and should be : '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in '6 7 8 9 \n\nhello' ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2007-08-06 19:18 Message: Logged In: YES user_id=972995 Originator: YES the bug appears to be quite frequent now (once one knows it :-) ). Possibly for the same reason one sees this kind of subject alteration by one space often on the usenet. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-09 07:19 Message: Logged In: YES user_id=479790 Originator: NO Quoting RFC2822 section 2.2.3 : """The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test [...]Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP.""" That is, folding is done by inserting ONLY the sequence CRLF before any folding whitespace. When the header is interpreted, the whitespace is NOT removed, only the CRLF. The posted Subject header should become "Subject: 1 2 3...7 8\n\r 9 1 2...' I think this is a bug in the email.header.Header class; its __init__ says, about the continuation_ws argument: "[it] must be RFC 2822 compliant folding whitespace (usually either a space or a hard tab) which will be prepended to continuation lines.". Folding does not involve *prepending* any whitespace, just inserting CRLF right before *existing* whitespace. Note that this is wrong even for the old RFC 822 (with slightly different rules for line folding.) ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2007-06-08 14:11 Message: Logged In: YES user_id=972995 Originator: YES What would be the RFC definition for a correct auto-line break in a (subject) mail header line? Wouldn't it be more simple to not do any auto-line break for the subject? or is there a requirement for the line break in the RFC. Don't think any reader program would fail because of >79 char subject header lines. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 22:17 Message: Logged In: YES user_id=12800 Originator: NO Whoops, this wasn't supposed to be a response to Tokio, but instead the OP. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 22:16 Message: Logged In: YES user_id=12800 Originator: NO Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Mail.app 2.1.1 -- the extra space produces an extra space between the 8 and 9 both in the message summary and in the Subject header in the preview pane. The no extra space message looks fine. Thunderbird 1.5.0.10 -- The extra space message produces an extra space in the message summary, while the no extra space message looks fine here. But the weird thing is that in both the extra space and non-extra space cases, the Subject header in the preview pane both have extra spaces. It looks to me like the leading tab is being inserted into the Subject header view. Entourage 11.3.3 -- The extra space shows up in both the summary and preview panes but only in the message with the extra space Linux Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in both the summary and preview pane. This is for both the extra space message and the no-extra space message; afaict, there's no difference between the two and this is definitely a difference between the Linux version and the OSX version of the same mail reader. Evolution 2.9.92 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks fine. Sylpheed Claws 2.6.0 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks file. So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 From noreply at sourceforge.net Mon Aug 6 21:08:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 12:08:59 -0700 Subject: [ python-Bugs-1768767 ] tutorial Message-ID: Bugs item #1768767, was opened at 2007-08-06 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael R Bax (mrbax) Assigned to: Nobody/Anonymous (nobody) Summary: tutorial Initial Comment: tutorial ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768767&group_id=5470 From noreply at sourceforge.net Mon Aug 6 21:12:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 12:12:15 -0700 Subject: [ python-Bugs-1768767 ] tutorial Message-ID: Bugs item #1768767, was opened at 2007-08-06 12:08 Message generated for change (Settings changed) made by mrbax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768767&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Michael R Bax (mrbax) Assigned to: Nobody/Anonymous (nobody) Summary: tutorial Initial Comment: tutorial ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768767&group_id=5470 From noreply at sourceforge.net Mon Aug 6 21:45:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 12:45:09 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-07 05:45 Message: Logged In: YES user_id=10273 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 07:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much "thread safe" as "thread robust". I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back if it is still not finished. However, as it is now it looks like it is fixed... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-04 06:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made threadsafe. To be truely threadsafe it also needs to make sure that _active contains only abandoned popen instances so that _cleanup() doesn't have it's inst.poll() calls collide with other threads that are still using those popen instances. This can be done by havin the popen instances added to _active only by Popen.__del__(), and only removed by _cleanup() when they are done. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 19:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 10:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-02 03:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 15:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Mon Aug 6 22:02:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 13:02:40 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 00:19 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2007-08-06 22:02 Message: Logged In: YES user_id=344921 Originator: NO >I can create a patch to make current head a bit cleaner, if anyone is >interested... Sure, this would be great. I would also love a test case that reproduces this problem. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-06 21:45 Message: Logged In: YES user_id=10273 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 23:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much "thread safe" as "thread robust". I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back if it is still not finished. However, as it is now it looks like it is fixed... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 22:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 21:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made threadsafe. To be truely threadsafe it also needs to make sure that _active contains only abandoned popen instances so that _cleanup() doesn't have it's inst.poll() calls collide with other threads that are still using those popen instances. This can be done by havin the popen instances added to _active only by Popen.__del__(), and only removed by _cleanup() when they are done. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 21:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 11:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 02:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 19:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 19:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 07:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Tue Aug 7 00:43:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 15:43:17 -0700 Subject: [ python-Bugs-1768858 ] Python - Operation time out problem Message-ID: Bugs item #1768858, was opened at 2007-08-06 17: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=1768858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: MASK (mohammedsk) Assigned to: Nobody/Anonymous (nobody) Summary: Python - Operation time out problem Initial Comment: I have a program that reads from a file some search terms. The script uses Medline record parser pub med dictionary. Since I search so many terms, the script times out. Here is the error: Traceback (most recent call last): File "(stdin)", line1, in File "search_all.py",line71, in Cur_record = medline_dict [id] File "C:\Python25\Lib\site-packages\PubMed.py", line 103, in_getitem_raise Key Error,x Key Error: IOError('socket error',error(10060,'Operation timed out')) I looked online for solutions and one solution was to add the following to the script: import socket socket.setdefaulttimeout(value) But this code did not do anything, the script continues on timing out. A complete Python script is attached. Any help is appreciated. Thanks, Mohammed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1768858&group_id=5470 From noreply at sourceforge.net Tue Aug 7 07:45:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 22:45:41 -0700 Subject: [ python-Bugs-1767242 ] os.chmod failure Message-ID: Bugs item #1767242, was opened at 2007-08-03 11:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Heck (rgheck) Assigned to: Nobody/Anonymous (nobody) Summary: os.chmod failure Initial Comment: When running on Linux and accessing a FAT partition, os.chmod fails with otherwise sensible partitions: >>> os.chmod("/media/IHP-100/Test.lyx", 400) >>> os.chmod("/media/IHP-100/Test.lyx", 600) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx' The only thing that seems to be allowed is `4'. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-06 22:45 Message: Logged In: YES user_id=33168 Originator: NO Note: you are *not* using octal in python, but the chmod program is using octal: Try prefixing 400/600 with a zero, ie: 0400 or 0600. ---------------------------------------------------------------------- Comment By: Richard Heck (rgheck) Date: 2007-08-03 13:39 Message: Logged In: YES user_id=1072146 Originator: YES Well, the shell's chmod doesn't return an error. [rgheck at rghstudy scripts]$ chmod 600 /media/IHP-100/Test.lyx [rgheck at rghstudy scripts]$ echo $? 0 [rgheck at rghstudy scripts]$ chmod 400 /media/IHP-100/Test.lyx [rgheck at rghstudy scripts]$ echo $? 0 [rgheck at rghstudy scripts]$ chmod 700 /media/IHP-100/Test.lyx [rgheck at rghstudy scripts]$ echo $? 0 [rgheck at rghstudy scripts]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:00) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.chmod("/media/IHP-100/Test.lyx", 400) >>> os.chmod("/media/IHP-100/Test.lyx", 600) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 1] Operation not permitted: '/media/IHP-100/Test.lyx' I don't know what would happen in C, say. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-03 13:25 Message: Logged In: YES user_id=849994 Originator: NO Why do you think this is Python's fault? os.chmod() is only a very thin wrapper around the OS' chmod(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767242&group_id=5470 From noreply at sourceforge.net Tue Aug 7 07:54:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 22:54:48 -0700 Subject: [ python-Bugs-1767933 ] Badly formed XML using etree and utf-16 Message-ID: Bugs item #1767933, was opened at 2007-08-05 08:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: BugoK (bugok) >Assigned to: Fredrik Lundh (effbot) Summary: Badly formed XML using etree and utf-16 Initial Comment: Hello, The bug occurs when writing an XML file using the UTF-16 encoding. The problem is that the etree encodes every string to utf-16 by itself - meaning, inserting the 0xfffe BOM before every string (tag, text, attribute name, etc.), causing a badly formed utf=16 strings. A possible solution, which was offered by a co-worker of mine, was to use a utf-16 writer (from codecs.getwriter('utf-16') to write the file. Best, BugoK. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-06 22:54 Message: Logged In: YES user_id=33168 Originator: NO Fredrik, could you take a look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 From noreply at sourceforge.net Tue Aug 7 08:20:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 23:20:13 -0700 Subject: [ python-Bugs-1767933 ] Badly formed XML using etree and utf-16 Message-ID: Bugs item #1767933, was opened at 2007-08-05 17:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: BugoK (bugok) Assigned to: Fredrik Lundh (effbot) Summary: Badly formed XML using etree and utf-16 Initial Comment: Hello, The bug occurs when writing an XML file using the UTF-16 encoding. The problem is that the etree encodes every string to utf-16 by itself - meaning, inserting the 0xfffe BOM before every string (tag, text, attribute name, etc.), causing a badly formed utf=16 strings. A possible solution, which was offered by a co-worker of mine, was to use a utf-16 writer (from codecs.getwriter('utf-16') to write the file. Best, BugoK. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2007-08-07 08:20 Message: Logged In: YES user_id=38376 Originator: NO ET's standard serializer currently only supports ASCII-compatible encodings. See e.g. http://effbot.python-hosting.com/ticket/47 The best workaround for ET 1.2 (Python 2.5) is probably to serialize as "utf-8" and transcode: out = unicode(ET.tostring(elem), "utf-8").encode(...) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-07 07:54 Message: Logged In: YES user_id=33168 Originator: NO Fredrik, could you take a look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1767933&group_id=5470 From report at bugs.python.org Tue Aug 7 08:27:25 2007 From: report at bugs.python.org (user) Date: Tue, 07 Aug 2007 06:27:25 -0000 Subject: [issue1] Test issue Message-ID: <1186468045.4.0.686842929742.issue1@psf.upfronthosting.co.za> New submission from user: Hi there folks. This is just a test issue to make sure the e-mail sending from the tracker that hopefully will be in production RSN works as expected. ---------- components: Build messages: 17863 nosy: user severity: normal status: open title: Test issue type: rfe versions: Python 2.3 ________________________________ Tracker ________________________________ From report at bugs.python.org Tue Aug 7 08:27:25 2007 From: report at bugs.python.org (user) Date: Tue, 07 Aug 2007 06:27:25 -0000 Subject: [issue1] Test issue Message-ID: <1186468045.4.0.686842929742.issue1@psf.upfronthosting.co.za> New submission from user: Hi there folks. This is just a test issue to make sure the e-mail sending from the tracker that hopefully will be in production RSN works as expected. ---------- components: Build messages: 17863 nosy: user severity: normal status: open title: Test issue type: rfe versions: Python 2.3 ________________________________ Tracker ________________________________ From noreply at sourceforge.net Tue Aug 7 08:44:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Aug 2007 23:44:21 -0700 Subject: [ python-Bugs-1769002 ] A paragraph about packages should be updated. Message-ID: Bugs item #1769002, was opened at 2007-08-07 09: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=1769002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: A paragraph about packages should be updated. Initial Comment: The page about packages says: " When packages are structured into subpackages (as with the Sound package in the example), there's no shortcut to refer to submodules of sibling packages - the full name of the subpackage must be used ... " This isn't true, a thing which becomes apparant once you read the next paragraph, about relative imports in Python 2.5. Thanks, Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1769002&group_id=5470 From noreply at sourceforge.net Tue Aug 7 09:13:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 00:13:58 -0700 Subject: [ python-Bugs-1769002 ] A paragraph about packages should be updated. Message-ID: Bugs item #1769002, was opened at 2007-08-07 06:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1769002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: A paragraph about packages should be updated. Initial Comment: The page about packages says: " When packages are structured into subpackages (as with the Sound package in the example), there's no shortcut to refer to submodules of sibling packages - the full name of the subpackage must be used ... " This isn't true, a thing which becomes apparant once you read the next paragraph, about relative imports in Python 2.5. Thanks, Noam ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-07 07:13 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 56797, 56798 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1769002&group_id=5470 From report at bugs.python.org Tue Aug 7 09:33:40 2007 From: report at bugs.python.org (devel) Date: Tue, 07 Aug 2007 07:33:40 -0000 Subject: [issue1] Test issue Message-ID: <1186472019.75.0.377957402766.issue1@psf.upfronthosting.co.za> devel added the comment: Closing test issue. ---------- nosy: +devel resolution: -> invalid status: open -> closed ________________________________ Tracker ________________________________ From noreply at sourceforge.net Tue Aug 7 20:31:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Aug 2007 11:31:41 -0700 Subject: [ python-Bugs-1769002 ] A paragraph about packages should be updated. Message-ID: Bugs item #1769002, was opened at 2007-08-07 12:14 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1769002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: A paragraph about packages should be updated. Initial Comment: The page about packages says: " When packages are structured into subpackages (as with the Sound package in the example), there's no shortcut to refer to submodules of sibling packages - the full name of the subpackage must be used ... " This isn't true, a thing which becomes apparant once you read the next paragraph, about relative imports in Python 2.5. Thanks, Noam ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-08 00:01 Message: Logged In: YES user_id=942711 Originator: NO That was a nice observation. Good that its fixed now. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-07 12:43 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 56797, 56798 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1769002&group_id=5470 From report at bugs.python.org Tue Aug 7 21:45:01 2007 From: report at bugs.python.org (user) Date: Tue, 07 Aug 2007 19:45:01 -0000 Subject: [issue1767787] MSVC++8 x86 tkinter build patch for trunk Message-ID: <1186515901.86.0.121335968762.issue1767787@psf.upfronthosting.co.za> Changes by user: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Aug 8 09:28:02 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 08 Aug 2007 07:28:02 -0000 Subject: [issue1000] x Message-ID: <1186558082.61.0.18941974791.issue1000@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- severity: normal status: open title: x __________________________________ Tracker __________________________________ From noreply at sourceforge.net Wed Aug 8 14:44:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 05:44:32 -0700 Subject: [ python-Bugs-1770009 ] decimal.Decimal("trash") produces informationless exception Message-ID: Bugs item #1770009, was opened at 2007-08-08 22: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=1770009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: decimal.Decimal("trash") produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> decimal.Decimal("-$123,456.78") Traceback (most recent call last): File "", line 1, in File "C:\python25\lib\decimal.py", line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\python25\lib\decimal.py", line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: >>> float("-$123,456.78") Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for float(): -$123,456.78 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 From noreply at sourceforge.net Wed Aug 8 15:04:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 06:04:10 -0700 Subject: [ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects Message-ID: Bugs item #1730114, was opened at 2007-06-03 01:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: reedobrien (reedobrien) Assigned to: Georg Brandl (gbrandl) Summary: cStringIO no longer accepts array.array objects Initial Comment: It worked fine in 2.5 and 2.4.4 Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15) Type "copyright", "credits" or "license" for more information. In [1]: from cStringIO import StringIO In [2]: from array import array In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) --------------------------------------------------------------------------- Traceback (most recent call last) /Users/reedobrien/ in () : expected a character buffer object Recompiling with the 2.5 cStringIO.c it works. Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12) Type "copyright", "credits" or "license" for more information. In [1]: from array import array In [2]: from cStringIO import StringIO In [3]: a = array('B', [0,1,2]) In [4]: StringIO(a) Out[4]: I blame Visual Studio. I don't know enough c to fix it. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-08 13:04 Message: Logged In: YES user_id=849994 Originator: NO Fixed by reverting the offending change. Added a note in the docs. Committed revisions 56830, 56831 (2.5). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-06 18:12 Message: Logged In: YES user_id=849994 Originator: NO I'll look at it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 06:40 Message: Logged In: YES user_id=80475 Originator: NO Georgbot, I believe this was your checkin. ---------------------------------------------------------------------- Comment By: reedobrien (reedobrien) Date: 2007-06-03 05:49 Message: Logged In: YES user_id=995094 Originator: YES It appears this is the change that broke it. http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302 This is the log entry from that changeset: Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode arguments with the system default encoding just like the write() method does, instead of converting it to a raw buffer. (backport from rev. 52301) Perhaps the cPickle module should be used instead... BUT at first glance the following seems to make both work: if (PyUnicode_Check(s)) { if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0) { PyErr_Format(PyExc_TypeError, "expected character buffer, %.200s found", s->ob_type->tp_name); return NULL; } } else { if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0) return NULL; } But the more I think about it the more I think cPickle is more appropriate for this purpose. In that case I should make a blurb for the docs about not storing arbitrary data in cStringIO. Either way I am attaching the cStringIO.c file that worked for me... File Added: cStringIO.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470 From noreply at sourceforge.net Wed Aug 8 20:08:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 11:08:55 -0700 Subject: [ python-Bugs-1770190 ] platform.mac_ver() returning incorrect patch version Message-ID: Bugs item #1770190, was opened at 2007-08-08 13:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gus Tabares (gtabares) Assigned to: Jack Jansen (jackjansen) Summary: platform.mac_ver() returning incorrect patch version Initial Comment: Running on an Intel Mac OSX 10.4.10 machine: >>> platform.mac_ver() ('10.4.9', ('', '', ''), 'i386') I have reproduced this on 4 other (Intel Mac) machines. I don't have access to a 10.4.10 PPC machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&group_id=5470 From noreply at sourceforge.net Wed Aug 8 22:43:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 13:43:22 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 18: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=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Thu Aug 9 00:05:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 15:05:15 -0700 Subject: [ python-Bugs-1770190 ] platform.mac_ver() returning incorrect patch version Message-ID: Bugs item #1770190, was opened at 2007-08-08 20:08 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gustavo Tabares (gtabares) Assigned to: Jack Jansen (jackjansen) Summary: platform.mac_ver() returning incorrect patch version Initial Comment: Running on an Intel Mac OSX 10.4.10 machine: >>> platform.mac_ver() ('10.4.9', ('', '', ''), 'i386') I have reproduced this on 4 other (Intel Mac) machines. I don't have access to a 10.4.10 PPC machine. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2007-08-09 00:05 Message: Logged In: YES user_id=45365 Originator: NO Interesting problem! Mac_ver() basically uses gestalt() with a selector of 'sysv' and this will return '9' for the micro-version if it is 9 or greater. It could be fixed, according to by using three calls to gestalt() with selectors 'sys1', 'sys2' and 'sys3', which will return the three numbers correctly. I'm not sure whether these selectors are always available, will investigate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&group_id=5470 From noreply at sourceforge.net Thu Aug 9 03:34:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 18:34:16 -0700 Subject: [ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030 Message-ID: Bugs item #1770551, was opened at 2007-08-09 01: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=1770551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Z-flagship (zaex) Assigned to: M.-A. Lemburg (lemburg) Summary: words able to decode but unable to encode in GB18030 Initial Comment: Here is a list of chinese characters that can be read from a file [in GB18030 encoding], but unable to encode to GB18030 encoding detailed: used codecs.open(r'file name', encoding='GB18030') to read the characters from a file, and try to encode them word by word into GB18030 with word.encode('GB18030'). The action caused an exception with 'illegal multibyte sequence' the attachment is also the list. list: ????????????????????????????????????????????????????? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 From noreply at sourceforge.net Thu Aug 9 03:37:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Aug 2007 18:37:14 -0700 Subject: [ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030 Message-ID: Bugs item #1770551, was opened at 2007-08-09 01:34 Message generated for change (Comment added) made by zaex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Z-flagship (zaex) Assigned to: M.-A. Lemburg (lemburg) Summary: words able to decode but unable to encode in GB18030 Initial Comment: Here is a list of chinese characters that can be read from a file [in GB18030 encoding], but unable to encode to GB18030 encoding detailed: used codecs.open(r'file name', encoding='GB18030') to read the characters from a file, and try to encode them word by word into GB18030 with word.encode('GB18030'). The action caused an exception with 'illegal multibyte sequence' the attachment is also the list. list: ????????????????????????????????????????????????????? ---------------------------------------------------------------------- >Comment By: Z-flagship (zaex) Date: 2007-08-09 01:37 Message: Logged In: YES user_id=1863611 Originator: YES The Python is Python2.5 , my OS is windows XP professional sp2 version 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 From report at bugs.python.org Thu Aug 9 07:17:41 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 09 Aug 2007 05:17:41 -0000 Subject: [issue1720897] fix 1668596: copy datafiles properly when package_dir is ' ' Message-ID: <1186636661.03.0.250406296675.issue1720897@psf.upfronthosting.co.za> Martin v. L?wis added the comment: URL test (http://www.python.org/sf/1668596) ---------- nosy: +loewis _____________________________________ Tracker _____________________________________ From noreply at sourceforge.net Thu Aug 9 10:09:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 01:09:29 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 17:43 Message generated for change (Comment added) made by ajaksu2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 05:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Thu Aug 9 17:09:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 08:09:54 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 18:13 Message generated for change (Comment added) made by aryx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- >Comment By: Jason G (aryx) Date: 2007-08-09 12:39 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 05:39 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Thu Aug 9 19:21:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 10:21:43 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 17:43 Message generated for change (Comment added) made by ajaksu2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 14:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is "don't touch decimal.py until X", this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): """ Convert decimal.Decimal to long (abridged, non-checking version)""" decimal_string = str(number) if "e" in decimal_string: radix, exponent = decimal_string.split("e") elif "E" in decimal_string: radix, exponent = decimal_string.split("E") else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if "." in radix: rint, rdec = radix.split(".") radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len <= exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if "." in radix: radix_integer_part = long(radix.split(".")[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): """Converts self to an int, truncating if necessary.""" if number._exp >= 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) ---------------------------------------------------------------------- Comment By: Jason G (aryx) Date: 2007-08-09 12:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 05:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Thu Aug 9 19:37:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 10:37:40 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) >Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is "don't touch decimal.py until X", this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): """ Convert decimal.Decimal to long (abridged, non-checking version)""" decimal_string = str(number) if "e" in decimal_string: radix, exponent = decimal_string.split("e") elif "E" in decimal_string: radix, exponent = decimal_string.split("E") else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if "." in radix: rint, rdec = radix.split(".") radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len <= exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if "." in radix: radix_integer_part = long(radix.split(".")[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): """Converts self to an int, truncating if necessary.""" if number._exp >= 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) ---------------------------------------------------------------------- Comment By: Jason G (aryx) Date: 2007-08-09 15:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 08:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Thu Aug 9 23:37:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 14:37:51 -0700 Subject: [ python-Bugs-1771260 ] Errors in site.py not reported properly Message-ID: Bugs item #1771260, was opened at 2007-08-09 15: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=1771260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) rhamph at factor:~/src/python-p3yk/build$ make object : type : TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the "lost sys.stderr" line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief "stderr unavailable; original exception was ..." message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 From noreply at sourceforge.net Fri Aug 10 04:32:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 19:32:24 -0700 Subject: [ python-Bugs-1771381 ] bsddb can't use unicode keys Message-ID: Bugs item #1771381, was opened at 2007-08-10 04:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771381&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erol Aktay (moghe) Assigned to: M.-A. Lemburg (lemburg) Summary: bsddb can't use unicode keys Initial Comment: bsddb throws a TypeError when I try to use an unicode string as key name; i.e. bsddb.btopen("foobar", "c")[u'foo'] = "bar" fails I discovered it while experimenting with the shelve module. You may find more information in the attached file. Python version: 2.5.1 OS: Windows XP SP2 (5.1.2600) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771381&group_id=5470 From noreply at sourceforge.net Fri Aug 10 05:35:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 20:35:29 -0700 Subject: [ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030 Message-ID: Bugs item #1770551, was opened at 2007-08-08 18:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Z-flagship (zaex) >Assigned to: Hye-Shik Chang (perky) Summary: words able to decode but unable to encode in GB18030 Initial Comment: Here is a list of chinese characters that can be read from a file [in GB18030 encoding], but unable to encode to GB18030 encoding detailed: used codecs.open(r'file name', encoding='GB18030') to read the characters from a file, and try to encode them word by word into GB18030 with word.encode('GB18030'). The action caused an exception with 'illegal multibyte sequence' the attachment is also the list. list: ????????????????????????????????????????????????????? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-09 20:35 Message: Logged In: YES user_id=33168 Originator: NO This seems like a cjk problem. Hye-Shik, could you take a look? ---------------------------------------------------------------------- Comment By: Z-flagship (zaex) Date: 2007-08-08 18:37 Message: Logged In: YES user_id=1863611 Originator: YES The Python is Python2.5 , my OS is windows XP professional sp2 version 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 From noreply at sourceforge.net Fri Aug 10 05:36:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Aug 2007 20:36:21 -0700 Subject: [ python-Bugs-1770009 ] decimal.Decimal("trash") produces informationless exception Message-ID: Bugs item #1770009, was opened at 2007-08-08 05:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) >Assigned to: Facundo Batista (facundobatista) Summary: decimal.Decimal("trash") produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> decimal.Decimal("-$123,456.78") Traceback (most recent call last): File "", line 1, in File "C:\python25\lib\decimal.py", line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\python25\lib\decimal.py", line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: >>> float("-$123,456.78") Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for float(): -$123,456.78 >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-09 20:36 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 From noreply at sourceforge.net Fri Aug 10 10:56:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 01:56:28 -0700 Subject: [ python-Bugs-1771483 ] another 'nothing to repeat' Message-ID: Bugs item #1771483, was opened at 2007-08-10 08: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=1771483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: viciousdog (viciousdog) Assigned to: Gustavo Niemeyer (niemeyer) Summary: another 'nothing to repeat' Initial Comment: Hi, rxSlice = re.compile('\[([^:\]]*):([^:\[]?){1}(:[^:\[]+)?\]') compiles, but rxSlice = re.compile('\[([^:\]]*):([^:\[]*){1}(:[^:\[]+)?\]') produces: >>> error: nothing to repeat (Python 2.5.1 in idle on Windows XPpro) Perhaps that 'nothing to repeat' is intended for {x} (i wouldn't like that at all), but then it must not differenciate between * and ?. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771483&group_id=5470 From noreply at sourceforge.net Fri Aug 10 11:27:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 02:27:23 -0700 Subject: [ python-Bugs-1771483 ] another 'nothing to repeat' Message-ID: Bugs item #1771483, was opened at 2007-08-10 08:56 Message generated for change (Settings changed) made by viciousdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.5 >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: viciousdog (viciousdog) Assigned to: Gustavo Niemeyer (niemeyer) Summary: another 'nothing to repeat' Initial Comment: Hi, rxSlice = re.compile('\[([^:\]]*):([^:\[]?){1}(:[^:\[]+)?\]') compiles, but rxSlice = re.compile('\[([^:\]]*):([^:\[]*){1}(:[^:\[]+)?\]') produces: >>> error: nothing to repeat (Python 2.5.1 in idle on Windows XPpro) Perhaps that 'nothing to repeat' is intended for {x} (i wouldn't like that at all), but then it must not differenciate between * and ?. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771483&group_id=5470 From noreply at sourceforge.net Fri Aug 10 13:30:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 04:30:25 -0700 Subject: [ python-Bugs-1771558 ] minor bug in turtle Message-ID: Bugs item #1771558, was opened at 2007-08-10 11: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=1771558&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in turtle Initial Comment: xpc17:~:$ python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import turtle >>> turtle.demo2() Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.5/lib-tk/turtle.py", line 874, in demo2 sleep(2) NameError: global name 'sleep' is not defined Sleep needs to be imported from the time module before it is used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771558&group_id=5470 From noreply at sourceforge.net Fri Aug 10 19:32:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 10:32:12 -0700 Subject: [ python-Bugs-1771558 ] minor bug in turtle Message-ID: Bugs item #1771558, was opened at 2007-08-10 11:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771558&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in turtle Initial Comment: xpc17:~:$ python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import turtle >>> turtle.demo2() Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.5/lib-tk/turtle.py", line 874, in demo2 sleep(2) NameError: global name 'sleep' is not defined Sleep needs to be imported from the time module before it is used. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-10 17:32 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 56900. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771558&group_id=5470 From noreply at sourceforge.net Fri Aug 10 20:19:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 11:19:06 -0700 Subject: [ python-Bugs-1771260 ] Errors in site.py not reported properly Message-ID: Bugs item #1771260, was opened at 2007-08-09 15:37 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) rhamph at factor:~/src/python-p3yk/build$ make object : type : TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the "lost sys.stderr" line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief "stderr unavailable; original exception was ..." message. ---------------------------------------------------------------------- >Comment By: Adam Olsen (rhamphoryncus) Date: 2007-08-10 12:19 Message: Logged In: YES user_id=12364 Originator: YES Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead. That way the callers can add the message about "lost sys.stderr" themselves, rather than it being interspersed in their output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 From noreply at sourceforge.net Fri Aug 10 22:01:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 13:01:57 -0700 Subject: [ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time Message-ID: Bugs item #1633941, was opened at 2007-01-12 02:34 Message generated for change (Comment added) made by marhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: liw at esme$ python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time liw at esme$ Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. ---------------------------------------------------------------------- Comment By: Mark Harrison (marhar) Date: 2007-08-10 13:01 Message: Logged In: YES user_id=40482 Originator: NO I think this should be considered a bug. These two command lines (on unix) should behave the same: cat | ./foo.py ./foo.py But they do not. The first (using cat) behaves typically, needing only one control-D. The second needs the two control-D's as noted. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-25 11:04 Message: Logged In: YES user_id=984087 Originator: NO BTW, I opened bug 1643712 for doc change. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-24 09:20 Message: Logged In: YES user_id=984087 Originator: NO I tested two kinds of inputs with iter and noiter verisons. I posted "noter" code and OP's code is the iter version. 1) For input without newline at all (line1) behaves same with both versions. 2) The noiter version prints "eof" with "line1\n" while the iter version requires an additional CTRL-D. This is because iter version uses read ahead which is implemented using fread() . A simple C program using fread() behaves exactly same way. I tested on Linux but am sure windows behaviour (as posted by gagenellina) will have same reasons. Since the issue is with platform's stdio library, I don't think python should fix anything here. However, it may be worthwhile to mention something about this in documentation. I will open a bug for this purpose. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 09:45 Message: Logged In: YES user_id=984087 Originator: NO Ok. This may sound stupid but I couldn't find a way to attach a file to this bug report. So I am copying the code here: ************ import sys line = sys.stdin.readline() while (line): print line, line = sys.stdin.readline() print "eof" ************* ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 09:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 08:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 08:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 20:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ctrl-D) has to be pressed 3 times: D:\Temp>python foo.py foo <--- I pressed Enter ^Z <--- I pressed Ctrl-Z and then Enter again foo <--- this appeared ^Z <--- I pressed Ctrl-Z and then Enter again D:\Temp>python foo.py foo^Z <--- I pressed Ctrl-Z and then Enter ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again foo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 From noreply at sourceforge.net Fri Aug 10 23:38:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Aug 2007 14:38:47 -0700 Subject: [ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library Message-ID: Bugs item #1721161, was opened at 2007-05-18 01:12 Message generated for change (Comment added) made by mwtoews You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): ============================================================== TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. ============================================================== How to repair?! ---------------------------------------------------------------------- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 14:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. ---------------------------------------------------------------------- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 05:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 02:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 From noreply at sourceforge.net Sat Aug 11 09:09:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 00:09:57 -0700 Subject: [ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library Message-ID: Bugs item #1721161, was opened at 2007-05-18 08:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): ============================================================== TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. ============================================================== How to repair?! ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 07:09 Message: Logged In: YES user_id=849994 Originator: NO Closing as 3rd party. ---------------------------------------------------------------------- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 21:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. ---------------------------------------------------------------------- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 12:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 09:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 From noreply at sourceforge.net Sat Aug 11 09:10:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 00:10:11 -0700 Subject: [ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library Message-ID: Bugs item #1721161, was opened at 2007-05-18 08:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): ============================================================== TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. ============================================================== How to repair?! ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 07:10 Message: Logged In: YES user_id=849994 Originator: NO Closing as 3rd party. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 07:09 Message: Logged In: YES user_id=849994 Originator: NO Closing as 3rd party. ---------------------------------------------------------------------- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 21:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. ---------------------------------------------------------------------- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 12:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 09:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 From noreply at sourceforge.net Sun Aug 12 03:22:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 18:22:42 -0700 Subject: [ python-Bugs-1772481 ] urllib2 hangs with some documents. Message-ID: Bugs item #1772481, was opened at 2007-08-12 01: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=1772481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Creature (acreature) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 hangs with some documents. Initial Comment: While working on a web spider I encountered the following page that causes the read() call of a urllib2 response to fail. It uses 100% of the CPU and does not seem to ever return. I have this behaviour on Python 2.4.4, but several people on 2.5.1 have tried the code below and reported the same behaviour. By the way, the page it uses is a porn site, but please don't get hung up on that fact. This is a data processing issue, not a subject matter issue. This test case is attached as a file, but is also available at http://pastebin.com/d6f98618f . Please note that the user-agent masquerading is present to rule out any issues with the server returning different data to different clients; commenting out the line so Python sends the standard headers still results in the issue occuring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&group_id=5470 From noreply at sourceforge.net Sun Aug 12 03:32:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 18:32:54 -0700 Subject: [ python-Bugs-1772481 ] urllib2 hangs with some documents. Message-ID: Bugs item #1772481, was opened at 2007-08-12 01:22 Message generated for change (Comment added) made by acreature You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Creature (acreature) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 hangs with some documents. Initial Comment: While working on a web spider I encountered the following page that causes the read() call of a urllib2 response to fail. It uses 100% of the CPU and does not seem to ever return. I have this behaviour on Python 2.4.4, but several people on 2.5.1 have tried the code below and reported the same behaviour. By the way, the page it uses is a porn site, but please don't get hung up on that fact. This is a data processing issue, not a subject matter issue. This test case is attached as a file, but is also available at http://pastebin.com/d6f98618f . Please note that the user-agent masquerading is present to rule out any issues with the server returning different data to different clients; commenting out the line so Python sends the standard headers still results in the issue occuring. ---------------------------------------------------------------------- >Comment By: Creature (acreature) Date: 2007-08-12 01:32 Message: Logged In: YES user_id=1407924 Originator: YES It seems that a fix to this issue is to change line 525 to add "or line == ''" on httplib.py in Python 2.4.4: # read and discard trailer up to the CRLF terminator ### note: we shouldn't have any trailers! while True: line = self.fp.readline() if line == '\r\n' or line == '': break I'm told that this is found on line 574 on Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&group_id=5470 From noreply at sourceforge.net Sun Aug 12 04:25:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 19:25:39 -0700 Subject: [ python-Bugs-1772489 ] dir() on traceback objects returns an empty list Message-ID: Bugs item #1772489, was opened at 2007-08-11 22:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: dir() on traceback objects returns an empty list Initial Comment: The current status of the py3k branch is that calling dir() on a traceback object does not produce the expected results: a 4-element list of the tb_* attributes. The attached patch restores this behaviour and adds a regression test to test_builtins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772489&group_id=5470 From noreply at sourceforge.net Sun Aug 12 04:34:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Aug 2007 19:34:20 -0700 Subject: [ python-Bugs-1772489 ] dir() on traceback objects returns an empty list Message-ID: Bugs item #1772489, was opened at 2007-08-11 19:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: dir() on traceback objects returns an empty list Initial Comment: The current status of the py3k branch is that calling dir() on a traceback object does not produce the expected results: a 4-element list of the tb_* attributes. The attached patch restores this behaviour and adds a regression test to test_builtins. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 19:34 Message: Logged In: YES user_id=33168 Originator: NO I was the one that broke this when I removed __members__ and __methods__. I was hoping we could get rid of the getattr. See the XXX comment near the top of the file. If that can't be removed this patch should at least by applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772489&group_id=5470 From noreply at sourceforge.net Sun Aug 12 13:26:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 04:26:59 -0700 Subject: [ python-Bugs-1742889 ] Pickling of exceptions broken Message-ID: Bugs item #1742889, was opened at 2007-06-25 16:43 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? ---------------------------------------------------------------------- >Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:26 Message: Logged In: YES user_id=1326842 Originator: NO Jim, could you please take a look at the pathes in #1692335? See: http://www.python.org/sf/1692335 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 17:57 Message: Logged In: YES user_id=849994 Originator: NO No, I haven't anything written -- and this should be fixed anyway. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 17:57 Message: Logged In: YES user_id=73023 Originator: YES I'll note that I think the right thing to do is to: - Take args and message out of the C struct. - inherit the default reduce behavior from object. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 17:53 Message: Logged In: YES user_id=73023 Originator: YES I'm not aware of any such contract. Can you point to anything in writing? See for example: file:///home/jim/Documentation/Python-Docs-2.4.1/tut/node10.html#SECTION0010500000000000000000 which teaches people to create custom exceptions that: - don't set args ro message and - won't be unpicklable in Python 2.5. Also, as I mentioned, the reduce implementation doesn't preserve the message, so even if that was the contract, the contract is broken. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 17:26 Message: Logged In: YES user_id=849994 Originator: NO AFAIR we were told that filling args and message is part of the exception contract... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 From noreply at sourceforge.net Sun Aug 12 17:18:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 08:18:46 -0700 Subject: [ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030 Message-ID: Bugs item #1770551, was opened at 2007-08-09 10:34 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Z-flagship (zaex) Assigned to: Hye-Shik Chang (perky) Summary: words able to decode but unable to encode in GB18030 Initial Comment: Here is a list of chinese characters that can be read from a file [in GB18030 encoding], but unable to encode to GB18030 encoding detailed: used codecs.open(r'file name', encoding='GB18030') to read the characters from a file, and try to encode them word by word into GB18030 with word.encode('GB18030'). The action caused an exception with 'illegal multibyte sequence' the attachment is also the list. list: ????????????????????????????????????????????????????? ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2007-08-13 00:18 Message: Logged In: YES user_id=55188 Originator: NO The problem has been fixed about a week ago. (r56727-8) It will be okay on the forthcoming Python releases. Thank you for reporting! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-10 12:35 Message: Logged In: YES user_id=33168 Originator: NO This seems like a cjk problem. Hye-Shik, could you take a look? ---------------------------------------------------------------------- Comment By: Z-flagship (zaex) Date: 2007-08-09 10:37 Message: Logged In: YES user_id=1863611 Originator: YES The Python is Python2.5 , my OS is windows XP professional sp2 version 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470 From noreply at sourceforge.net Sun Aug 12 19:12:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 10:12:04 -0700 Subject: [ python-Bugs-1772686 ] exec() doesn't take an open file Message-ID: Bugs item #1772686, was opened at 2007-08-12 10:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: exec() doesn't take an open file Initial Comment: exec() is documented to take an open file. The error message also says it takes one, however: >>> exec(open('nn.py')) Traceback (most recent call last): File "", line 1, in TypeError: exec() arg 1 must be a string, file, or code object, not TextIOWrapper ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470 From noreply at sourceforge.net Sun Aug 12 19:57:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 10:57:46 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 17:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999999999999999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is "don't touch decimal.py until X", this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): """ Convert decimal.Decimal to long (abridged, non-checking version)""" decimal_string = str(number) if "e" in decimal_string: radix, exponent = decimal_string.split("e") elif "E" in decimal_string: radix, exponent = decimal_string.split("E") else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if "." in radix: rint, rdec = radix.split(".") radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len <= exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if "." in radix: radix_integer_part = long(radix.split(".")[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): """Converts self to an int, truncating if necessary.""" if number._exp >= 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) ---------------------------------------------------------------------- Comment By: Jason G (aryx) Date: 2007-08-09 15:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 08:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Sun Aug 12 21:16:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 12:16:44 -0700 Subject: [ python-Bugs-1772686 ] exec() doesn't take an open file Message-ID: Bugs item #1772686, was opened at 2007-08-12 10:12 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: exec() doesn't take an open file Initial Comment: exec() is documented to take an open file. The error message also says it takes one, however: >>> exec(open('nn.py')) Traceback (most recent call last): File "", line 1, in TypeError: exec() arg 1 must be a string, file, or code object, not TextIOWrapper ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-08-12 12:16 Message: Logged In: YES user_id=357491 Originator: NO This is a duplicate of bug #1762972 which Guido and I have already discussed how to deal with this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470 From noreply at sourceforge.net Sun Aug 12 21:43:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 12:43:37 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 19:43 Message: Logged In: YES user_id=703403 Originator: NO Mark Dickinson (marketdickinson) stupidly claimed that: hash(n) == hash(n % (2**32-1)) It's not true. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 17:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999999999999999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is "don't touch decimal.py until X", this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): """ Convert decimal.Decimal to long (abridged, non-checking version)""" decimal_string = str(number) if "e" in decimal_string: radix, exponent = decimal_string.split("e") elif "E" in decimal_string: radix, exponent = decimal_string.split("E") else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if "." in radix: rint, rdec = radix.split(".") radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len <= exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if "." in radix: radix_integer_part = long(radix.split(".")[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): """Converts self to an int, truncating if necessary.""" if number._exp >= 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) ---------------------------------------------------------------------- Comment By: Jason G (aryx) Date: 2007-08-09 15:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 08:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Mon Aug 13 00:54:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 15:54:08 -0700 Subject: [ python-Bugs-1772788 ] chr(128) in u'only ascii' -> TypeError with misleading msg Message-ID: Bugs item #1772788, was opened at 2007-08-13 01: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=1772788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' -> TypeError with misleading msg Initial Comment: A test using in format "chr(x) in " raises a TypeError if "x" is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> chr(127) in 'hello' False >>> chr(128) in 'hello' False >>> chr(127) in u'hi' False >>> chr(128) in u'hi' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using "in " format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. >>> chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. >>> type(chr(128)) A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 From noreply at sourceforge.net Mon Aug 13 01:17:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 16:17:18 -0700 Subject: [ python-Bugs-1772794 ] Using telnetlib fails with unicode strings containing only a Message-ID: Bugs item #1772794, was opened at 2007-08-13 02: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=1772794&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: Using telnetlib fails with unicode strings containing only a Initial Comment: It is not possible to use unicode strings with telnetlib even if these strings used only ascii characters. Example below demonstrates this. Type "help", "copyright", "credits" or "license" for more information. >>> import telnetlib >>> telnetlib.Telnet().write(u'hi') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/telnetlib.py", line 289, in write if IAC in buffer: TypeError: 'in ' requires string as left operand This problem is caused by bug #1772788 "chr(128) in u'only ascii' -> TypeError with misleading msg". The relevant code is following and IAC is chr(255). def write(self, buffer): if IAC in buffer: buffer = buffer.replace(IAC, IAC+IAC) self.msg("send %r", buffer) self.sock.sendall(buffer) There are many pretty obvious ways to have a workaround for the issue. I suggest something like follows assuming that accepting unicode data is ok in general. If unicode is not ok then "pass" can be replaced with something like "raise TypeError('Unicode data no accepted')" to at least have a better error message. def write(self, buffer): try: buffer = buffer.replace(IAC, IAC+IAC) except UnicodeError: pass self.msg("send %r", buffer) self.sock.sendall(buffer) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470 From noreply at sourceforge.net Mon Aug 13 01:21:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 16:21:06 -0700 Subject: [ python-Bugs-1772794 ] Telnetlib dosn't accept unicode containing only ascii Message-ID: Bugs item #1772794, was opened at 2007-08-13 02:17 Message generated for change (Settings changed) made by laukpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) >Summary: Telnetlib dosn't accept unicode containing only ascii Initial Comment: It is not possible to use unicode strings with telnetlib even if these strings used only ascii characters. Example below demonstrates this. Type "help", "copyright", "credits" or "license" for more information. >>> import telnetlib >>> telnetlib.Telnet().write(u'hi') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/telnetlib.py", line 289, in write if IAC in buffer: TypeError: 'in ' requires string as left operand This problem is caused by bug #1772788 "chr(128) in u'only ascii' -> TypeError with misleading msg". The relevant code is following and IAC is chr(255). def write(self, buffer): if IAC in buffer: buffer = buffer.replace(IAC, IAC+IAC) self.msg("send %r", buffer) self.sock.sendall(buffer) There are many pretty obvious ways to have a workaround for the issue. I suggest something like follows assuming that accepting unicode data is ok in general. If unicode is not ok then "pass" can be replaced with something like "raise TypeError('Unicode data no accepted')" to at least have a better error message. def write(self, buffer): try: buffer = buffer.replace(IAC, IAC+IAC) except UnicodeError: pass self.msg("send %r", buffer) self.sock.sendall(buffer) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470 From noreply at sourceforge.net Mon Aug 13 01:22:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 16:22:44 -0700 Subject: [ python-Bugs-1772794 ] Telnetlib dosn't accept u'only ascii' Message-ID: Bugs item #1772794, was opened at 2007-08-13 02:17 Message generated for change (Settings changed) made by laukpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) >Summary: Telnetlib dosn't accept u'only ascii' Initial Comment: It is not possible to use unicode strings with telnetlib even if these strings used only ascii characters. Example below demonstrates this. Type "help", "copyright", "credits" or "license" for more information. >>> import telnetlib >>> telnetlib.Telnet().write(u'hi') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/telnetlib.py", line 289, in write if IAC in buffer: TypeError: 'in ' requires string as left operand This problem is caused by bug #1772788 "chr(128) in u'only ascii' -> TypeError with misleading msg". The relevant code is following and IAC is chr(255). def write(self, buffer): if IAC in buffer: buffer = buffer.replace(IAC, IAC+IAC) self.msg("send %r", buffer) self.sock.sendall(buffer) There are many pretty obvious ways to have a workaround for the issue. I suggest something like follows assuming that accepting unicode data is ok in general. If unicode is not ok then "pass" can be replaced with something like "raise TypeError('Unicode data no accepted')" to at least have a better error message. def write(self, buffer): try: buffer = buffer.replace(IAC, IAC+IAC) except UnicodeError: pass self.msg("send %r", buffer) self.sock.sendall(buffer) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470 From noreply at sourceforge.net Mon Aug 13 05:07:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 20:07:44 -0700 Subject: [ python-Bugs-1772481 ] urllib2 hangs with some documents. Message-ID: Bugs item #1772481, was opened at 2007-08-12 06:52 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Creature (acreature) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 hangs with some documents. Initial Comment: While working on a web spider I encountered the following page that causes the read() call of a urllib2 response to fail. It uses 100% of the CPU and does not seem to ever return. I have this behaviour on Python 2.4.4, but several people on 2.5.1 have tried the code below and reported the same behaviour. By the way, the page it uses is a porn site, but please don't get hung up on that fact. This is a data processing issue, not a subject matter issue. This test case is attached as a file, but is also available at http://pastebin.com/d6f98618f . Please note that the user-agent masquerading is present to rule out any issues with the server returning different data to different clients; commenting out the line so Python sends the standard headers still results in the issue occuring. ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-13 08:37 Message: Logged In: YES user_id=942711 Originator: NO Yes, I could verify the issue as well as the fix. Please submit a patch to patches or if someone with trunk access can make the change immediately. ---------------------------------------------------------------------- Comment By: Creature (acreature) Date: 2007-08-12 07:02 Message: Logged In: YES user_id=1407924 Originator: YES It seems that a fix to this issue is to change line 525 to add "or line == ''" on httplib.py in Python 2.4.4: # read and discard trailer up to the CRLF terminator ### note: we shouldn't have any trailers! while True: line = self.fp.readline() if line == '\r\n' or line == '': break I'm told that this is found on line 574 on Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&group_id=5470 From noreply at sourceforge.net Mon Aug 13 05:35:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 20:35:27 -0700 Subject: [ python-Feature Requests-1728488 ] -q (quiet) option for python interpreter Message-ID: Feature Requests item #1728488, was opened at 2007-05-30 20:44 Message generated for change (Comment added) made by wojdyr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: I'd like to suggest the new option for python: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. Why: I often use python as a calculator, for a couple-lines calculations, and would prefer to avoid having printed these three lines. There is a similar option in e.g. gdb. AFAICS the implementation would require small changes in Modules/main.c, Misc/python.man and probably in other docs. If it would be accepted, I can do it. Marcin ---------------------------------------------------------------------- >Comment By: Marcin Wojdyr (wojdyr) Date: 2007-08-13 05:35 Message: Logged In: YES user_id=586843 Originator: YES -> patch 1772833 ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-03 04:06 Message: Logged In: YES user_id=942711 Originator: NO +1 for this option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-08-02 06:26 Message: Logged In: YES user_id=80475 Originator: NO +1 I think this would be nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 From noreply at sourceforge.net Mon Aug 13 06:48:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 21:48:21 -0700 Subject: [ python-Bugs-1558802 ] Tru64 make install failure Message-ID: Bugs item #1558802, was opened at 2006-09-15 03:21 Message generated for change (Comment added) made by chris_laws You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Anthony Baxter (anthonybaxter) Summary: Tru64 make install failure Initial Comment: "make install" of Python 2.5c2 fails under Tru64 Unix V5.1. The failure is fixed by the simple patch below. I.e., simply remove two lines from Makefile.pre.in. Apparently the native make doesn't support comments where commands are expected. diff -r -u Python-2.5c2/Makefile.pre.in Python-2.5c2_cci/Makefile.pre.in --- Python-2.5c2/Makefile.pre.in 2006-07-30 09:20:10.000000000 -0700 +++ Python-2.5c2_cci/Makefile.pre.in 2006-09-14 10:17:12.000000000 -0700 @@ -850,8 +850,6 @@ $(INSTALL_DATA) Modules/Setup.config $(DESTDIR)$(LIBPL)/Setup.config $(INSTALL_SCRIPT) $(srcdir)/Modules/makesetup $(DESTDIR)$(LIBPL)/makesetup $(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh - # Substitution happens here, as the completely-expanded BINDIR - # is not available in configure sed -e "s, at EXENAME@,$(BINDIR)/python$(VERSION)$(EXE)," < $(srcdir)/Misc/python-config.in >python-config $(INSTALL_SCRIPT) python-config $(DESTDIR)$(BINDIR)/python$(VERSION)-config rm python-config ---------------------------------------------------------------------- Comment By: chris_laws (chris_laws) Date: 2007-08-13 14:18 Message: Logged In: YES user_id=1866246 Originator: NO Not sure if this is appropriate here but it may at least indicate that the issue is affecting more than one user. I've just come across this bug and implementing the suggested patch fixed the issue for me. My company has a lot of DEC Alpha's (uname -a: OSF1 V4.0 1530 alpha) that we want to run Python on. It would be great if this simple fix was rolled into the main baseline in a future release. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 14:00 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&group_id=5470 From noreply at sourceforge.net Mon Aug 13 06:50:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Aug 2007 21:50:22 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-13 04:50 Message: Logged In: YES user_id=703403 Originator: NO See patch #1772851 ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 19:43 Message: Logged In: YES user_id=703403 Originator: NO Mark Dickinson (marketdickinson) stupidly claimed that: hash(n) == hash(n % (2**32-1)) It's not true. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 17:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999999999999999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is "don't touch decimal.py until X", this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): """ Convert decimal.Decimal to long (abridged, non-checking version)""" decimal_string = str(number) if "e" in decimal_string: radix, exponent = decimal_string.split("e") elif "E" in decimal_string: radix, exponent = decimal_string.split("E") else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if "." in radix: rint, rdec = radix.split(".") radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len <= exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if "." in radix: radix_integer_part = long(radix.split(".")[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): """Converts self to an int, truncating if necessary.""" if number._exp >= 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) ---------------------------------------------------------------------- Comment By: Jason G (aryx) Date: 2007-08-09 15:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 08:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Mon Aug 13 09:10:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 00:10:13 -0700 Subject: [ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo Message-ID: Bugs item #1772890, was opened at 2007-08-13 02: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=1772890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: 3rd Party Status: Open Resolution: None Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 "String Methods" ===== startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. ===== ...Believe "suffixes" should be corrected to "prefixes" (Likely a copy and paste oversight from the description for mirror method " endswith(suffix[, start[, end]])") Typo report of Jan. 2007 noted as closed, but error is still present. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 From noreply at sourceforge.net Mon Aug 13 10:15:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 01:15:58 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Mon Aug 13 11:39:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 02:39:23 -0700 Subject: [ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo Message-ID: Bugs item #1772890, was opened at 2007-08-13 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: 3rd Party >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 "String Methods" ===== startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. ===== ...Believe "suffixes" should be corrected to "prefixes" (Likely a copy and paste oversight from the description for mirror method " endswith(suffix[, start[, end]])") Typo report of Jan. 2007 noted as closed, but error is still present. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 From noreply at sourceforge.net Mon Aug 13 11:39:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 02:39:38 -0700 Subject: [ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo Message-ID: Bugs item #1772890, was opened at 2007-08-13 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: 3rd Party Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 "String Methods" ===== startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. ===== ...Believe "suffixes" should be corrected to "prefixes" (Likely a copy and paste oversight from the description for mirror method " endswith(suffix[, start[, end]])") Typo report of Jan. 2007 noted as closed, but error is still present. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 From noreply at sourceforge.net Mon Aug 13 13:06:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 04:06:45 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 03:15 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 06:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Mon Aug 13 17:10:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 08:10:14 -0700 Subject: [ python-Bugs-1770416 ] Decimal.__int__ overflows for large values Message-ID: Bugs item #1770416, was opened at 2007-08-08 17:43 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. >>> from decimal import Decimal as D >>> e = D("1e1234567890987654321") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer >>> e = D("1e1234567890") >>> int(e) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/decimal.py", line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-08-13 12:10 Message: Logged In: YES user_id=752496 Originator: NO hash will NOT be changed as is requested in this bug: >>> import decimal >>> d = decimal.Decimal(1) >>> hash(d) 1 >>> hash(1) 1 >>> hash(d.as_tuple()) -790594979 >>> See this requirement from PEP 327: hash(n) == hash(Decimal(n)) # Only if n is int, long, or Decimal Regarding the overflow, this must to be fixed... I'll take a look to marketdickinson patch... ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-13 01:50 Message: Logged In: YES user_id=703403 Originator: NO See patch #1772851 ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 16:43 Message: Logged In: YES user_id=703403 Originator: NO Mark Dickinson (marketdickinson) stupidly claimed that: hash(n) == hash(n % (2**32-1)) It's not true. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 14:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999999999999999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 14:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 14:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is "don't touch decimal.py until X", this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): """ Convert decimal.Decimal to long (abridged, non-checking version)""" decimal_string = str(number) if "e" in decimal_string: radix, exponent = decimal_string.split("e") elif "E" in decimal_string: radix, exponent = decimal_string.split("E") else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if "." in radix: rint, rdec = radix.split(".") radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len <= exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if "." in radix: radix_integer_part = long(radix.split(".")[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): """Converts self to an int, truncating if necessary.""" if number._exp >= 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) ---------------------------------------------------------------------- Comment By: Jason G (aryx) Date: 2007-08-09 12:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) ---------------------------------------------------------------------- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 05:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to "index-sized ints" as in "ints that are valid indexes for sequences", try: >>> e = "0" * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470 From noreply at sourceforge.net Mon Aug 13 17:17:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 08:17:50 -0700 Subject: [ python-Bugs-1770009 ] decimal.Decimal("trash") produces informationless exception Message-ID: Bugs item #1770009, was opened at 2007-08-08 09:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Facundo Batista (facundobatista) Summary: decimal.Decimal("trash") produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> decimal.Decimal("-$123,456.78") Traceback (most recent call last): File "", line 1, in File "C:\python25\lib\decimal.py", line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\python25\lib\decimal.py", line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: >>> float("-$123,456.78") Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for float(): -$123,456.78 >>> ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-08-13 12:17 Message: Logged In: YES user_id=752496 Originator: NO Yes, I will. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-10 00:36 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 From noreply at sourceforge.net Tue Aug 14 03:07:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 18:07:23 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Comment added) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- >Comment By: lplatypus (ldeller) Date: 2007-08-14 11:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 21:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Tue Aug 14 05:32:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 20:32:34 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 03:15 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 22:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2007-08-13 20:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 06:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Tue Aug 14 08:23:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Aug 2007 23:23:25 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Comment added) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- >Comment By: lplatypus (ldeller) Date: 2007-08-14 16:23 Message: Logged In: YES user_id=1534394 Originator: YES Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that matching allocator and deallocator functions are used. I installed PyXML-0.8.4 from source ("python setup.py install" on Win32 which picked up the C compiler from MSVS7.1). The cause of the problem is quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL are used together): http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I guess they weren't keeping in sync with each other. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-14 13:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2007-08-14 11:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 21:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Tue Aug 14 14:29:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 05:29:25 -0700 Subject: [ python-Bugs-1424152 ] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: Bugs item #1424152, was opened at 2006-02-04 18:50 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424152&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) >Summary: urllib/urllib2: HTTPS over (Squid) Proxy fails Initial Comment: py2.4.2/win32 The proxy mechanism of python fails on https and does work completely wrong (not using the CONNECT scheme). (after urlopen some minute(s) freeze then EOF error) Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.getproxies() {'ftp': 'ftp://vserver:3128', 'http': 'http://vserver:3128', 'gopher': 'gopher:/ /vserver:3128', 'https': 'https://vserver:3128'} >>> urllib.urlopen('https://www.elster.de') Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 386, in open_https h.endheaders() File "C:\Python24\lib\httplib.py", line 795, in endheaders self._send_output() File "C:\Python24\lib\httplib.py", line 676, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 643, in send self.connect() File "C:\Python24\lib\httplib.py", line 1071, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "C:\Python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) IOError: [Errno socket error] (8, 'EOF occurred in violation of protocol') >>> no CONNECT even appears in the squid proxy access log. Robert ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2007-08-14 14:29 Message: Logged In: YES user_id=60903 Originator: NO seen with urllib2 as well: https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/122551 ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-02-11 19:28 Message: Logged In: YES user_id=972995 Meanwhile I wrote my own CONNECT quick hack. As indeed this hack works correct for all proxied environments tested up to now (>30) I wonder how open_https (in urllib and urllib2) ever in the past managed to come through a proxy, because there is some differentiation in open_https for the case, that there is a proxy!? Who has written that if..else's? Are there proxies which really do SSL-handshaking directly and make an extra connection to the target server? I guess that would even make certificate handling very strange... I cannot immagine and never saw one. But maybe such proxies exist. I am not a real expert for such networking questions, but I guess CONNECT is widely used and in my own proxies I can see in the log file, that all common browsers use a HTTP CONNECT request for https proxying. CONNECT should at least be implemented as an option in urllibX Robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424152&group_id=5470 From noreply at sourceforge.net Tue Aug 14 19:54:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 10:54:45 -0700 Subject: [ python-Bugs-1772489 ] dir() on traceback objects returns an empty list Message-ID: Bugs item #1772489, was opened at 2007-08-11 22:25 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: dir() on traceback objects returns an empty list Initial Comment: The current status of the py3k branch is that calling dir() on a traceback object does not produce the expected results: a 4-element list of the tb_* attributes. The attached patch restores this behaviour and adds a regression test to test_builtins. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-08-14 13:54 Message: Logged In: YES user_id=1344176 Originator: YES Submitted as r57028. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 22:34 Message: Logged In: YES user_id=33168 Originator: NO I was the one that broke this when I removed __members__ and __methods__. I was hoping we could get rid of the getattr. See the XXX comment near the top of the file. If that can't be removed this patch should at least by applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772489&group_id=5470 From noreply at sourceforge.net Tue Aug 14 22:10:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Aug 2007 13:10:29 -0700 Subject: [ python-Bugs-1424152 ] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: Bugs item #1424152, was opened at 2006-02-04 23:20 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424152&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2: HTTPS over (Squid) Proxy fails Initial Comment: py2.4.2/win32 The proxy mechanism of python fails on https and does work completely wrong (not using the CONNECT scheme). (after urlopen some minute(s) freeze then EOF error) Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.getproxies() {'ftp': 'ftp://vserver:3128', 'http': 'http://vserver:3128', 'gopher': 'gopher:/ /vserver:3128', 'https': 'https://vserver:3128'} >>> urllib.urlopen('https://www.elster.de') Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 386, in open_https h.endheaders() File "C:\Python24\lib\httplib.py", line 795, in endheaders self._send_output() File "C:\Python24\lib\httplib.py", line 676, in _send_output self.send(msg) File "C:\Python24\lib\httplib.py", line 643, in send self.connect() File "C:\Python24\lib\httplib.py", line 1071, in connect ssl = socket.ssl(sock, self.key_file, self.cert_file) File "C:\Python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) IOError: [Errno socket error] (8, 'EOF occurred in violation of protocol') >>> no CONNECT even appears in the squid proxy access log. Robert ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-15 01:40 Message: Logged In: YES user_id=942711 Originator: NO Please verify if this recipe is of any help: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/456195 ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2007-08-14 17:59 Message: Logged In: YES user_id=60903 Originator: NO seen with urllib2 as well: https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/122551 ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-02-11 23:58 Message: Logged In: YES user_id=972995 Meanwhile I wrote my own CONNECT quick hack. As indeed this hack works correct for all proxied environments tested up to now (>30) I wonder how open_https (in urllib and urllib2) ever in the past managed to come through a proxy, because there is some differentiation in open_https for the case, that there is a proxy!? Who has written that if..else's? Are there proxies which really do SSL-handshaking directly and make an extra connection to the target server? I guess that would even make certificate handling very strange... I cannot immagine and never saw one. But maybe such proxies exist. I am not a real expert for such networking questions, but I guess CONNECT is widely used and in my own proxies I can see in the log file, that all common browsers use a HTTP CONNECT request for https proxying. CONNECT should at least be implemented as an option in urllibX Robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1424152&group_id=5470 From noreply at sourceforge.net Wed Aug 15 16:34:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 07:34:07 -0700 Subject: [ python-Bugs-1774736 ] Binding fails Message-ID: Bugs item #1774736, was opened at 2007-08-15 18: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=1774736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ali Gholami Rudi (aligrudi) Assigned to: Martin v. L?wis (loewis) Summary: Binding fails Initial Comment: In py3k branch r57057, when I run:: import Tkinter tk = Tkinter.Tk() text = Tkinter.Text(tk) def callback(event=None): return text.bind('', callback) text.pack() text.focus_set() tk.mainloop() when I press C-space I get this exception:: Traceback (most recent call last): File "spacefailure.py", line 13, in tk.mainloop() File "/usr/local/lib/python3.0/lib-tk/Tkinter.py", line 1022, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding The strange thing about it is that other bindings work as expected. I'm running on ubuntu feisty. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1774736&group_id=5470 From noreply at sourceforge.net Wed Aug 15 17:14:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 08:14:33 -0700 Subject: [ python-Bugs-1770009 ] decimal.Decimal("trash") produces informationless exception Message-ID: Bugs item #1770009, was opened at 2007-08-08 09:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Facundo Batista (facundobatista) Summary: decimal.Decimal("trash") produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> decimal.Decimal("-$123,456.78") Traceback (most recent call last): File "", line 1, in File "C:\python25\lib\decimal.py", line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File "C:\python25\lib\decimal.py", line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: >>> float("-$123,456.78") Traceback (most recent call last): File "", line 1, in ValueError: invalid literal for float(): -$123,456.78 >>> ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-08-15 12:14 Message: Logged In: YES user_id=752496 Originator: NO Fixed, both in trunk and in the decimal-branch: >>> import decimal >>> decimal.Decimal("-$123,456.78") Traceback (most recent call last): ... decimal.InvalidOperation: Invalid literal for Decimal: '-$123,456.78' >>> ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-08-13 12:17 Message: Logged In: YES user_id=752496 Originator: NO Yes, I will. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-10 00:36 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470 From noreply at sourceforge.net Wed Aug 15 18:27:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 09:27:20 -0700 Subject: [ python-Bugs-1774840 ] Not exiting when running tests Message-ID: Bugs item #1774840, was opened at 2007-08-15 16:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1774840&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jos? Pablo "Pupeno" Fern?ndez (pupeno) Assigned to: Nobody/Anonymous (nobody) Summary: Not exiting when running tests Initial Comment: Can you please offer a way to not exit when running unit tests, that is, an argument to unittest.main() that would make it not exit? Thank you ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1774840&group_id=5470 From noreply at sourceforge.net Wed Aug 15 20:43:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 11:43:09 -0700 Subject: [ python-Bugs-816725 ] mark deprecated modules in indexes Message-ID: Bugs item #816725, was opened at 2003-10-02 18:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816725&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Georg Brandl (gbrandl) Summary: mark deprecated modules in indexes Initial Comment: J. David Ibanez (jdavid at itaapy.com) suggested via email: It would be nice if the "Global Module Index" showed the deprecated modules clearly separated from the non deprecated modules. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-15 18:43 Message: Logged In: YES user_id=849994 Originator: NO This is now implemented in Sphinx, committed rev. 57075. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816725&group_id=5470 From noreply at sourceforge.net Wed Aug 15 20:46:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 11:46:49 -0700 Subject: [ python-Bugs-1243945 ] Python function/method/constant names as HTML-tag IDs Message-ID: Bugs item #1243945, was opened at 2005-07-24 15:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243945&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Chad Miller (chadmiller) >Assigned to: Georg Brandl (gbrandl) Summary: Python function/method/constant names as HTML-tag IDs Initial Comment: It would be very nice if HTML tag IDs were predictable, and not generated. For instance, when newbie-Joe complains on IRC about his program, I'd much rather be able to point him to http://python.org/doc/current/lib/built-in-funcs#input instead of http://python.org/doc/current/lib/built-in-funcs#l2h-38 or telling him to find it manually. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-15 18:46 Message: Logged In: YES user_id=849994 Originator: NO Sphinx does this right from the start. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-25 21:48 Message: Logged In: YES user_id=1188172 And the Tutorial section anchors aren't very pretty, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243945&group_id=5470 From noreply at sourceforge.net Wed Aug 15 20:47:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 11:47:48 -0700 Subject: [ python-Bugs-1375258 ] Collapse distutils docs Message-ID: Bugs item #1375258, was opened at 2005-12-07 12:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375258&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Trash >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Collapse distutils docs Initial Comment: The global module index is huge, 358 entries by my quick check. 46 of those entries are related to distutils. Let collapse it a bit. The Carbon entries are also numerous, but not that bad. As an example, check the docs for the distutils.debug module: 11.16 distutils.debug -- Distutils debug mode This module provides the DEBUG flag. Except for the header and footer generated by latex2html, that's the entire thing! Doesn't seem like it deserves its own entry in the global module index... I'll try to get to this, but in case I don't, at least it's recorded here... ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-15 18:47 Message: Logged In: YES user_id=849994 Originator: NO The global module index in Sphinx now automatically collapses submodules, so it should be fine for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1375258&group_id=5470 From noreply at sourceforge.net Wed Aug 15 20:53:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Aug 2007 11:53:42 -0700 Subject: [ python-Bugs-1559142 ] some section links (previous, up, next) missing last word Message-ID: Bugs item #1559142, was opened at 2006-09-15 08:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Tim Smith (thimsmith) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some section links (previous, up, next) missing last word Initial Comment: The Previous, Up and Next links in the Library Reference are often missing the last word. Examples: http://www.python.org/doc/current/lib/module-operator.html """Previous: 3.9 UserString Up: 3. Python Runtime Services Next: 3.10.1 Mapping Operators to """ (Next link missing last word "Functions".) http://www.python.org/doc/current/lib/weakref-example.html """Previous: 3.3.1 Weak Reference Objects Up: 3.3 weakref Next: 3.3.3 Weak References in """ (Next link missing last two words "Extension Types".) There are *many* examples of this. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-15 18:53 Message: Logged In: YES user_id=849994 Originator: NO Doesn't apply to Sphinx, closing. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 13:56 Message: Logged In: YES user_id=3066 Originator: NO This is indeed a LaTeX2HTML (mis-)feature. I think this is the first time it's been reported as a problem, but I agree that it's misleading without some indication that something was elided (an ellipsis would help a lot). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 12:10 Message: Logged In: YES user_id=849994 This seems to be a "feature" of LaTeX2html. It limits the links to three words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 From noreply at sourceforge.net Thu Aug 16 14:28:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Aug 2007 05:28:59 -0700 Subject: [ python-Bugs-1775388 ] Display CallTips for classes using metaclasses. Message-ID: Bugs item #1775388, was opened at 2007-08-16 15: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=1775388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Display CallTips for classes using metaclasses. Initial Comment: Hello, Currently, if you write something like this: class MyType(type): pass class MyClass(object): __metaclass__ = MyType def __init__(self, a): pass And write in the shell: >>> MyClass( a calltip won't be displayed. To fix this, replace this line in CallTups.py: if type(ob) in (types.ClassType, types.TypeType): with this one: if issubclass(type(ob), (types.ClassType, types.TypeType)): and now it works. Thanks, Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1775388&group_id=5470 From noreply at sourceforge.net Fri Aug 17 10:18:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 01:18:29 -0700 Subject: [ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject? Message-ID: Bugs item #1645148, was opened at 2007-01-26 10:04 Message generated for change (Comment added) made by aalbrecht You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIME renderer: wrong header line break with long subject? Initial Comment: >>> from email.MIMEText import MIMEText >>> o=MIMEText('hello') >>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 ' >>> o.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\ nhello' >>> The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 without space between 89 in usual mail readers. Is this an error and should be : '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in '6 7 8 9 \n\nhello' ---------------------------------------------------------------------- Comment By: Andi Albrecht (aalbrecht) Date: 2007-08-17 08:18 Message: Logged In: YES user_id=1693212 Originator: NO The problem occurs, when you are using strings, not when you use the Header class directly. The reason for this behaviour is the way the Generator creates Header instances from strings: It initializes the class with continuation_ws set to '\t' instead of the default ' ' (email/generator.py in method _write_headers). >>> from email.MIMEText import MIMEText >>> msg = MIMEText("Just a test.") >>> msg["Subject"] = "foo "*22 >>> print msg.as_string() Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo Just a test. >>> Tab as the whitespace character is no problem for most email clients. But i.e. Outlook removes it. When using the Header class you get the following >>> from email.MIMEText import MIMEText >>> from email.header import Header >>> msg = MIMEText("Just a test.") >>> msg["Subject"] = Header("foo "*22) >>> print msg.as_string() Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo Just a test. >>> The last message shows up in Outlook correctly. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2007-08-06 17:18 Message: Logged In: YES user_id=972995 Originator: YES the bug appears to be quite frequent now (once one knows it :-) ). Possibly for the same reason one sees this kind of subject alteration by one space often on the usenet. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-06-09 05:19 Message: Logged In: YES user_id=479790 Originator: NO Quoting RFC2822 section 2.2.3 : """The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test [...]Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP.""" That is, folding is done by inserting ONLY the sequence CRLF before any folding whitespace. When the header is interpreted, the whitespace is NOT removed, only the CRLF. The posted Subject header should become "Subject: 1 2 3...7 8\n\r 9 1 2...' I think this is a bug in the email.header.Header class; its __init__ says, about the continuation_ws argument: "[it] must be RFC 2822 compliant folding whitespace (usually either a space or a hard tab) which will be prepended to continuation lines.". Folding does not involve *prepending* any whitespace, just inserting CRLF right before *existing* whitespace. Note that this is wrong even for the old RFC 822 (with slightly different rules for line folding.) ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2007-06-08 12:11 Message: Logged In: YES user_id=972995 Originator: YES What would be the RFC definition for a correct auto-line break in a (subject) mail header line? Wouldn't it be more simple to not do any auto-line break for the subject? or is there a requirement for the line break in the RFC. Don't think any reader program would fail because of >79 char subject header lines. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 21:17 Message: Logged In: YES user_id=12800 Originator: NO Whoops, this wasn't supposed to be a response to Tokio, but instead the OP. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 21:16 Message: Logged In: YES user_id=12800 Originator: NO Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Mail.app 2.1.1 -- the extra space produces an extra space between the 8 and 9 both in the message summary and in the Subject header in the preview pane. The no extra space message looks fine. Thunderbird 1.5.0.10 -- The extra space message produces an extra space in the message summary, while the no extra space message looks fine here. But the weird thing is that in both the extra space and non-extra space cases, the Subject header in the preview pane both have extra spaces. It looks to me like the leading tab is being inserted into the Subject header view. Entourage 11.3.3 -- The extra space shows up in both the summary and preview panes but only in the message with the extra space Linux Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in both the summary and preview pane. This is for both the extra space message and the no-extra space message; afaict, there's no difference between the two and this is definitely a difference between the Linux version and the OSX version of the same mail reader. Evolution 2.9.92 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks fine. Sylpheed Claws 2.6.0 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks file. So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 From noreply at sourceforge.net Fri Aug 17 13:24:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 04:24:22 -0700 Subject: [ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory Message-ID: Bugs item #1776160, was opened at 2007-08-17 13: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=1776160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 From report at bugs.python.org Fri Aug 17 14:56:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 17 Aug 2007 12:56:04 -0000 Subject: [issue1000] Test Message-ID: <1187355364.43.0.232568184499.issue1000@psf.upfronthosting.co.za> New submission from Martin v. L?wis: This contains a word egastono that is unlikely to occur elsewhere ---------- messages: 55039 nosy: loewis severity: normal status: open title: Test __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 17 14:56:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 17 Aug 2007 12:56:04 -0000 Subject: [issue1000] Test Message-ID: <1187355364.43.0.232568184499.issue1000@psf.upfronthosting.co.za> New submission from Martin v. L?wis: This contains a word egastono that is unlikely to occur elsewhere ---------- messages: 55039 nosy: loewis severity: normal status: open title: Test __________________________________ Tracker __________________________________ From noreply at sourceforge.net Fri Aug 17 17:09:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 08:09:20 -0700 Subject: [ python-Feature Requests-1619060 ] bisect on presorted list Message-ID: Feature Requests item #1619060, was opened at 2006-12-19 22:14 Message generated for change (Comment added) made by karlb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) Assigned to: Raymond Hettinger (rhettinger) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. ---------------------------------------------------------------------- Comment By: Karl Bartel (karlb) Date: 2007-08-17 17:09 Message: Logged In: YES user_id=787 Originator: NO +1 for adding a reverse parameter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-19 22:43 Message: Logged In: YES user_id=80475 Originator: NO I'm -1 on this patch. At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key. In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again. This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern). By including custom sorting in bisect's API we would be diverting users away from better approaches. A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1619060&group_id=5470 From noreply at sourceforge.net Fri Aug 17 20:56:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 11:56:28 -0700 Subject: [ python-Bugs-1698167 ] xml.etree document element.tag Message-ID: Bugs item #1698167, was opened at 2007-04-11 06:25 Message generated for change (Comment added) made by dlocke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Fredrik Lundh (effbot) Summary: xml.etree document element.tag Initial Comment: The xml.etree docs vaguely mention an implementation-dependent Element interface without describing it in any detail. I could not figure out from the docs how to get the tag name of an element returned from (say) the getiterator interface. That is, for an element like , I wanted the string "foo". Examining the library source showed that e.tag does the job, at least some of the time, and that was enough to get my app working. Could the actual situation please be documented--thanks. ---------------------------------------------------------------------- Comment By: dlocke (dlocke) Date: 2007-08-17 18:56 Message: Logged In: YES user_id=1525611 Originator: NO I concur that any documentation about the Element object seems to be missing. Is there any timetable for getting this added to the documentation? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2007-04-13 13:32 Message: Logged In: YES user_id=38376 Originator: NO Looks like the entire Element section is missing from the current documentation. Thanks for reporting this; I'll take a look when I find the time. In the meantime, you'll find additional documentation here: http://effbot.org/zone/element.htm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1698167&group_id=5470 From noreply at sourceforge.net Sat Aug 18 02:14:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 17:14:50 -0700 Subject: [ python-Bugs-1776674 ] glob.glob inconsistent Message-ID: Bugs item #1776674, was opened at 2007-08-18 02: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=1776674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: norbidur (norbidur) Assigned to: Nobody/Anonymous (nobody) Summary: glob.glob inconsistent Initial Comment: On windows, glob.glob gives different results if you use a wildcard or not and if you use unix-style paths. exemple : import glob print glob.glob("c:/tmp/3691674.jpg") print glob.glob("c:/tmp/3691674.jpg*") print glob.glob("c:/res.txt") print glob.glob("c:/res.txt*") gives : ['c:/tmp/3691674.jpg'] ['c:/tmp\\3691674.jpg'] ['c:/res.txt'] ['c:/res.txt'] the two first calls give the same result but one with a platform specific separator, and not the other. One can think that if there is no wildcard, this is normal behavior to return the path given to glob.glob but then I have the second inconsitency : in that case the last result should be c:\\res.txt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776674&group_id=5470 From noreply at sourceforge.net Sat Aug 18 04:31:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Aug 2007 19:31:17 -0700 Subject: [ python-Bugs-1776696 ] tempfile.TemporaryFile differs between platforms Message-ID: Bugs item #1776696, was opened at 2007-08-18 02:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenneth Loafman (loafman) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.TemporaryFile differs between platforms Initial Comment: When running the following: import tempfile foo=tempfile.TemporaryFile type(foo) Linux returns: Windows and Cygwin return: It should return the same across platforms, or return an undefined indication if not possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&group_id=5470 From noreply at sourceforge.net Sat Aug 18 13:38:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 04:38:06 -0700 Subject: [ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory Message-ID: Bugs item #1776160, was opened at 2007-08-17 06:24 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 06:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep/0000/0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 From noreply at sourceforge.net Sun Aug 19 03:13:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 18:13:40 -0700 Subject: [ python-Bugs-1777057 ] memoryview('test') is causing a segfault Message-ID: Bugs item #1777057, was opened at 2007-08-19 03: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=1777057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: memoryview('test') is causing a segfault Initial Comment: ./python -c "memoryview('test')" Segmentation fault I compiled Python 3.0 with $ ./configure --with-pydebug --enable-unicode=ucs4 and $ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG" after a make clean; rm -rf build; svn up I've used gdb to trace the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210415424 (LWP 14436)] 0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at Python/errors.c:55 55 if (exception != NULL && ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 From noreply at sourceforge.net Sun Aug 19 03:14:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 18:14:50 -0700 Subject: [ python-Bugs-1777057 ] memoryview('test') is causing a segfault Message-ID: Bugs item #1777057, was opened at 2007-08-19 03:13 Message generated for change (Settings changed) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: memoryview('test') is causing a segfault Initial Comment: ./python -c "memoryview('test')" Segmentation fault I compiled Python 3.0 with $ ./configure --with-pydebug --enable-unicode=ucs4 and $ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG" after a make clean; rm -rf build; svn up I've used gdb to trace the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210415424 (LWP 14436)] 0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at Python/errors.c:55 55 if (exception != NULL && ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 From noreply at sourceforge.net Sun Aug 19 04:00:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 19:00:59 -0700 Subject: [ python-Bugs-1775388 ] Display CallTips for classes using metaclasses. Message-ID: Bugs item #1775388, was opened at 2007-08-16 08:28 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1775388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Noam Raphael (noamr) >Assigned to: Kurt B. Kaiser (kbk) Summary: Display CallTips for classes using metaclasses. Initial Comment: Hello, Currently, if you write something like this: class MyType(type): pass class MyClass(object): __metaclass__ = MyType def __init__(self, a): pass And write in the shell: >>> MyClass( a calltip won't be displayed. To fix this, replace this line in CallTups.py: if type(ob) in (types.ClassType, types.TypeType): with this one: if issubclass(type(ob), (types.ClassType, types.TypeType)): and now it works. Thanks, Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1775388&group_id=5470 From noreply at sourceforge.net Sun Aug 19 06:25:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Aug 2007 21:25:00 -0700 Subject: [ python-Bugs-1777057 ] memoryview('test') is causing a segfault Message-ID: Bugs item #1777057, was opened at 2007-08-18 18:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 8 Private: No Submitted By: Christian Heimes (tiran) >Assigned to: Neal Norwitz (nnorwitz) Summary: memoryview('test') is causing a segfault Initial Comment: ./python -c "memoryview('test')" Segmentation fault I compiled Python 3.0 with $ ./configure --with-pydebug --enable-unicode=ucs4 and $ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG" after a make clean; rm -rf build; svn up I've used gdb to trace the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210415424 (LWP 14436)] 0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at Python/errors.c:55 55 if (exception != NULL && ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-18 21:25 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 57193. This problem was due to not initializing the new BufferError properly. Travis mentioned this in his post to python-3000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 From noreply at sourceforge.net Sun Aug 19 12:25:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 03:25:07 -0700 Subject: [ python-Bugs-1777160 ] Please warn about a subtle trap Message-ID: Bugs item #1777160, was opened at 2007-08-19 10:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Please warn about a subtle trap Initial Comment: In python, -1**2 is -1. This will horribly surprise most mathematicians or C programmers where unary - binds very tightly. Such people will expect -1**2 == 1. This problem shows up in scientific contexts, especially Numpy, where an easy way to generate an alternating string of positive and negative numbers is -1**numpy.arange(10). In this example, one expects to produce [1, -1, 1, -1, ...]. So, please put a note in the documentation warning of this problem. It can lead to subtly wrong computations. The appropriate place to put the note is in the Python Reference Manual, section 5.4, The Power operator. Please insert a final line saying: "Note: since the minus sign is not part of a numeric literal, powers of negative numeric constants need to be written with parentheses. Be aware that -1**2 == -(1**2), not (-1)**2." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 From noreply at sourceforge.net Sun Aug 19 12:40:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 03:40:53 -0700 Subject: [ python-Bugs-1777168 ] Confusing typography Python Ref 5.9 Message-ID: Bugs item #1777168, was opened at 2007-08-19 10: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=1777168&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic "opa", "opb" etc reads rather poorly because of a visually confusing choice of names. The bit about "...then a opa b opb c ... y opy z opz" looks more like "aopabopbcopc...yopyzopz" : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. "opa" and "a", then "opb" then "b"), and also by the use of a three-character string to mean "operator a" versus a one-character name for the variable. So, please change "opa" to "A" et cetera, or make some other change that makes it easier to read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 From noreply at sourceforge.net Sun Aug 19 14:49:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 05:49:29 -0700 Subject: [ python-Bugs-1777057 ] memoryview('test') is causing a segfault Message-ID: Bugs item #1777057, was opened at 2007-08-19 03:13 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 >Status: Open Resolution: Fixed Priority: 8 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Neal Norwitz (nnorwitz) Summary: memoryview('test') is causing a segfault Initial Comment: ./python -c "memoryview('test')" Segmentation fault I compiled Python 3.0 with $ ./configure --with-pydebug --enable-unicode=ucs4 and $ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG" after a make clean; rm -rf build; svn up I've used gdb to trace the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210415424 (LWP 14436)] 0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at Python/errors.c:55 55 if (exception != NULL && ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-08-19 14:49 Message: Logged In: YES user_id=560817 Originator: YES I've found another bug: $ ./python -c "memoryview('test')" Fatal Python error: UNREF invalid object Aborted ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-19 06:25 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 57193. This problem was due to not initializing the new BufferError properly. Travis mentioned this in his post to python-3000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 From noreply at sourceforge.net Sun Aug 19 14:54:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 05:54:05 -0700 Subject: [ python-Bugs-1776696 ] tempfile.TemporaryFile differs between platforms Message-ID: Bugs item #1776696, was opened at 2007-08-18 04:31 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenneth Loafman (loafman) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.TemporaryFile differs between platforms Initial Comment: When running the following: import tempfile foo=tempfile.TemporaryFile type(foo) Linux returns: Windows and Cygwin return: It should return the same across platforms, or return an undefined indication if not possible. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-19 14:54 Message: Logged In: YES user_id=560817 Originator: NO It's not a bug. The interface for both types are equal. Python doesn't guarantee that it uses the same types on every platform. It just guarantees that the behavior of the objects are the same on both platforms. Please study tempfile.py for detailed information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776696&group_id=5470 From noreply at sourceforge.net Sun Aug 19 15:02:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 06:02:08 -0700 Subject: [ python-Bugs-1751598 ] struni: str() doesn't call __str__() of subclasses of str Message-ID: Bugs item #1751598, was opened at 2007-07-11 03:48 Message generated for change (Settings changed) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: struni: str() doesn't call __str__() of subclasses of str Initial Comment: In the py3k-struni branch the str() constructor doesn't use __str__ when the argument is an instance of a subclass of str. A user defined string can't change __str__(). It works in Python 2.5 and in the p3yk branch. Python 3.0x (py3k-struni:56245, Jul 10 2007, 23:34:56) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Mystr(str): ... def __str__(self): return 'v' ... >>> s = Mystr('x') >>> s 'x' >>> str(s) 'x' # <- SHOULD RETURN 'v' Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Mystr(str): ... def __str__(self): return 'v' ... >>> s = Mystr('x') >>> s 'x' >>> str(s) 'v' Python 3.0x (p3yk:56180, Jul 6 2007, 23:35:08) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Mystr(str): ... def __str__(self): return 'v' ... >>> s = Mystr('x') >>> s 'x' >>> str(s) 'v' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&group_id=5470 From noreply at sourceforge.net Sun Aug 19 15:56:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 06:56:20 -0700 Subject: [ python-Bugs-1771260 ] Errors in site.py not reported properly Message-ID: Bugs item #1771260, was opened at 2007-08-09 23:37 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) rhamph at factor:~/src/python-p3yk/build$ make object : type : TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the "lost sys.stderr" line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief "stderr unavailable; original exception was ..." message. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-19 15:56 Message: Logged In: YES user_id=560817 Originator: NO I run into trouble with stderr myself and I agree that the problem should be resolved somehow by falling back to the file descriptor 2 (stderr). The current implementation makes it unnecessarily hard to debug problems in site.py, io.py and possible also codecs.*. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-08-10 20:19 Message: Logged In: YES user_id=12364 Originator: YES Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead. That way the callers can add the message about "lost sys.stderr" themselves, rather than it being interspersed in their output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 From noreply at sourceforge.net Sun Aug 19 20:39:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 11:39:44 -0700 Subject: [ python-Bugs-1777057 ] memoryview('test') is causing a segfault Message-ID: Bugs item #1777057, was opened at 2007-08-18 18:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 >Status: Closed Resolution: Fixed Priority: 8 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Neal Norwitz (nnorwitz) Summary: memoryview('test') is causing a segfault Initial Comment: ./python -c "memoryview('test')" Segmentation fault I compiled Python 3.0 with $ ./configure --with-pydebug --enable-unicode=ucs4 and $ make EXTRA_CFLAGS="-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG" after a make clean; rm -rf build; svn up I've used gdb to trace the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210415424 (LWP 14436)] 0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at Python/errors.c:55 55 if (exception != NULL && ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-19 11:39 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 57198 fixes the problem in debug mode. Now a proper exception is generated. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-08-19 05:49 Message: Logged In: YES user_id=560817 Originator: YES I've found another bug: $ ./python -c "memoryview('test')" Fatal Python error: UNREF invalid object Aborted ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-18 21:25 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 57193. This problem was due to not initializing the new BufferError properly. Travis mentioned this in his post to python-3000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777057&group_id=5470 From noreply at sourceforge.net Mon Aug 20 04:56:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 19:56:49 -0700 Subject: [ python-Bugs-1777398 ] IDLE Freezes After Running Scripts Message-ID: Bugs item #1777398, was opened at 2007-08-19 21: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=1777398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ross Peoples (deejross) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE Freezes After Running Scripts Initial Comment: IDLE freezes after running a script in a new window. I'm writing a wxPython script, which runs well until the window is closed, then IDLE freezes (shell and all open windows) and I have to kill the process. It is a tutorial script, so nothing too fancy: import wx class MyFrame(wx.Frame): def __init__(self, parent, id, title): wx.Frame.__init__(self, parent, id, title) menubar = wx.MenuBar() file = wx.Menu() edit = wx.Menu() help = wx.Menu() file.Append(101, "&New") file.Append(102, "&Open", "Open a new document") fileRecent = wx.Menu() fileRecent.Append(10301, "First Item") fileRecent.Append(10302, "Second Item") file.AppendMenu(103, "Open &Recent", fileRecent) file.Append(104, "&Save", "Save the document") file.AppendSeparator() file.Append(105, "E&xit", "Close this window") edit.Append(201, "Check 1", "Check 1 Tooltip", wx.ITEM_CHECK) edit.Append(202, "Check 2", "Check 2 Tooltip", wx.ITEM_CHECK) menubar.Append(file, "&File") menubar.Append(edit, "&Edit") menubar.Append(help, "&Help") self.SetMenuBar(menubar) self.CreateStatusBar() class MyApp(wx.App): def OnInit(self): frame = MyFrame(None, -1, "My Frame") frame.Center() frame.Show(True) return True app = MyApp(0) app.MainLoop() ----------------------------------- It should be noted that usually it freezes after running the script once, but sometimes I can run it a second time before it freezes IDLE. It doesn't seem to freeze using only core Python, only when using wxWidgets. Here are some versions: Ubuntu Gusty Python version 2.5.1 IDLE version 1.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777398&group_id=5470 From noreply at sourceforge.net Mon Aug 20 05:36:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Aug 2007 20:36:14 -0700 Subject: [ python-Bugs-1777412 ] Python's strftime dislikes years before 1900 Message-ID: Bugs item #1777412, was opened at 2007-08-20 13:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777412&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benno Rice (benno) Assigned to: Nobody/Anonymous (nobody) Summary: Python's strftime dislikes years before 1900 Initial Comment: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.date(1876, 2, 3).strftime('%Y-%m-%d') Traceback (most recent call last): File "", line 1, in ValueError: year=1876 is before 1900; the datetime strftime() methods require year >= 1900 Apparently this is due to platform-specific weirdnesses in implementations of strftime. It is still very annoying however. Perhaps a good implementation of strftime could be found and incorporated into Python itself? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777412&group_id=5470 From noreply at sourceforge.net Mon Aug 20 11:23:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 02:23:42 -0700 Subject: [ python-Bugs-1777530 ] ctypes on Solaris Message-ID: Bugs item #1777530, was opened at 2007-08-20 02:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aki (akineko) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes on Solaris Initial Comment: This is not really a bug. ctypes uses 'objdump', which is not available by default. (There are reasons not to install binutil on Solaris) There is no 'objdump' but Solaris has 'elfdump', instead. ctypes.util.py can use 'elfdump' instead of 'objdump'. # cmd = "objdump -p -j .dynamic 2>/dev/null " + f cmd = "elfdump -d 2>/dev/null " + f # res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read()) res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read()) if not res: return None return res.group(2) # <<<--- // ./Modules/_ctypes/libffi/config.guess also uses objdump so that file probably needs to be updated as well. Thank you for your attention. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 From noreply at sourceforge.net Mon Aug 20 09:08:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 00:08:15 -0700 Subject: [ python-Bugs-1777458 ] glob doesn't return unicode with unicode parameter Message-ID: Bugs item #1777458, was opened at 2007-08-20 09: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=1777458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with unicode parameter Initial Comment: Unless I'm not understanding a previous bug report, I see this is a regression of http://sourceforge.net/tracker/index.php?func=detail&aid=1001604&group_id=5470&atid=305470. Here's an interactive session with 2.5.1 on WXP: In [1]: import sys In [2]: sys.version Out[2]: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]' In [3]: import glob In [4]: glob.glob(u"*txt") Out[4]: ['hola.txt', 'ma\xf1ana.txt'] In [5]: glob.glob(u"./*txt") Out[5]: [u'.\\hola.txt', u'.\\ma\xf1ana.txt'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&group_id=5470 From noreply at sourceforge.net Mon Aug 20 23:12:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 14:12:53 -0700 Subject: [ python-Bugs-1759845 ] subprocess.call fails with unicode strings in command line Message-ID: Bugs item #1759845, was opened at 2007-07-24 14:24 Message generated for change (Comment added) made by mclausch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt (mclausch) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.call fails with unicode strings in command line Initial Comment: On Windows, subprocess.call() fails with an exception if either the executable or any of the arguments contain upper level characters. See below: >>> cmd = [ u'test_\xc5_exec.bat', u'arg1', u'arg2' ] >>> subprocess.call(cmd) Traceback (most recent call last): File "", line 1, in File "C:\Python25\lib\subprocess.py", line 443, in call return Popen(*popenargs, **kwargs).wait() File "C:\Python25\lib\subprocess.py", line 593, in __init__ errread, errwrite) File "C:\Python25\lib\subprocess.py", line 815, in _execute_child startupinfo) UnicodeEncodeError: 'ascii' codec can't encode character u'\xc5' in position 5: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Matt (mclausch) Date: 2007-08-20 17:12 Message: Logged In: YES user_id=1852547 Originator: YES Sorry, I should have been more specific. I'm looking for a general solution, not just one for characters in iso-8859-1. For instance, I need to execute a subprocess where the executable or the arguments may contain Japanese characters. So another example would be: cmd = [ u'test_\u65e5\u672c\u8a9e_exec.bat', u'arg1', u'arg2' ] subprocess.call(cmd) ---------------------------------------------------------------------- Comment By: brotchie (brotch) Date: 2007-08-05 04:36 Message: Logged In: YES user_id=1860608 Originator: NO Python's default character coding is 'ascii' which can't convert unicode > 127 into chars. Forcing the unicode string to encode as 'iso-8859-1' eg. subprocess.call(cmd.encode('iso-8859-1')) resolves the problem and runs the correct command. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1759845&group_id=5470 From noreply at sourceforge.net Tue Aug 21 01:20:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 16:20:21 -0700 Subject: [ python-Bugs-1778207 ] rounding inconsisntency using string formatting Message-ID: Bugs item #1778207, was opened at 2007-08-20 16: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=1778207&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print "%9.4f" % (229.0 * .325,) -> 74.4250 correct print "%9.2f" % (round(74.425, 2),) -> 74.43 correct print "%9.2f" % (74.425,) -> 74.42 wrong print "%9.2f" % (167.255,) -> 167.26 correct print "%9.2f" % (167.2551,) -> 167.26 correct print "%9.2f" % (167.2549,) -> 167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be "Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 From noreply at sourceforge.net Tue Aug 21 03:02:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 18:02:43 -0700 Subject: [ python-Bugs-1778207 ] rounding inconsisntency using string formatting Message-ID: Bugs item #1778207, was opened at 2007-08-20 23:20 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print "%9.4f" % (229.0 * .325,) -> 74.4250 correct print "%9.2f" % (round(74.425, 2),) -> 74.43 correct print "%9.2f" % (74.425,) -> 74.42 wrong print "%9.2f" % (167.255,) -> 167.26 correct print "%9.2f" % (167.2551,) -> 167.26 correct print "%9.2f" % (167.2549,) -> 167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be "Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-21 01:02 Message: Logged In: YES user_id=703403 Originator: NO This isn't really a bug---it's just one of those unavoidable things that happens when you're representing decimals using binary floating point: take a look at section 4.3 of the General Python FAQ: http://www.python.org/doc/faq/general/ If anything *is* wrong here it's actually the round() result, not the string formatting: 74.425 isn't exactly representable as a binary floating-point number, so Python (like most other languages) approximates it by the closest number that *is* exactly representable, which is (on my machine and probably yours too): 74.4249999999999971578290569595992565155029296875 Since this is less than 74.425, the round function would, in an ideal world, round this down to 74.42 instead of up to 74.43. In the absence of an ideal world, making this sort of thing happen reliably and portably is hard, and I'd guess that round() is unlikely to change. Have you looked at the decimal module in the standard library? It sounds as though you might find it useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 From noreply at sourceforge.net Tue Aug 21 03:15:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 18:15:12 -0700 Subject: [ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs Message-ID: Bugs item #1093389, was opened at 2004-12-31 05:36 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No 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. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-08-21 11:15 Message: Logged In: YES user_id=14198 Originator: NO This should be in the pywin32 collector, and should also be resolved in recent pywin32 builds, where either form will be accepted when being passed to MAPI. ---------------------------------------------------------------------- Comment By: Joe Hildebrand (hildjj) Date: 2005-09-20 09:43 Message: Logged In: YES user_id=101697 For example, you could use this (awful hack): def PROP_TAG(ulPropType,ulPropID): a = (ulPropID<<16)|(ulPropType) if ulPropID & 0x8000: a = int(-((a ^ 0xffffffff) + 1)) return a mostly posted here so i can google for it next time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 From noreply at sourceforge.net Tue Aug 21 03:18:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 18:18:53 -0700 Subject: [ python-Bugs-926910 ] Overenthusiastic check in Swap? Message-ID: Bugs item #926910, was opened at 2004-04-01 05:34 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926910&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: benson margulies (benson_basis) Assigned to: Mark Hammond (mhammond) Summary: Overenthusiastic check in Swap? Initial Comment: When Py_DEBUG is turned on, PyThreadState_Swap calls in a fatal error if the two different thread states are ever used for a thread. I submit that this is not a good check. The documentation encourages us to write code that creates and destroys thread states as C threads come and go. Why can't a single C thread make a thread state, release it, and then make another one later? One particular usage pattern: We have an API that initializes embedded python. Then we have another API where the callers are allowed to be in any C thread. The second API has no easy way to tell if a thread used for it happens to be the same thread that made the initialization call. As the code is written now, any code running on the 'main thread' is required to fish out the build-in main-thread thread state. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-08-21 11:18 Message: Logged In: YES user_id=14198 Originator: NO The docs probably could be improved, but for now, this bug as reported is not going to be fixed. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2004-06-08 00:20 Message: Logged In: YES user_id=876734 Somehow, the path I took through the documentation failed to rub my nose in this. It would be good if the language from the original PEP was applied to the APIs that I coded to to warn people to use these other APIs instead. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-06-07 17:22 Message: Logged In: YES user_id=14198 That check should not fail if you use the PyGILState APIs - it manages all of this for you. The PyGILState functions were added to handle exactly what you describe as your use case - is there any reason you can't use them? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-07 15:15 Message: Logged In: YES user_id=80475 Mark, I believe this is your code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926910&group_id=5470 From noreply at sourceforge.net Tue Aug 21 07:59:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 22:59:29 -0700 Subject: [ python-Bugs-1777530 ] ctypes on Solaris Message-ID: Bugs item #1777530, was opened at 2007-08-20 02:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aki (akineko) >Assigned to: Thomas Heller (theller) Summary: ctypes on Solaris Initial Comment: This is not really a bug. ctypes uses 'objdump', which is not available by default. (There are reasons not to install binutil on Solaris) There is no 'objdump' but Solaris has 'elfdump', instead. ctypes.util.py can use 'elfdump' instead of 'objdump'. # cmd = "objdump -p -j .dynamic 2>/dev/null " + f cmd = "elfdump -d 2>/dev/null " + f # res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read()) res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read()) if not res: return None return res.group(2) # <<<--- // ./Modules/_ctypes/libffi/config.guess also uses objdump so that file probably needs to be updated as well. Thank you for your attention. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-20 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777530&group_id=5470 From noreply at sourceforge.net Tue Aug 21 08:07:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 23:07:49 -0700 Subject: [ python-Bugs-1777160 ] Please warn about a subtle trap Message-ID: Bugs item #1777160, was opened at 2007-08-19 10:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Please warn about a subtle trap Initial Comment: In python, -1**2 is -1. This will horribly surprise most mathematicians or C programmers where unary - binds very tightly. Such people will expect -1**2 == 1. This problem shows up in scientific contexts, especially Numpy, where an easy way to generate an alternating string of positive and negative numbers is -1**numpy.arange(10). In this example, one expects to produce [1, -1, 1, -1, ...]. So, please put a note in the documentation warning of this problem. It can lead to subtly wrong computations. The appropriate place to put the note is in the Python Reference Manual, section 5.4, The Power operator. Please insert a final line saying: "Note: since the minus sign is not part of a numeric literal, powers of negative numeric constants need to be written with parentheses. Be aware that -1**2 == -(1**2), not (-1)**2." ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:07 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57255. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777160&group_id=5470 From noreply at sourceforge.net Tue Aug 21 08:12:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 23:12:37 -0700 Subject: [ python-Bugs-1777168 ] Confusing typography Python Ref 5.9 Message-ID: Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic "opa", "opb" etc reads rather poorly because of a visually confusing choice of names. The bit about "...then a opa b opb c ... y opy z opz" looks more like "aopabopbcopc...yopyzopz" : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. "opa" and "a", then "opb" then "b"), and also by the use of a three-character string to mean "operator a" versus a one-character name for the variable. So, please change "opa" to "A" et cetera, or make some other change that makes it easier to read. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 From noreply at sourceforge.net Tue Aug 21 08:12:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Aug 2007 23:12:56 -0700 Subject: [ python-Bugs-1777168 ] Confusing typography Python Ref 5.9 Message-ID: Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic "opa", "opb" etc reads rather poorly because of a visually confusing choice of names. The bit about "...then a opa b opb c ... y opy z opz" looks more like "aopabopbcopc...yopyzopz" : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. "opa" and "a", then "opb" then "b"), and also by the use of a three-character string to mean "operator a" versus a one-character name for the variable. So, please change "opa" to "A" et cetera, or make some other change that makes it easier to read. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777168&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:08:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:08:21 -0700 Subject: [ python-Bugs-1778376 ] Segfault. Message-ID: Bugs item #1778376, was opened at 2007-08-21 10: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=1778376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault. Initial Comment: On linux box this piece of code segfaults (CPy 2.5.1) while 1: f = open("/tmp/dupa", "w") thread.start_new_thread(f.close, ()) f.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778376&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:15:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:15:46 -0700 Subject: [ python-Feature Requests-1777412 ] Python's strftime dislikes years before 1900 Message-ID: Feature Requests item #1777412, was opened at 2007-08-20 05:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1777412&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benno Rice (benno) Assigned to: Nobody/Anonymous (nobody) Summary: Python's strftime dislikes years before 1900 Initial Comment: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.date(1876, 2, 3).strftime('%Y-%m-%d') Traceback (most recent call last): File "", line 1, in ValueError: year=1876 is before 1900; the datetime strftime() methods require year >= 1900 Apparently this is due to platform-specific weirdnesses in implementations of strftime. It is still very annoying however. Perhaps a good implementation of strftime could be found and incorporated into Python itself? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-08-21 10:15 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug report, but a feature request. Python works correctly as-is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1777412&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:18:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:18:47 -0700 Subject: [ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory Message-ID: Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep/0000/0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:27:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:27:53 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 10:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) >Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-08-21 10:27 Message: Logged In: YES user_id=21627 Originator: NO Fredrik, can you please comment? If not, unassign. ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2007-08-14 08:23 Message: Logged In: YES user_id=1534394 Originator: YES Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that matching allocator and deallocator functions are used. I installed PyXML-0.8.4 from source ("python setup.py install" on Win32 which picked up the C compiler from MSVS7.1). The cause of the problem is quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL are used together): http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I guess they weren't keeping in sync with each other. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-14 05:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2007-08-14 03:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 13:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:43:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:43:34 -0700 Subject: [ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed Message-ID: Bugs item #1772916, was opened at 2007-08-13 10:15 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) >Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 10:43 Message: Logged In: YES user_id=38376 Originator: NO I don't really have an opinion here; the best solution would of course be to find someone that cares enough about PyXML to cut a bugfix release, it's probably easiest to just remove it (or disable, with a note that it can be re-enabled if you have a stable version of sgmlop). I'm tempted to suggest removing SlowParser as well, but there might be some hackers on very small devices that rely on that one. (Ideally, someone should sit down and rewrite the Unmarshaller to use xml.etree.cElementTree's iterparse function instead. Contact me if you're interested). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-08-21 10:27 Message: Logged In: YES user_id=21627 Originator: NO Fredrik, can you please comment? If not, unassign. ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2007-08-14 08:23 Message: Logged In: YES user_id=1534394 Originator: YES Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that matching allocator and deallocator functions are used. I installed PyXML-0.8.4 from source ("python setup.py install" on Win32 which picked up the C compiler from MSVS7.1). The cause of the problem is quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL are used together): http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I guess they weren't keeping in sync with each other. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-14 05:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2007-08-14 03:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 13:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:48:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:48:42 -0700 Subject: [ python-Bugs-1772788 ] chr(128) in u'only ascii' -> TypeError with misleading msg Message-ID: Bugs item #1772788, was opened at 2007-08-13 00:54 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' -> TypeError with misleading msg Initial Comment: A test using in format "chr(x) in " raises a TypeError if "x" is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> chr(127) in 'hello' False >>> chr(128) in 'hello' False >>> chr(127) in u'hi' False >>> chr(128) in u'hi' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using "in " format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. >>> chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. >>> type(chr(128)) A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 10:48 Message: Logged In: YES user_id=38376 Originator: NO "Most other string operations work nicely between normal and unicode strings" Nope. You *always* get errors if you mix Unicode with NON-ASCII data (unless you've messed up the system's default encoding, which is a bad thing to do if you care about portability). Some examples: >>> chr(128) + u"foo" UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) >>> u"foo".find(chr(128)) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) etc. If there's a bug here, it's that you get a TypeError instead of a ValueError subclass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 From noreply at sourceforge.net Tue Aug 21 10:49:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 01:49:42 -0700 Subject: [ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory Message-ID: Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep/0000/0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 From noreply at sourceforge.net Tue Aug 21 12:06:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 03:06:34 -0700 Subject: [ python-Bugs-1778376 ] Segfault closing a file from concurrent threads Message-ID: Bugs item #1778376, was opened at 2007-08-21 08:08 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) >Summary: Segfault closing a file from concurrent threads Initial Comment: On linux box this piece of code segfaults (CPy 2.5.1) while 1: f = open("/tmp/dupa", "w") thread.start_new_thread(f.close, ()) f.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778376&group_id=5470 From noreply at sourceforge.net Tue Aug 21 16:03:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 07:03:01 -0700 Subject: [ python-Bugs-1772788 ] chr(128) in u'only ascii' -> TypeError with misleading msg Message-ID: Bugs item #1772788, was opened at 2007-08-13 01:54 Message generated for change (Comment added) made by laukpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' -> TypeError with misleading msg Initial Comment: A test using in format "chr(x) in " raises a TypeError if "x" is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> chr(127) in 'hello' False >>> chr(128) in 'hello' False >>> chr(127) in u'hi' False >>> chr(128) in u'hi' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using "in " format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. >>> chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. >>> type(chr(128)) A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. ---------------------------------------------------------------------- >Comment By: Pekka Laukkanen (laukpe) Date: 2007-08-21 17:03 Message: Logged In: YES user_id=1379331 Originator: YES Fredrik, you are obviously correct that most operations between normal and unicode strings don't work if the normal string contains non-ascii data. I still do think that a UnicodeWarning like you get from "chr(128) == u'foo'" would be nicer than an exception and prevent problems like the one in telnetlib [1]. If an exception is raised I don't care too much about its type but a better message would make debugging possible problems easier. [1] https://sourceforge.net/tracker/index.php?func=detail&aid=1772794&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 11:48 Message: Logged In: YES user_id=38376 Originator: NO "Most other string operations work nicely between normal and unicode strings" Nope. You *always* get errors if you mix Unicode with NON-ASCII data (unless you've messed up the system's default encoding, which is a bad thing to do if you care about portability). Some examples: >>> chr(128) + u"foo" UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) >>> u"foo".find(chr(128)) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) etc. If there's a bug here, it's that you get a TypeError instead of a ValueError subclass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 From noreply at sourceforge.net Tue Aug 21 19:31:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 10:31:49 -0700 Subject: [ python-Bugs-1777458 ] glob doesn't return unicode with unicode parameter Message-ID: Bugs item #1777458, was opened at 2007-08-20 12:38 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with unicode parameter Initial Comment: Unless I'm not understanding a previous bug report, I see this is a regression of http://sourceforge.net/tracker/index.php?func=detail&aid=1001604&group_id=5470&atid=305470. Here's an interactive session with 2.5.1 on WXP: In [1]: import sys In [2]: sys.version Out[2]: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]' In [3]: import glob In [4]: glob.glob(u"*txt") Out[4]: ['hola.txt', 'ma\xf1ana.txt'] In [5]: glob.glob(u"./*txt") Out[5]: [u'.\\hola.txt', u'.\\ma\xf1ana.txt'] ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-21 23:01 Message: Logged In: YES user_id=942711 Originator: NO This seems very much windows specific (someone needs to test on mac/other os as well). On linux, verified that glob unicode-in, unicode-out works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&group_id=5470 From noreply at sourceforge.net Wed Aug 22 03:29:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 18:29:11 -0700 Subject: [ python-Bugs-839151 ] attempt to access sys.argv when it doesn\'t exist Message-ID: Bugs item #839151, was opened at 2003-11-10 02:56 Message generated for change (Comment added) made by ngrover You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Bram Moolenaar (vimboss) Assigned to: Georg Brandl (gbrandl) Summary: attempt to access sys.argv when it doesn\'t exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. ---------------------------------------------------------------------- Comment By: Nishkar Grover (ngrover) Date: 2007-08-21 18:29 Message: Logged In: YES user_id=1656248 Originator: NO In addition to catching AttributeError in case sys.argv doesn't exist, this should also catch IndexError and TypeError in case sys.argv is an empty list or it is not even a list at all. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-26 15:55 Message: Logged In: YES user_id=1188172 Thanks for the report; this is fixed as of Lib/warnings.py r1.27, r1.24.2.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:23 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File "<stdin>", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:22 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File "<stdin>", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 07:02 Message: Logged In: YES user_id=33168 Just to provide a reference, 839200 was a duplicate of this report. I closed 839200. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 From noreply at sourceforge.net Wed Aug 22 07:56:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 22:56:42 -0700 Subject: [ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory Message-ID: Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-08-22 07:56 Message: Logged In: YES user_id=21627 Originator: NO Can you please explain what specifically you consider a bug here? I can see that the error message is confusing, so it could be improved. However, there is nothing we can do to make the error go away. The Microsoft C library simply does not support file names longer than MAX_PATH; you have to use Unicode file names to go beyond this limit. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep/0000/0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 From noreply at sourceforge.net Wed Aug 22 08:01:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 23:01:52 -0700 Subject: [ python-Bugs-1778207 ] rounding inconsisntency using string formatting Message-ID: Bugs item #1778207, was opened at 2007-08-21 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print "%9.4f" % (229.0 * .325,) -> 74.4250 correct print "%9.2f" % (round(74.425, 2),) -> 74.43 correct print "%9.2f" % (74.425,) -> 74.42 wrong print "%9.2f" % (167.255,) -> 167.26 correct print "%9.2f" % (167.2551,) -> 167.26 correct print "%9.2f" % (167.2549,) -> 167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be "Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-08-22 08:01 Message: Logged In: YES user_id=21627 Originator: NO As marketdickinson explains, this is not a bug - at least the line you consider "wrong" does not show a bug. 74.425 is indeed smaller than 74+425/1000, so it's correct that rounding rounds down. As for documentation, please take a look at http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate Closing as invalid. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-21 03:02 Message: Logged In: YES user_id=703403 Originator: NO This isn't really a bug---it's just one of those unavoidable things that happens when you're representing decimals using binary floating point: take a look at section 4.3 of the General Python FAQ: http://www.python.org/doc/faq/general/ If anything *is* wrong here it's actually the round() result, not the string formatting: 74.425 isn't exactly representable as a binary floating-point number, so Python (like most other languages) approximates it by the closest number that *is* exactly representable, which is (on my machine and probably yours too): 74.4249999999999971578290569595992565155029296875 Since this is less than 74.425, the round function would, in an ideal world, round this down to 74.42 instead of up to 74.43. In the absence of an ideal world, making this sort of thing happen reliably and portably is hard, and I'd guess that round() is unlikely to change. Have you looked at the decimal module in the standard library? It sounds as though you might find it useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 From noreply at sourceforge.net Wed Aug 22 08:36:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 23:36:56 -0700 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-23 03:22 Message generated for change (Comment added) made by huangpeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:36 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 14:05 Message: Logged In: YES user_id=33168 The patch just needs some attention (testing and possible fixes) on Windows. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-29 13:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 07:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 04:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 00:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Wed Aug 22 08:38:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Aug 2007 23:38:52 -0700 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-23 03:22 Message generated for change (Comment added) made by huangpeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:38 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. ---------------------------------------------------------------------- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:36 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 14:05 Message: Logged In: YES user_id=33168 The patch just needs some attention (testing and possible fixes) on Windows. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-29 13:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 07:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 04:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 00:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Wed Aug 22 09:49:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 00:49:19 -0700 Subject: [ python-Bugs-1779233 ] PyThreadState_SetAsyncExc and the main thread Message-ID: Bugs item #1779233, was opened at 2007-08-22 10: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=1779233&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rotem (rotem_yaari) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_SetAsyncExc and the main thread Initial Comment: Hi, The following does not work in python 2.5: ############################################## import ctypes import thread res = ctypes.pythonapi.PyThreadState_SetAsyncExc( thread.get_ident(), ctypes.py_object(SystemExit)) ############################################## Although according to my understanding this should "schedule" an async exception for the main thread, it does not (res receives the value of 0). When raising exceptions in other threads in this way, it works and the call to PyThreadState_SetAsyncExc returns 1 like it should. Doing so on the main thread doesn't seem to work, even when performed from threads other than the main one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1779233&group_id=5470 From noreply at sourceforge.net Wed Aug 22 12:26:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 03:26:29 -0700 Subject: [ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory Message-ID: Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-08-22 12:26 Message: Logged In: YES user_id=51702 Originator: YES Yes, it is the error message and the exception that is the problem. First, it shouldn't raise TypeError (which indicates a programming error), it should raise either IOError, OSError or WindowsError. Second, the exception message is whacky: "listdir() argument 1 must be (buffer overflow), not str" I realize that it is probably impossible to detect this specific error condition but I still want something more explanatory than what it currently is. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-08-22 07:56 Message: Logged In: YES user_id=21627 Originator: NO Can you please explain what specifically you consider a bug here? I can see that the error message is confusing, so it could be improved. However, there is nothing we can do to make the error go away. The Microsoft C library simply does not support file names longer than MAX_PATH; you have to use Unicode file names to go beyond this limit. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep/0000/0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 From report at bugs.python.org Wed Aug 22 15:28:31 2007 From: report at bugs.python.org (user) Date: Wed, 22 Aug 2007 13:28:31 -0000 Subject: [issue1000] test Message-ID: <1187789311.7.0.365576874965.issue1000@psf.upfronthosting.co.za> New submission from user: test patch ---------- files: python.diff messages: 55112 nosy: user severity: normal status: open title: test __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: python.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070822/b919b435/attachment.txt From report at bugs.python.org Wed Aug 22 15:28:32 2007 From: report at bugs.python.org (user) Date: Wed, 22 Aug 2007 13:28:32 -0000 Subject: [issue1000] test Message-ID: <1187789311.7.0.365576874965.issue1000@psf.upfronthosting.co.za> New submission from user: test patch ---------- files: python.diff messages: 55112 nosy: user severity: normal status: open title: test __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: python.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070822/b919b435/attachment-0001.txt From report at bugs.python.org Wed Aug 22 15:28:47 2007 From: report at bugs.python.org (user) Date: Wed, 22 Aug 2007 13:28:47 -0000 Subject: [issue1000] test Message-ID: <1187789327.04.0.886347611675.issue1000@psf.upfronthosting.co.za> Changes by user: ---------- type: -> rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 22 15:44:58 2007 From: report at bugs.python.org (user) Date: Wed, 22 Aug 2007 13:44:58 -0000 Subject: [issue1001] Test 2 Message-ID: <1187790298.77.0.558164647785.issue1001@psf.upfronthosting.co.za> Changes by user: ---------- severity: normal status: open title: Test 2 __________________________________ Tracker __________________________________ From noreply at sourceforge.net Wed Aug 22 19:53:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 10:53:49 -0700 Subject: [ python-Bugs-1731717 ] race condition in subprocess module Message-ID: Bugs item #1731717, was opened at 2007-06-06 00:19 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dsagal (dsagal) Assigned to: Peter ?strand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global "_cleanup()" function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object "foo" in one thread, and then a.wait(), and meanwhile I create another Popen object "bar" in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("/bin/ls", "-a", "/tmp"), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "z.py", line 21, in tt s.communicate()[0] File "/usr/lib/python2.4/subprocess.py", line 1083, in communicate self.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2007-08-22 19:53 Message: Logged In: YES user_id=769182 Originator: NO There should be test cases aplenty - this bug was first reported in March 2006 and this is one of four incarnations of it. See also 1753891, 1754642, 1183780 I think all of these contain testcases (though two roughly coincide) and any fix would be wise to try them all out... ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-06 22:02 Message: Logged In: YES user_id=344921 Originator: NO >I can create a patch to make current head a bit cleaner, if anyone is >interested... Sure, this would be great. I would also love a test case that reproduces this problem. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-06 21:45 Message: Logged In: YES user_id=10273 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 23:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much "thread safe" as "thread robust". I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back if it is still not finished. However, as it is now it looks like it is fixed... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 22:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 21:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made threadsafe. To be truely threadsafe it also needs to make sure that _active contains only abandoned popen instances so that _cleanup() doesn't have it's inst.poll() calls collide with other threads that are still using those popen instances. This can be done by havin the popen instances added to _active only by Popen.__del__(), and only removed by _cleanup() when they are done. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-03 21:14 Message: Logged In: YES user_id=10273 Originator: NO I just looked at popen2 and it has the same bug. I don't think __del__() related changes have anything to do with this. Popen.poll() and _cleanup() are non-threadsafe. When __init__() is called to create subprocesses simultaniously in two different threads, they both call _cleanup() and trample all over each other. Removing _cleanup() will not leave zombies for popened processes that are correctly handled to completion. Using methods like communicate() and wait() will handle the process to completion and reap the child. Unfortunately, I think a fairly common use-case is people using popen to fire-and-forget subprocesses without using communicate() or wait(). These will not get reaped, and will end up as zombies. I cannot think of an easy way to reap abandoned popen instances that is thread safe without using locks. At times like this I wish that the GIL was exposed as a recursive lock... we could have __cleanup__() acquire/release the GIL and make it atomic... no more race condition :-) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2007-08-02 11:15 Message: Logged In: YES user_id=344921 Originator: NO Suddenly starting to leave Zombies is NOT an option for me. To prevent zombies, all applications using the subprocess module would need to be changed. This is a major breakage of backwards compatibility, IMHO. subprocess (as well as the popen2 module) has prevented zombies automatically from the beginning and I believe they should continue to do so (at least by default). A little bit of history: When I wrote the subprocess module, I stole the idea of calling _cleanup whenever a new instance is created from the popen2 module, since I thought it was nice, lightweight and avoided having a __del__ method (which I have some bad experience with, GC-related). This worked great for a long time. At 2006-04-10, however, martin.v.loewis committed patch 1467770 (revision r45234), to solve bug 1460493. It introduces a __del__ method and some more complexity. I must admit that I didn't review this patch in detail, but it looked like thread safeness was being taken care of. But apparently it isn't. Perhaps reverting to the original popen2 approach would solve the problem? Or does the popen2 module suffer from this bug as well? I think that we need to fix this once and for all, this time. We should probably also consider adding the option of not having subprocess auto-wait while we are at it, for those what would like to wait() themselves (there should be a tracker item for this, but I can't find it right now). Are we tight on time for fixing this bug? I'm out in the forest right now... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-02 02:45 Message: Logged In: YES user_id=6380 Originator: NO I like #2. I don't see any use for threadsafe Popen instances, and I think that any self-respecting long-running server using Popen should properly manage its subprocesses anyway. (And for short-running processes it doesn't really matter if you have a few zombies.) One could add a __del__ method that registers zombies to be reaped later, but I don't think it's worth it, and __del__ has some serious issues of its own. (If you really want to do this, use a weak reference callback instead of __del__ to do the zombie registration.) ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 19:37 Message: Logged In: YES user_id=10273 Originator: NO Having just gone through that waffly description of the problems and various levels of fix, I think there are really only two fixes worth considering; 1) Make Popen instances fully threadsafe. Give them a recursive lock attribute and have every method acquire the lock at the start, and release it at the end. 2) Decide the "try to reap abandoned children at each Popen" idea was an ugly hack and abandon it. Remove _active and _cleanup(), and document that any child process not explicitly handled to completion will result in zombie child processes. ---------------------------------------------------------------------- Comment By: Donovan Baarda (abo) Date: 2007-08-01 19:05 Message: Logged In: YES user_id=10273 Originator: NO It appears that subprocess calls a module global "_cleanup()" whenever opening a new subprocess. This method is meant to reap any child processes that have terminated and have not explicitly cleaned up. These are processes you would expect to be cleaned up by GC, however, subprocess keeps a list of of all spawned subprocesses in _active until they are reaped explicitly so it can cleanup any that nolonger referenced anywhere else. The problem is lots of methods, including poll() and wait(), check self.returncode and then modify it. Any non-atomic read/modify action is inherently non-threadsafe. And _cleanup() calls poll() on all un-reaped child processes. If two threads happen to try and spawn subprocesses at once, these _cleanup() calls collide.. The way to fix this depends on how thread-safe you want to make it. If you want to share popen objects between threads to wait()/poll() with impunity from any thread, you should add a recursive lock attribute to the Popen instance and have it lock/release it at the start/end of every method call. If you only care about using popen objects in one thread at a time, then all you need to fix is the nasty "every popen created calls poll() on every other living popen object regardless of what thread started them, and poll() is not threadsafe" behaviour. Removing _cleanup() is one way, but it will then not reap child processes that you del'ed all references to (except the one in subprocess._active) before you checked they were done. Probably another good idea is to not append and remove popen objects to _active directly, instead and add a popen.__del__() method that defers GC'ing of non-finished popen objects by adding them to _active. This way, _active only contains un-reaped child processes that were due to be GC'ed. _cleanup() will then be responsible for polling and removing these popen objects from _active when they are done. However, this alone will not fix things because you are still calling _cleanup() from different threads, it is still calling poll() on all these un-reaped processes, and poll() is not threadsafe. So... you either have to make poll() threadsafe (lock/unlock at the beginning/end of the method), or make _cleanup() threadsafe. The reason you can get away with making only _cleanup() threadsafe this way is _active will contain a list of processes that are not referenced anywhere else, so you know the only thing that will call poll() on them is the _cleanup() method. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-07 07:26 Message: Logged In: YES user_id=33168 Originator: NO Peter, could you take a look at this? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731717&group_id=5470 From noreply at sourceforge.net Wed Aug 22 21:57:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Aug 2007 12:57:03 -0700 Subject: [ python-Bugs-1779700 ] urlparse.urljoin does not obey current uri rfc (rfc 3986) Message-ID: Bugs item #1779700, was opened at 2007-08-22 12:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1779700&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Adams (icosine) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse.urljoin does not obey current uri rfc (rfc 3986) Initial Comment: First, there are a lot of RFC's. The latest is RFC3986 (see http://en.wikipedia.org/wiki/Uniform_Resource_Identifier) A base url of the form: http://a/b/c/d;p?q when resolved with a relative link of the form: ?y resolves to: http://a/b/c/?q rather than: http://a/b/c/d;p?q It may seem that this doesn't matter, but try this in firefox or IE and you'll see that they exhibit the up-to-date correct behavior. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1779700&group_id=5470 From noreply at sourceforge.net Thu Aug 23 16:00:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Aug 2007 07:00:57 -0700 Subject: [ python-Bugs-1757057 ] IDLE + BeautifulSoup = Error Message-ID: Bugs item #1757057, was opened at 2007-07-19 20:17 Message generated for change (Comment added) made by altherac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1757057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE + BeautifulSoup = Error Initial Comment: This bug manifests only when running with a subprocess. Trying to display an instance of BeautifulSoup's NavigableString class, this is the result: RuntimeError: maximum recursion depth exceeded See http://mail.python.org/pipermail/idle-dev/2007-July/002600.html for details (including how to recreate the error). Diagnosis: The problem arises when trying to pickle such instances - pickle enters an endless loop and reaches the max recursion limit (eventually). This happens regardless of the protocol used. IDLE is probably trying to pickle them because their class, NavigableString, inherits from unicode, so isinstance(, basestring) return True. Possibly related to SF bug #1581183: "pickle protocol 2 failure on int subclass" http://sourceforge.net/tracker/index.php?funchttp://sourceforge.net/tracker/index.php?func=detail&aid=1581183&group_id=5470&atid=105470=detail&aid=1512695&group_id=5470&atid=105470 Fix: IDLE should check for any exception when trying to pickle, not just pickle.PicklingError, to avoid such errors. If pickle doesn't work, for whatever reason, IDLE can still work around it with str() and repr(). I'll post a bug report for Pickle as well. ---------------------------------------------------------------------- Comment By: Christophe Michel (altherac) Date: 2007-08-23 16:00 Message: Logged In: YES user_id=562686 Originator: NO Let's use the following sample code. It's the most minimalistic one, and isolates the cause of the bug. ----------8<----------8<---------- #!/usr/bin/env python import pickle, sys class EvilString(unicode): def __unicode__(self): return self n = EvilString("") pickle.dump(n, sys.stdout) ----------8<----------8<---------- The evil recursion proceeds as follows : >> File "C:\Python25\lib\pickle.py", line 1364, in dump >> Pickler(file, protocol).dump(obj) Initial call to dump(), as intended. >> File "C:\Python25\lib\pickle.py", line 224, in dump >> self.save(obj) save() calls obj.__reduce_ex(), obj being our EvilString instance. This function is defined in copyreg.py, line 58 and following my example, returns a tuple containing three elements: 1) the _reconstructor function, as defined in copyreg.py, line 46 2) a tuple : (, , <'__main__.EvilString' instance at 0xXXXXXXXX>) First element is the actual class of obj, second is the base class, and third is the current instance (known as state). 3) an empty dict {} >> File "C:\Python25\lib\pickle.py", line 331, in save >> self.save_reduce(obj=obj, *rv) save_reduce() calls self.save() twice: - first on the func argument, which is the _reconstructor function. This call works as intended - next on the tuple (, , <'__main__.EvilString' instance at 0xXXXXXXXX>) >> File "C:\Python25\lib\pickle.py", line 403, in save_reduce >> save(args) >> File "C:\Python25\lib\pickle.py", line 286, in save >> f(self, obj) # Call unbound method with explicit self save() finds out its argument is a Tuple, and calls save_tuple() appropriately >> File "C:\Python25\lib\pickle.py", line 564, in save_tuple >> save(element) ... and save_tuple() calls save() on each element of the tuple. See what's wrong ? This means calling save() again on the EvilString instance. Which, in turn, will call save_reduce() on it, and so on. The problem lies in _reduce_ex(), in the definition of the state of the object: copyreg.py, lines 65 to 70: if base is object: state = None else: if base is self.__class__: raise TypeError, "can't pickle %s objects" % base.__name__ state = base(self) When this code gets executed on an EvilString instance, base is the type 'unicode'. Since it's not an object, and since it's not the actual class EvilString either, the following line gets executed: state=base(self) Which corresponds to unicode(self), or self.__unicode__, which returns an EvilString instance, not a variable of type unicode. And there starts the recursion. I don't know if this is flaw in the design of _reduce_ex, or a flaw inherent to having __unicode__(self) returning self. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1757057&group_id=5470 From noreply at sourceforge.net Thu Aug 23 16:02:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Aug 2007 07:02:02 -0700 Subject: [ python-Bugs-1757062 ] Pickle fails on BeautifulSoup's navigableString instances Message-ID: Bugs item #1757062, was opened at 2007-07-19 20:23 Message generated for change (Comment added) made by altherac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1757062&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle fails on BeautifulSoup's navigableString instances Initial Comment: Trying to pickle an instance of BeautifulSoup's NavigableString class, this is the result: "RuntimeError: maximum recursion depth exceeded" Diagnosis: The problem arises when trying to pickle such instances - pickle enters an endless loop and reaches the max recursion limit (eventually). This happens regardless of the protocol used. Possibly related to SF bug #1581183: "pickle protocol 2 failure on int subclass" http://sourceforge.net/tracker/index.php?funchttp://sourceforge.net/tracker/index.php?func=detail&aid=1581183&group_id=5470&atid=105470=detail&aid=1512695&group_id=5470&atid=105470 See http://mail.python.org/pipermail/idle-dev/2007-July/002600.html (originally a bug report for IDLE on the IDLE-dev list) for details (including how to recreate the error). Related IDLE bug report: #1757057 https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1757057&group_id=5470 ---------------------------------------------------------------------- Comment By: Christophe Michel (altherac) Date: 2007-08-23 16:02 Message: Logged In: YES user_id=562686 Originator: NO Let's use the following sample code. It's the most minimalistic one, and isolates the cause of the bug. ----------8<----------8<---------- #!/usr/bin/env python import pickle, sys class EvilString(unicode): def __unicode__(self): return self n = EvilString("") pickle.dump(n, sys.stdout) ----------8<----------8<---------- The evil recursion proceeds as follows : >> File "C:\Python25\lib\pickle.py", line 1364, in dump >> Pickler(file, protocol).dump(obj) Initial call to dump(), as intended. >> File "C:\Python25\lib\pickle.py", line 224, in dump >> self.save(obj) save() calls obj.__reduce_ex(), obj being our EvilString instance. This function is defined in copyreg.py, line 58 and following my example, returns a tuple containing three elements: 1) the _reconstructor function, as defined in copyreg.py, line 46 2) a tuple : (, , <'__main__.EvilString' instance at 0xXXXXXXXX>) First element is the actual class of obj, second is the base class, and third is the current instance (known as state). 3) an empty dict {} >> File "C:\Python25\lib\pickle.py", line 331, in save >> self.save_reduce(obj=obj, *rv) save_reduce() calls self.save() twice: - first on the func argument, which is the _reconstructor function. This call works as intended - next on the tuple (, , <'__main__.EvilString' instance at 0xXXXXXXXX>) >> File "C:\Python25\lib\pickle.py", line 403, in save_reduce >> save(args) >> File "C:\Python25\lib\pickle.py", line 286, in save >> f(self, obj) # Call unbound method with explicit self save() finds out its argument is a Tuple, and calls save_tuple() appropriately >> File "C:\Python25\lib\pickle.py", line 564, in save_tuple >> save(element) ... and save_tuple() calls save() on each element of the tuple. See what's wrong ? This means calling save() again on the EvilString instance. Which, in turn, will call save_reduce() on it, and so on. The problem lies in _reduce_ex(), in the definition of the state of the object: copyreg.py, lines 65 to 70: if base is object: state = None else: if base is self.__class__: raise TypeError, "can't pickle %s objects" % base.__name__ state = base(self) When this code gets executed on an EvilString instance, base is the type 'unicode'. Since it's not an object, and since it's not the actual class EvilString either, the following line gets executed: state=base(self) Which corresponds to unicode(self), or self.__unicode__, which returns an EvilString instance, not a variable of type unicode. And there starts the recursion. I don't know if this is flaw in the design of _reduce_ex, or a flaw inherent to having __unicode__(self) returning self. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1757062&group_id=5470 From report at bugs.python.org Thu Aug 23 18:51:05 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 16:51:05 -0000 Subject: [issue1624674] webbrowser.open_new() suggestion Message-ID: <1187887865.43.0.219524340492.issue1624674@psf.upfronthosting.co.za> Georg Brandl added the comment: webbrowser uses the default GNOME browser if a GNOME session is running and kfmclient if a KDE session is running. Closing as "works for me". ---------- resolution: -> works for me status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:08:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:08:55 -0000 Subject: [issue1753371] Open always create new tab or new browser Message-ID: <1187888935.5.0.884896541135.issue1753371@psf.upfronthosting.co.za> Georg Brandl added the comment: With Firefox, that's probably because you have set the default behavior to "open a new tab", so there's nothing webbrowser.py can do about that. In Windows, os.startfile() is used, which doesn't allow remote settings like "new window" etc., so there's nothing webbrowser.py can do about that, too. Setting tentatively to "Won't fix". ---------- nosy: +gbrandl resolution: -> wont fix status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:15:20 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 23 Aug 2007 17:15:20 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1187889320.04.0.389615764059.issue1779871@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Why does you patch test for -mno-fused-madd? If it isn't actually needed for something I'd rather not have that logic in the configure file, determining which bits of that file are actually needed for supported OS-es is hard enough as it is. -Wno-long-double is needed when compiling on old versions of OSX, where "long double" worked but wasn't actually useful. Keeping that option seems to be harmless. -no-cpp-precomp was necessary for several packages on older releases of OSX. I'll test on a 10.3 box when I have time (which is the oldest I can test on). ---------- assignee: -> ronaldoussoren nosy: +ronaldoussoren _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:17:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:17:56 -0000 Subject: [issue1776696] tempfile.TemporaryFile differs between platforms Message-ID: <1187889476.13.0.038511131096.issue1776696@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree with tiran. TemporaryFile(...) returns a file-like object, the details are implementation specific. ---------- nosy: +gbrandl resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:24:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:24:47 -0000 Subject: [issue1742889] Pickling of exceptions broken Message-ID: <1187889887.63.0.519989622095.issue1742889@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing in favor of #1692335. ---------- status: open -> closed superseder: -> Move initial args assignment to BaseException.__new__ _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:28:00 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:28:00 -0000 Subject: [issue1744398] Improve exception pickling support Message-ID: <1187890080.41.0.193989997826.issue1744398@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing in favor of #1692335. ---------- nosy: +gbrandl status: open -> closed superseder: -> Move initial args assignment to BaseException.__new__ _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:29:54 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:29:54 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1187890194.47.0.827707339661.issue1692335@psf.upfronthosting.co.za> Georg Brandl added the comment: Raising priority. ---------- priority: normal -> urgent severity: normal -> major title: Move initial args assignment to BaseException.__new__ -> Fix exception pickling: Move initial args assignment to BaseException.__new__ versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:34:23 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:34:23 -0000 Subject: [issue1772481] urllib2 hangs with some documents. Message-ID: <1187890463.65.0.050476433483.issue1772481@psf.upfronthosting.co.za> Georg Brandl added the comment: The fix seems safe to apply. ---------- nosy: +gbrandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:54:31 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:54:31 -0000 Subject: [issue1768121] Byte code WITH_CLEANUP missing, MAKE_CLOSURE wrong Message-ID: <1187891671.3.0.36148902249.issue1768121@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57324, thanks for the report. ---------- assignee: -> gbrandl nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 19:58:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 17:58:13 -0000 Subject: [issue1766421] poll() returns "status code", not "return code" Message-ID: <1187891893.5.0.109547835712.issue1766421@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report, fixed in rev. 57326, 57327. ---------- assignee: -> gbrandl nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:05:32 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 23 Aug 2007 18:05:32 -0000 Subject: [issue469773] Write 'Using Python on Platform X' documents Message-ID: <1187892332.55.0.889642143129.issue469773@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr.: ---------- assignee: fdrake -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 20:08:36 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 23 Aug 2007 18:08:36 -0000 Subject: [issue870479] Scripts need platform-dependent handling Message-ID: <1187892516.57.0.313924339665.issue870479@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Removing the assignment to me, since I'm not going to resolve the fundamental disagreements about what "the right thing" is. Someone else can argue with the wrong-headed. ---------- assignee: fdrake -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 20:08:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:08:55 -0000 Subject: [issue1752175] fixing 2.5.1 build with unicode and dynamic loading disabled Message-ID: <1187892535.25.0.281238006417.issue1752175@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, fixed both and backported in rev. 57328, 57330. ---------- assignee: -> gbrandl nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:11:46 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:11:46 -0000 Subject: [issue1757118] utilize 2.5 try/except/finally in contextlib Message-ID: <1187892706.68.0.184669860841.issue1757118@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in rev. 57331. ---------- assignee: -> gbrandl nosy: +gbrandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:13:56 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:13:56 -0000 Subject: [issue1756389] reference count discrepancy, PyErr_Print vs. PyErr_Clear Message-ID: <1187892836.42.0.377699541261.issue1756389@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as invalid. ---------- nosy: +gbrandl resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:14:11 2007 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 23 Aug 2007 18:14:11 -0000 Subject: [issue1209562] add single html files Message-ID: <1187892851.29.0.21227058304.issue1209562@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Might be nice, but it's obvious I've not gotten to this, so removing myself from the issue. ---------- assignee: fdrake -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:16:09 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:16:09 -0000 Subject: [issue1757072] Zipfile robustness Message-ID: <1187892969.75.0.00851571471893.issue1757072@psf.upfronthosting.co.za> Georg Brandl added the comment: Alan? ---------- assignee: -> aimacintyre nosy: +gbrandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:20:09 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:20:09 -0000 Subject: [issue1764044] copy 2 Message-ID: <1187893209.6.0.285687739623.issue1764044@psf.upfronthosting.co.za> Georg Brandl added the comment: Which "time" is that? Windows three timestamps, IIRC: creation, modification, access. ---------- nosy: +gbrandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:24:44 2007 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 23 Aug 2007 18:24:44 -0000 Subject: [issue1749583] expanduser("~") on Windows looks for HOME first Message-ID: <1187893484.96.0.688490149102.issue1749583@psf.upfronthosting.co.za> Ralf Schmitt added the comment: As a user of msys I would expect that python returns the value of HOME. If I didn't start python from msys, HOME would either not be set, or I had set in some windows dialog (and then I would expect python to also use that). ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:39:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:39:03 -0000 Subject: [issue1753395] struni: assertion in Windows debug build Message-ID: <1187894343.35.0.285488269365.issue1753395@psf.upfronthosting.co.za> Georg Brandl added the comment: Attaching a patch, should fix this. ---------- nosy: +gbrandl _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: slots_id.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/070f99f5/attachment-0001.txt From report at bugs.python.org Thu Aug 23 20:43:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:43:13 -0000 Subject: [issue1757072] Zipfile robustness Message-ID: <1187894593.27.0.973128290299.issue1757072@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: aimacintyre -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:46:35 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:46:35 -0000 Subject: [issue1209562] add single html files Message-ID: <1187894795.95.0.0983816165883.issue1209562@psf.upfronthosting.co.za> Georg Brandl added the comment: The new docs (see http://docs.python.org/dev) have much longer individual HTML pages, perhaps this is already enough for your needs (a single Library Reference page would be several Megabytes in size...) ---------- nosy: +gbrandl status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:49:43 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 18:49:43 -0000 Subject: [issue1752703] chown() does not handle UID > INT_MAX Message-ID: <1187894983.27.0.645242413809.issue1752703@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing, superseder has more information and same patch. ---------- nosy: +gbrandl resolution: -> duplicate status: open -> closed superseder: -> chown broken on 64bit _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 20:55:45 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 23 Aug 2007 18:55:45 -0000 Subject: [issue1771381] bsddb can't use unicode keys Message-ID: <1187895345.81.0.11512679248.issue1771381@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Unassigning since I don't know the details of bsddb. ---------- assignee: lemburg -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 21:02:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 19:02:13 -0000 Subject: [issue457493] include SQL interface module Message-ID: <1187895733.12.0.572058514557.issue457493@psf.upfronthosting.co.za> Georg Brandl added the comment: With DB API and sqlite3 in the stdlib, I think this can be closed. ---------- nosy: +gbrandl status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:04:24 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 19:04:24 -0000 Subject: [issue514532] Add "eu#" parser marker Message-ID: <1187895864.38.0.299789492059.issue514532@psf.upfronthosting.co.za> Georg Brandl added the comment: I guess this can be closed in the light of Py3k. ---------- nosy: +gbrandl status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:10:43 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 19:10:43 -0000 Subject: [issue714469] Easy tutorial printing should be possible Message-ID: <1187896243.1.0.284091381613.issue714469@psf.upfronthosting.co.za> Georg Brandl added the comment: Assigning to me to remind myself about writing a PDF-producing Sphinx builder. ---------- assignee: -> gbrandl nosy: +gbrandl resolution: invalid -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:12:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 19:12:26 -0000 Subject: [issue447143] exception item from mapped function Message-ID: <1187896346.25.0.0592765275966.issue447143@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing, see PEP 3134. ---------- nosy: +gbrandl status: open -> closed title: exception item from mapped function -> exception item from mapped function ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:15:44 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 19:15:44 -0000 Subject: [issue223599] Need user-centered info for Windows users. Message-ID: <1187896544.07.0.684322772802.issue223599@psf.upfronthosting.co.za> Georg Brandl added the comment: issue469773 subsumes this. ---------- nosy: +gbrandl -nobody resolution: -> duplicate status: open -> closed superseder: -> Write 'Using Python on Platform X' documents ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:25:19 2007 From: report at bugs.python.org (Jason Prado) Date: Thu, 23 Aug 2007 19:25:19 -0000 Subject: [issue1000] Patch to rename *Server modules to lower-case Message-ID: <1187897119.59.0.989686888119.issue1000@psf.upfronthosting.co.za> New submission from Jason Prado: Here's a patcher for the 2to3 fixer. After I add this ticket I'll try to add another file for the py3k/Lib directory. ---------- components: Library (Lib) files: fixer-server-imports.patch messages: 55188 nosy: jasonpjason severity: normal status: open title: Patch to rename *Server modules to lower-case versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fixer-server-imports.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/d92f3370/attachment.txt From report at bugs.python.org Thu Aug 23 21:25:19 2007 From: report at bugs.python.org (Jason Prado) Date: Thu, 23 Aug 2007 19:25:19 -0000 Subject: [issue1000] Patch to rename *Server modules to lower-case Message-ID: <1187897119.59.0.989686888119.issue1000@psf.upfronthosting.co.za> New submission from Jason Prado: Here's a patcher for the 2to3 fixer. After I add this ticket I'll try to add another file for the py3k/Lib directory. ---------- components: Library (Lib) files: fixer-server-imports.patch messages: 55188 nosy: jasonpjason severity: normal status: open title: Patch to rename *Server modules to lower-case versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fixer-server-imports.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/d92f3370/attachment-0003.txt From report at bugs.python.org Thu Aug 23 21:27:24 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 23 Aug 2007 19:27:24 -0000 Subject: [issue225476] Codec naming scheme and aliasing support Message-ID: <1187897244.98.0.822540589568.issue225476@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Closing this request as the encodings package search function should not be used import external codecs (this poses a security risk). ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:28:17 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 23 Aug 2007 19:28:17 -0000 Subject: [issue880951] "ez" format code for ParseTuple() Message-ID: <1187897297.64.0.0253549013256.issue880951@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Closing. There doesn't seem to be much interest in this. ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:31:03 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 23 Aug 2007 19:31:03 -0000 Subject: [issue1001895] Adding missing ISO 8859 codecs, especially Thai Message-ID: <1187897463.83.0.63321040708.issue1001895@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Not sure why this is still open. The patches were checked in a long time ago. ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 21:33:20 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 23 Aug 2007 19:33:20 -0000 Subject: [issue547537] cStringIO should provide a binary option Message-ID: <1187897600.82.0.516525219839.issue547537@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Unassigning: I've never had a need for this in the past years. ---------- assignee: lemburg -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:46:08 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 19:46:08 -0000 Subject: [issue698900] Provide "plucker" format docs. Message-ID: <1187898368.05.0.0332351608666.issue698900@psf.upfronthosting.co.za> Georg Brandl added the comment: Plucker seems to be dead for at least two years, so closing. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 21:54:02 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Thu, 23 Aug 2007 19:54:02 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1187898842.41.0.753910416206.issue1001@psf.upfronthosting.co.za> Changes by Adrian Holovaty: ---------- components: Demos and Tools severity: normal status: open title: 2to3 crashes on input files with no trailing newlines type: crash __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 21:56:26 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 23 Aug 2007 19:56:26 -0000 Subject: [issue1675334] Draft implementation for PEP 364 Message-ID: <1187898986.98.0.933532537711.issue1675334@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +py3k _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:00:03 2007 From: report at bugs.python.org (Brett Cannon) Date: Thu, 23 Aug 2007 20:00:03 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1187899203.81.0.970666580259.issue1001@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +py3k __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 22:00:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:00:48 -0000 Subject: [issue1086642] Compile of _socket fails on IRIX with 2.4 Message-ID: <1187899248.88.0.439829618388.issue1086642@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- title: Compile of _socket fails on 2.4 -> Compile of _socket fails on IRIX with 2.4 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:00:53 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Thu, 23 Aug 2007 20:00:53 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1187899253.26.0.0999442692621.issue1001@psf.upfronthosting.co.za> New submission from Adrian Holovaty: The 2to3 Python 3k migration utility crashes with the following traceback on any input file that does *not* have a trailing newline. It doesn't seem to matter whether the input file needs modifications or not. RefactoringTool: Can't parse /path/to/testing2.py: ParseError: bad input: type=0, value='', context=('\n', (2, 0)) RefactoringTool: No files need to be modified. RefactoringTool: There was 1 error: RefactoringTool: Can't parse /path/to/testing2.py: ParseError: bad input: type=0, value='', context=('\n', (2, 0)) ---------- nosy: +adrianholovaty __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 22:07:49 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:07:49 -0000 Subject: [issue765228] Subclassing from Modules Message-ID: <1187899669.03.0.337477202012.issue765228@psf.upfronthosting.co.za> Georg Brandl added the comment: In 2.5, the message says "module.__init__() takes at most 2 arguments (3 given)", which is at least a bit more specific. You get similar errors when "deriving" from other arbitrary objects, so I don't know if a special case makes sense here. ---------- nosy: +gbrandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 22:13:18 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Thu, 23 Aug 2007 20:13:18 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1187899998.71.0.569816759264.issue1001@psf.upfronthosting.co.za> Adrian Holovaty added the comment: (Sorry, the previous error snippet isn't a traceback as I had said. It's the error text.) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 22:15:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:15:47 -0000 Subject: [issue924771] work around to compile \r\n file Message-ID: <1187900147.81.0.989006508025.issue924771@psf.upfronthosting.co.za> Georg Brandl added the comment: The offending open() call in trace.py is fixed, so closing this. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 22:20:17 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 20:20:17 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187900417.52.0.984066469485.issue1002@psf.upfronthosting.co.za> New submission from Paul Smith: HTMLParser is renamed to html_parser. ---------- components: Library (Lib) files: rename-html-parser.diff messages: 55200 nosy: paulsmith severity: normal status: open title: Patch to rename HTMLParser module to lower_case versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-html-parser.diff Type: application/octet-stream Size: 1199 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/c8e2f389/attachment.obj From report at bugs.python.org Thu Aug 23 22:20:17 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 20:20:17 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187900417.52.0.984066469485.issue1002@psf.upfronthosting.co.za> New submission from Paul Smith: HTMLParser is renamed to html_parser. ---------- components: Library (Lib) files: rename-html-parser.diff messages: 55200 nosy: paulsmith severity: normal status: open title: Patch to rename HTMLParser module to lower_case versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-html-parser.diff Type: application/octet-stream Size: 1199 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/c8e2f389/attachment-0001.obj From report at bugs.python.org Thu Aug 23 22:20:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:20:32 -0000 Subject: [issue881765] configure warning / sys/un.h: present but cannot be compiled Message-ID: <1187900432.19.0.570154222804.issue881765@psf.upfronthosting.co.za> Georg Brandl added the comment: No followup for 3 years, so this can probably be closed. ---------- nosy: +gbrandl status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 22:20:43 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 20:20:43 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187900443.19.0.0210903411598.issue1002@psf.upfronthosting.co.za> Paul Smith added the comment: Patch to 2to3 fix_imports. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-html-parser-fix-imports.diff Type: application/octet-stream Size: 724 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/eead4d18/attachment.obj From report at bugs.python.org Thu Aug 23 22:30:21 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:30:21 -0000 Subject: [issue547537] cStringIO should provide a binary option Message-ID: <1187901021.29.0.960878451953.issue547537@psf.upfronthosting.co.za> Georg Brandl added the comment: I think this can be closed, cStringIO won't change and Py3k won't have StringIO unicode problems anyway. ---------- nosy: +gbrandl resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 22:31:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:31:32 -0000 Subject: [issue1767242] os.chmod failure Message-ID: <1187901092.09.0.474545902441.issue1767242@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:35:14 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:35:14 -0000 Subject: [issue1697820] __getslice__ still used in built-in types Message-ID: <1187901314.45.0.720078367331.issue1697820@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57343. ---------- assignee: rhettinger -> gbrandl nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:35:46 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:35:46 -0000 Subject: [issue1293790] python.sty: \py@sigline correction Message-ID: <1187901346.26.0.0906096778479.issue1293790@psf.upfronthosting.co.za> Georg Brandl added the comment: Obsolete now that we're using reST sources. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:36:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:36:03 -0000 Subject: [issue1293788] python.sty correction - verbatim environment Message-ID: <1187901363.41.0.175345168333.issue1293788@psf.upfronthosting.co.za> Georg Brandl added the comment: Obsolete now that we're using reST sources. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:40:11 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:40:11 -0000 Subject: [issue1573854] sqlite3 documentation on rowcount is contradictory Message-ID: <1187901611.98.0.366041883649.issue1573854@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed now in rev. 57345. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:50:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:50:38 -0000 Subject: [issue1694833] Bad documentation for existing imp methods Message-ID: <1187902238.55.0.5279937415.issue1694833@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report, fixed in rev. 57347. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:52:34 2007 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 23 Aug 2007 20:52:34 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1187902354.06.0.528343653401.issue1779871@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: In http://gcc.gnu.org/ml/gcc/2005-12/msg00368.html, Mike Stump said "This flag [-no-cpp-precomp] should be removed from the compile, it hasn't been needed in a long while (since gcc-3.1)." which was released in 2002. I'm happy to remove -mno-fused-madd if you say it's unnecessary. Ronald, do you mean "Removing that option [-Wno-long-double] seems to be harmless"? Keeping it harms compiles with non-apple gcc's, but I could add it to a block like -mno-fused-madd. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:53:16 2007 From: report at bugs.python.org (David W) Date: Thu, 23 Aug 2007 20:53:16 -0000 Subject: [issue1003] zipfile password fails validation Message-ID: <1187902396.85.0.749832175087.issue1003@psf.upfronthosting.co.za> New submission from David W: This is in python2.5: zipfile.py SVN rev-56308 When testing a zipfile.Zipfile().read() with a password protected zip file, I would continually get exceptions. So I tracked this down to line 796-797: if ord(h[11]) != ((zinfo.CRC>>24)&255): raise RuntimeError, "Bad password for file %s" % name scope related data: bytes = `)?G\x02???&\x1E#??` h[11] = `?` zinfo.CRC = `1554440319` ord(h[11]) == 175 ((zinfo.CRC>>24)&255) == 92 When I commented out the error check, the script extracted 150 JPGs with no corruption or errors in any of the images...so its just seems like an issue with the error check. ---------- components: Library (Lib) messages: 55210 nosy: djw severity: normal status: open title: zipfile password fails validation type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 22:53:16 2007 From: report at bugs.python.org (David W) Date: Thu, 23 Aug 2007 20:53:16 -0000 Subject: [issue1003] zipfile password fails validation Message-ID: <1187902396.85.0.749832175087.issue1003@psf.upfronthosting.co.za> New submission from David W: This is in python2.5: zipfile.py SVN rev-56308 When testing a zipfile.Zipfile().read() with a password protected zip file, I would continually get exceptions. So I tracked this down to line 796-797: if ord(h[11]) != ((zinfo.CRC>>24)&255): raise RuntimeError, "Bad password for file %s" % name scope related data: bytes = `)?G\x02???&\x1E#??` h[11] = `?` zinfo.CRC = `1554440319` ord(h[11]) == 175 ((zinfo.CRC>>24)&255) == 92 When I commented out the error check, the script extracted 150 JPGs with no corruption or errors in any of the images...so its just seems like an issue with the error check. ---------- components: Library (Lib) messages: 55210 nosy: djw severity: normal status: open title: zipfile password fails validation type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 22:53:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:53:37 -0000 Subject: [issue1594966] doctest simple usage recipe is misleading Message-ID: <1187902417.12.0.645850291667.issue1594966@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57348. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 22:59:44 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 20:59:44 -0000 Subject: [issue1095328] Add 'update FAQ' to release checklist Message-ID: <1187902784.67.0.174728827726.issue1095328@psf.upfronthosting.co.za> Georg Brandl added the comment: Updated FAQ once again; there is an item in PEP 101 already. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:11:45 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:11:45 -0000 Subject: [issue1119439] Python Programming FAQ should be updated for Python 2.4 Message-ID: <1187903505.78.0.543304518206.issue1119439@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in my pydotorg tree, will commit as soon as I find out how :) ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:14:48 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:14:48 -0000 Subject: [issue1635217] Add example of distutils setup() with "requires" argument Message-ID: <1187903688.29.0.76697220009.issue1635217@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- title: Little mistake in docs -> Add example of distutils setup() with "requires" argument _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:18:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:18:55 -0000 Subject: [issue1752332] getaddrinfo no longer used in httplib Message-ID: <1187903935.86.0.350124297316.issue1752332@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57351. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:21:49 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:21:49 -0000 Subject: [issue1734111] struct.Struct.size is not documented Message-ID: <1187904109.64.0.428533769801.issue1734111@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57352. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:21:58 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 21:21:58 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187904118.03.0.167564401356.issue1002@psf.upfronthosting.co.za> Paul Smith added the comment: Note that patch doesn't include `svn mv Lib/HTMLParser.py Lib/html_parser.py`. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 23 23:22:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:22:40 -0000 Subject: [issue1707497] generation errors in PDF-A4 tags for lib.pdf Message-ID: <1187904160.98.0.53490949816.issue1707497@psf.upfronthosting.co.za> Georg Brandl added the comment: Obsolete; the sources from which these PDFs are generated are no longer used. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:23:49 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:23:49 -0000 Subject: [issue1708326] imp.find_module doc ambiguity Message-ID: <1187904229.23.0.372266651594.issue1708326@psf.upfronthosting.co.za> Georg Brandl added the comment: IMO it is your responsibility to make sure that the module name you pass is a valid Python module name. ---------- nosy: +gbrandl status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:25:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:25:40 -0000 Subject: [issue1699759] pickle example contains errors Message-ID: <1187904340.04.0.650728350938.issue1699759@psf.upfronthosting.co.za> Georg Brandl added the comment: The example is already fixed; also, a note is in the docs that you must use binary mode for protocols >= 1. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:28:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:28:06 -0000 Subject: [issue1688564] os.path.join.__doc__ should mention absolute paths Message-ID: <1187904486.81.0.444157125721.issue1688564@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57353. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:29:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:29:40 -0000 Subject: [issue1630515] doc misleading in re.compile Message-ID: <1187904580.81.0.145860367619.issue1630515@psf.upfronthosting.co.za> Georg Brandl added the comment: Normal usage is to create a RE object and then using its methods. Why would you pass a RE object to a module-level function instead? Therefore, documenting this possibility would just confuse the reader. Closing as "won't fix". ---------- nosy: +gbrandl resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:32:01 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:32:01 -0000 Subject: [issue1421839] Inconsistency in Programming FAQ Message-ID: <1187904721.13.0.486992133205.issue1421839@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in my pydotorg tree, will commit ASAP. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:36:17 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:36:17 -0000 Subject: [issue1625381] re module documentation on search/match is unclear Message-ID: <1187904977.57.0.739385559943.issue1625381@psf.upfronthosting.co.za> Georg Brandl added the comment: Clarified in rev. 57354. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:43:03 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:43:03 -0000 Subject: [issue1758696] Documentation of descriptors needs more detail Message-ID: <1187905383.4.0.606809151314.issue1758696@psf.upfronthosting.co.za> Georg Brandl added the comment: Added a footnote in rev. 57355. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:48:17 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:48:17 -0000 Subject: [issue1742164] Incorrect docs for optparse OptionParser add_help_option Message-ID: <1187905697.1.0.751707885989.issue1742164@psf.upfronthosting.co.za> Georg Brandl added the comment: This is finally fixed with the new sources and toolset. ---------- nosy: +gbrandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:49:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:49:06 -0000 Subject: [issue1743846] Examples dropped from PDF version of SQLite docs Message-ID: <1187905746.54.0.661803291876.issue1743846@psf.upfronthosting.co.za> Georg Brandl added the comment: Obsolete now, the toolset that generated these PDFs is no longer used for new versions. ---------- nosy: +gbrandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:52:01 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:52:01 -0000 Subject: [issue780725] Compile error messages and PEP-263 Message-ID: <1187905921.12.0.159941092814.issue780725@psf.upfronthosting.co.za> Georg Brandl added the comment: #1031213 contains a patch, marking as superseder. ---------- nosy: +gbrandl resolution: -> duplicate status: open -> closed superseder: -> Patch for bug #780725 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 23 23:52:37 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:52:37 -0000 Subject: [issue1031213] Use correct encoding for printing SyntaxErrors Message-ID: <1187905957.07.0.1850100973.issue1031213@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- title: Patch for bug #780725 -> Use correct encoding for printing SyntaxErrors _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 23 23:56:11 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 21:56:11 -0000 Subject: [issue1779550] Remove redundancies inside class logging.Logger Message-ID: <1187906171.59.0.891005853768.issue1779550@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, applied as rev. 57357. ---------- assignee: -> gbrandl nosy: +gbrandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 00:00:55 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Aug 2007 22:00:55 -0000 Subject: [issue1766304] improve xrange.__contains__ Message-ID: <1187906455.39.0.490212540365.issue1766304@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- keywords: +py3k _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 00:13:50 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 22:13:50 -0000 Subject: [issue1005] Patches to rename Queue module to queue Message-ID: <1187907230.61.0.022863019632.issue1005@psf.upfronthosting.co.za> New submission from Paul Smith: Renamed Lib/Queue.py to Lib/queue.py. ---------- components: Library (Lib) files: rename-queue.diff messages: 55230 nosy: paulsmith severity: normal status: open title: Patches to rename Queue module to queue versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-queue.diff Type: application/octet-stream Size: 6941 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/8f591451/attachment-0001.obj From report at bugs.python.org Fri Aug 24 00:13:50 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 22:13:50 -0000 Subject: [issue1005] Patches to rename Queue module to queue Message-ID: <1187907230.61.0.022863019632.issue1005@psf.upfronthosting.co.za> New submission from Paul Smith: Renamed Lib/Queue.py to Lib/queue.py. ---------- components: Library (Lib) files: rename-queue.diff messages: 55230 nosy: paulsmith severity: normal status: open title: Patches to rename Queue module to queue versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-queue.diff Type: application/octet-stream Size: 6941 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/8f591451/attachment-0002.obj From report at bugs.python.org Fri Aug 24 00:14:57 2007 From: report at bugs.python.org (Paul Smith) Date: Thu, 23 Aug 2007 22:14:57 -0000 Subject: [issue1005] Patches to rename Queue module to queue Message-ID: <1187907297.93.0.825848697804.issue1005@psf.upfronthosting.co.za> Paul Smith added the comment: Patches 2to3/fixes/fix_imports.py. Note that patch to Lib doesn't include `svn mv Lib/Queue.py Lib/queue.py` (issue reporter without commit privileges). __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-queue-fix-imports.diff Type: application/octet-stream Size: 480 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070823/9922617d/attachment.obj From report at bugs.python.org Fri Aug 24 02:23:08 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Atul_Varma=0A=09=09=09=09?=) Date: Fri, 24 Aug 2007 00:23:08 -0000 Subject: [issue1006] Refactor test_winreg.py to use unittest. Message-ID: <1187914988.48.0.215976715361.issue1006@psf.upfronthosting.co.za> New submission from Atul Varma : This patch refactors test_winreg.py to use unittest. When this patch is applied, Lib/test/output/test_winreg can be removed. I also made a few formatting changes to ensure that all lines are constrained to 80-characters. The original test_winreg.py took a command-line argument, "--remote", to specify the name of a remote computer to run tests on. For now, I've added a unittest test called "testRemoteMachineRegistryWorks" which raises a test_support.TestSkipped exception if the "--remote" argument wasn't specified. I'm not sure if this is optimal behavior; it can be changed if not, of course. ---------- components: Tests files: refactor_test_winreg.py.patch messages: 55232 nosy: varmaa severity: normal status: open title: Refactor test_winreg.py to use unittest. versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: refactor_test_winreg.py.patch Type: application/octet-stream Size: 12191 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/1ea52c47/attachment-0001.obj From report at bugs.python.org Fri Aug 24 02:23:08 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Atul_Varma=0A=09=09=09=09?=) Date: Fri, 24 Aug 2007 00:23:08 -0000 Subject: [issue1006] Refactor test_winreg.py to use unittest. Message-ID: <1187914988.48.0.215976715361.issue1006@psf.upfronthosting.co.za> New submission from Atul Varma : This patch refactors test_winreg.py to use unittest. When this patch is applied, Lib/test/output/test_winreg can be removed. I also made a few formatting changes to ensure that all lines are constrained to 80-characters. The original test_winreg.py took a command-line argument, "--remote", to specify the name of a remote computer to run tests on. For now, I've added a unittest test called "testRemoteMachineRegistryWorks" which raises a test_support.TestSkipped exception if the "--remote" argument wasn't specified. I'm not sure if this is optimal behavior; it can be changed if not, of course. ---------- components: Tests files: refactor_test_winreg.py.patch messages: 55232 nosy: varmaa severity: normal status: open title: Refactor test_winreg.py to use unittest. versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: refactor_test_winreg.py.patch Type: application/octet-stream Size: 12191 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/1ea52c47/attachment-0002.obj From report at bugs.python.org Fri Aug 24 02:56:10 2007 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Aug 2007 00:56:10 -0000 Subject: [issue1007] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1187916970.05.0.432366194478.issue1007@psf.upfronthosting.co.za> Larry Hastings added the comment: Whoops, copy & paste error on the title, there. ---------- title: ix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) -> Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 02:58:46 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 00:58:46 -0000 Subject: [issue1007] [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1187917126.93.0.062898722473.issue1007@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- title: Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) -> [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 03:01:15 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 01:01:15 -0000 Subject: [issue1007] [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1187917275.37.0.865965419135.issue1007@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> greg __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 03:54:07 2007 From: report at bugs.python.org (Atul Varma) Date: Fri, 24 Aug 2007 01:54:07 -0000 Subject: [issue1008] Refactor test_signal.py to use unittest. Message-ID: <1187920447.34.0.203956739279.issue1008@psf.upfronthosting.co.za> New submission from Atul Varma: This patch refactors test_signal.py to use unittest. When this patch is applied, Lib/test/output/test_signal can be removed. I tried to refactor out individual tests from the original script and place them in separate test cases. ---------- components: Tests files: refactored_test_signal.py.patch messages: 55235 nosy: varmaa severity: normal status: open title: Refactor test_signal.py to use unittest. versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: refactored_test_signal.py.patch Type: text/x-patch Size: 12023 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/45498ea1/attachment-0001.bin From report at bugs.python.org Fri Aug 24 03:54:07 2007 From: report at bugs.python.org (Atul Varma) Date: Fri, 24 Aug 2007 01:54:07 -0000 Subject: [issue1008] Refactor test_signal.py to use unittest. Message-ID: <1187920447.34.0.203956739279.issue1008@psf.upfronthosting.co.za> New submission from Atul Varma: This patch refactors test_signal.py to use unittest. When this patch is applied, Lib/test/output/test_signal can be removed. I tried to refactor out individual tests from the original script and place them in separate test cases. ---------- components: Tests files: refactored_test_signal.py.patch messages: 55235 nosy: varmaa severity: normal status: open title: Refactor test_signal.py to use unittest. versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: refactored_test_signal.py.patch Type: text/x-patch Size: 12023 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/45498ea1/attachment-0002.bin From report at bugs.python.org Fri Aug 24 05:25:40 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 24 Aug 2007 03:25:40 -0000 Subject: [issue1721890] IDLE hangs in popup method completion Message-ID: <1187925940.71.0.329555096608.issue1721890@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: fixed at 53042. ---------- priority: high -> normal status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 05:57:06 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 03:57:06 -0000 Subject: [issue1771381] bsddb can't use unicode keys Message-ID: <1187927826.78.0.357006507023.issue1771381@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The BerkeleyDB library operates on bytes only. Unicode doesn't make sense as a key without converting it to a particular encoding first. Use the unicode object's encode() method if you need to use it as a database key or create a wrapper object or subclass of the db that automatically does that for you as appropriate. ---------- assignee: -> greg nosy: +greg resolution: -> wont fix status: open -> closed versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 06:02:05 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 04:02:05 -0000 Subject: [issue533281] bsddb module needs iterators Message-ID: <1187928125.23.0.662676075319.issue533281@psf.upfronthosting.co.za> Gregory P. Smith added the comment: this was marked 'open' and 'fixed' at the same time. that should be an invalid state. it was indeed fixed eons ago. ---------- nosy: +greg status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Aug 24 06:11:21 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 04:11:21 -0000 Subject: [issue1725856] bsddb.btopen . del of record doesn't update index Message-ID: <1187928681.45.0.691060931751.issue1725856@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- assignee: -> greg _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 06:26:54 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 04:26:54 -0000 Subject: [issue1725856] bsddb.btopen . del of record doesn't update index Message-ID: <1187929614.02.0.518796955135.issue1725856@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This code deletes the item that the internal database cursor created by the db.first() call is pointing at. Then when db.first() is called again it tries to reuse the same cursor. Now to decide if thats the expected behavior or a real problem and how to fix it... side note: I don't know why your backtraces contained the wrong strings. All of mine look fine here. also: for a simpler test case to debug, change the 10 to 2 in the testbtopen.py file. ---------- nosy: +greg _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 06:42:02 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 24 Aug 2007 04:42:02 -0000 Subject: [issue533281] bsddb module needs iterators Message-ID: <1187930522.51.0.997864466051.issue533281@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It had indeed the status Fixed/Open on SF. It was marked as Fixed and Closed by rhettinger, then reopened by rhettinger in response to my comment in msg53513. It does not refer to _bsddb.c, but bsddbmodule.c. Are you saying that bsddbmodule.c supports __iter__? It does not look that way to me... ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Aug 24 06:49:27 2007 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 24 Aug 2007 04:49:27 -0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting Message-ID: <1187930967.56.0.989084439416.issue1009@psf.upfronthosting.co.za> Changes by Eric V. Smith: ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 06:51:46 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 04:51:46 -0000 Subject: [issue1725856] bsddb.btopen . del of record doesn't update index Message-ID: <1187931106.63.0.104459709858.issue1725856@psf.upfronthosting.co.za> Gregory P. Smith added the comment: My first description wasn't quite accurate. What was happening is that the __delitem__(i) call by del was closing the existing cursor and saving the key it was pointing to and the first() and last() methods were creating a new cursor and trying to restore the new cursor to the last known position saved when __delitem__ closed the previous cursor. This failed as that item no longer existed. first() and last() by their very nature don't need to restore the cursor position since they set it to an absolute position. Here's the patch to fix this: --- Lib/bsddb/__init__.py (revision 57289) +++ Lib/bsddb/__init__.py (working copy) @@ -274,12 +274,16 @@ def first(self): self._checkOpen() + # fix 1725856: don't needlessly try to restore our cursor position + self.saved_dbc_key = None self._checkCursor() rv = _DeadlockWrap(self.dbc.first) return rv def last(self): self._checkOpen() + # fix 1725856: don't needlessly try to restore our cursor position + self.saved_dbc_key = None self._checkCursor() rv = _DeadlockWrap(self.dbc.last) return rv ---------- status: open -> pending _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 07:33:05 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 05:33:05 -0000 Subject: [issue1725856] bsddb.btopen . del of record doesn't update index Message-ID: <1187933585.42.0.937318790224.issue1725856@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Committed to HEAD as r57378 Committed to release25-maint as r57379 Committed to py3k as r57380 ---------- resolution: -> fixed status: pending -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 08:19:26 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 06:19:26 -0000 Subject: [issue1686597] descrintro: error describing __new__ behavior Message-ID: <1187936366.93.0.337002877931.issue1686597@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in pydotorg rev. 10972. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 08:24:04 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 06:24:04 -0000 Subject: [issue533281] bsddb185 module needs iterators Message-ID: <1187936644.69.0.615232202578.issue533281@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Oops. You're right. This was referring to the legacy bsddb185 module in Modules/bsddbmodule.c. In 2.6 that is never built by default. I'm marking it as wont fix. ---------- resolution: fixed -> wont fix title: bsddb module needs iterators -> bsddb185 module needs iterators ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Aug 24 08:56:59 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Fri, 24 Aug 2007 06:56:59 -0000 Subject: [issue1734164] sqlite3 causes memory read error Message-ID: <1187938619.81.0.568373196932.issue1734164@psf.upfronthosting.co.za> Gerhard H?ring added the comment: This was already reported upstream at http://initd.org/tracker/pysqlite/ticket/205 It's a bug in the SQLite version of the DLL is shipped with Python 2.5 on Windows. Updating the DLL to a newer version would help. In the meantime, users can just download the newest DLL from the SQLite site and replace the one shipped by Python with it. ---------- assignee: -> ghaering nosy: +ghaering _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 08:58:03 2007 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Fri, 24 Aug 2007 06:58:03 -0000 Subject: [issue1734164] sqlite3 causes memory read error Message-ID: <1187938683.91.0.36061209683.issue1734164@psf.upfronthosting.co.za> Changes by Gerhard H?ring: ---------- type: -> crash versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 12:23:20 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 24 Aug 2007 10:23:20 -0000 Subject: [issue1276378] tarfile: adding filed that use direct device addressing Message-ID: <1187951000.77.0.280835358105.issue1276378@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Closing this due to lack of interest. This is no tarfile issue. If direct device addressing should be supported by Python, os.stat() would be the place to implement it. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 13:39:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 11:39:42 -0000 Subject: [issue1728488] -q (quiet) option for python interpreter Message-ID: <1187955582.33.0.288429966056.issue1728488@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- superseder: -> -q (quiet) option for python interpreter _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 13:40:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 11:40:33 -0000 Subject: [issue1772833] -q (quiet) option for python interpreter Message-ID: <1187955633.13.0.694720524694.issue1772833@psf.upfronthosting.co.za> Georg Brandl added the comment: Guido, is this okay to check in? ---------- assignee: -> gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 13:48:01 2007 From: report at bugs.python.org (Christophe Michel) Date: Fri, 24 Aug 2007 11:48:01 -0000 Subject: [issue1757062] Pickle fails on BeautifulSoup's navigableString instances Message-ID: <1187956081.12.0.0997377416459.issue1757062@psf.upfronthosting.co.za> Christophe Michel added the comment: I started by isolating the most minimalist code that triggers the error. If you play a bit with NavigableString, you will end up with the attached code. As expected, this program fails with RuntimeError: maximum recursion depth exceeded The evil recursion proceeds as follows : >> File "C:\Python25\lib\pickle.py", line 1364, in dump >> Pickler(file, protocol).dump(obj) Initial call to dump(), as intended. >> File "C:\Python25\lib\pickle.py", line 224, in dump >> self.save(obj) save() calls obj.__reduce_ex(), obj being our EvilString instance. This function is defined in copyreg.py, line 58 and following my example, returns a tuple containing three elements: 1) the _reconstructor function, as defined in copyreg.py, line 46 2) a tuple : (, , <'__main__.EvilString' instance at 0xXXXXXXXX>) First element is the actual class of obj, second is the base class, and third is the current instance (known as state). 3) an empty dict {} >> File "C:\Python25\lib\pickle.py", line 331, in save >> self.save_reduce(obj=obj, *rv) save_reduce() calls self.save() twice: - first on the func argument, which is the _reconstructor function. This call works as intended - next on the tuple (, , <'__main__.EvilString' instance at 0xXXXXXXXX>) >> File "C:\Python25\lib\pickle.py", line 403, in save_reduce >> save(args) >> File "C:\Python25\lib\pickle.py", line 286, in save >> f(self, obj) # Call unbound method with explicit self save() finds out its argument is a Tuple, and calls save_tuple() appropriately >> File "C:\Python25\lib\pickle.py", line 564, in save_tuple >> save(element) ... and save_tuple() calls save() on each element of the tuple. See what's wrong ? This means calling save() again on the EvilString instance. Which, in turn, will call save_reduce() on it, and so on. The problem lies in _reduce_ex(), in the definition of the state of the object: copyreg.py, lines 65 to 70: if base is object: state = None else: if base is self.__class__: raise TypeError, "can't pickle %s objects" % base.__name__ state = base(self) When this code gets executed on an EvilString instance, base is the type 'unicode'. Since it's not an object, and since it's not the actual class EvilString either, the following line gets executed: state=base(self) Which corresponds to unicode(self), or self.__unicode__, which returns an EvilString instance, not a variable of type unicode. And there starts the recursion. I don't know if this is flaw in the design of _reduce_ex, or a flaw inherent to having __unicode__(self) returning self. My guess is the latter is right. ---------- nosy: +altherac _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-175062.py Type: application/octet-stream Size: 204 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/cd36e27d/attachment.obj From report at bugs.python.org Fri Aug 24 13:48:50 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 11:48:50 -0000 Subject: [issue1765375] setup.py trashes LDFLAGS Message-ID: <1187956130.7.0.16648926624.issue1765375@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report, fixed in rev. 57389, 57390 (2.5). ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 13:49:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 11:49:06 -0000 Subject: [issue1765558] small improvement for peephole conditional jump optimizer Message-ID: <1187956146.87.0.958719599137.issue1765558@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> rhettinger _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 13:49:53 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 11:49:53 -0000 Subject: [issue1764986] generic and more efficient removal of unreachable code Message-ID: <1187956193.84.0.0233063869667.issue1764986@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> rhettinger _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 13:58:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 11:58:25 -0000 Subject: [issue1757062] Pickle fails on BeautifulSoup's navigableString instances Message-ID: <1187956705.69.0.0986485054095.issue1757062@psf.upfronthosting.co.za> Georg Brandl added the comment: This is indeed tricky. The docs say __unicode__ "should return a Unicode object", so I'm inclined to blame BeautifulSoup. Asking Neal for a second opinion. ---------- assignee: -> nnorwitz nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 15:19:30 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 24 Aug 2007 13:19:30 -0000 Subject: [issue1010] Broken bug tracker url Message-ID: <1187961570.05.0.530223209072.issue1010@psf.upfronthosting.co.za> New submission from Nir Soffer: In http://docs.python.org/lib/about.html, the link to "Python Bug Tracker" point to the old close tracker in sourceforge.net. Should be replaced to bugs.python.org. ---------- components: Documentation messages: 55253 nosy: nirs severity: normal status: open title: Broken bug tracker url versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 15:19:30 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 24 Aug 2007 13:19:30 -0000 Subject: [issue1010] Broken bug tracker url Message-ID: <1187961570.05.0.530223209072.issue1010@psf.upfronthosting.co.za> New submission from Nir Soffer: In http://docs.python.org/lib/about.html, the link to "Python Bug Tracker" point to the old close tracker in sourceforge.net. Should be replaced to bugs.python.org. ---------- components: Documentation messages: 55253 nosy: nirs severity: normal status: open title: Broken bug tracker url versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 15:33:45 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 24 Aug 2007 13:33:45 -0000 Subject: [issue1011] Wrong documentation for rfc822.Message.getheader Message-ID: <1187962425.36.0.406803838673.issue1011@psf.upfronthosting.co.za> New submission from Nir Soffer: In http://docs.python.org/lib/message-objects.html, getheader doc say: "Like getrawheader(name), but strip leading and trailing whitespace. Internal whitespace is not stripped. The optional default argument can be used to specify a different default to be returned when there is no header matching name." However, getheader is not like getrawheader. getheader return the *last* header seen, using the message dict. getrawheader retruns the *first* header line seen, searching through the list of parsed header lines. The text should also note that getheader is faster and the preferred way to get parsed headers. ---------- components: Documentation messages: 55254 nosy: nirs severity: normal status: open title: Wrong documentation for rfc822.Message.getheader versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 15:33:45 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 24 Aug 2007 13:33:45 -0000 Subject: [issue1011] Wrong documentation for rfc822.Message.getheader Message-ID: <1187962425.36.0.406803838673.issue1011@psf.upfronthosting.co.za> New submission from Nir Soffer: In http://docs.python.org/lib/message-objects.html, getheader doc say: "Like getrawheader(name), but strip leading and trailing whitespace. Internal whitespace is not stripped. The optional default argument can be used to specify a different default to be returned when there is no header matching name." However, getheader is not like getrawheader. getheader return the *last* header seen, using the message dict. getrawheader retruns the *first* header line seen, searching through the list of parsed header lines. The text should also note that getheader is faster and the preferred way to get parsed headers. ---------- components: Documentation messages: 55254 nosy: nirs severity: normal status: open title: Wrong documentation for rfc822.Message.getheader versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 16:22:18 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Ilan_Peleg=0A=09=09=09=09?=) Date: Fri, 24 Aug 2007 14:22:18 -0000 Subject: [issue1753371] Open always create new tab or new browser Message-ID: <1187965338.16.0.0503323433782.issue1753371@psf.upfronthosting.co.za> Ilan Peleg added the comment: Hi there, I Have only 2 lines in my programs which related to webbrowser.py. 1) import webbrowser 2) webbrowser.open(windowsPath) # Called many times. In the following browsers [FastBrowser,Firefox,IE7,FrontPage] new tab is created after each call. In IE6 new window is created. Most of the time that behavior (many tabs) is nice feature but in some scenarios it looks bad. I simply wish to have new tabs only when I ask it. Thanks Ilan. ---------- type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 16:35:27 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Ilan_Peleg=0A=09=09=09=09?=) Date: Fri, 24 Aug 2007 14:35:27 -0000 Subject: [issue1753371] Open always create new tab or new browser Message-ID: <1187966127.95.0.242029934444.issue1753371@psf.upfronthosting.co.za> Ilan Peleg added the comment: Just to make sure I'm clear. I don't wish new tabs neither new windows. I wish all calls to webbrowser.open(path) to go the same tab or to the same window when tabs are not supported or not requested. Ilan. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 17:56:20 2007 From: report at bugs.python.org (O.R.Senthil Kumaran) Date: Fri, 24 Aug 2007 15:56:20 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187970980.16.0.832429668131.issue1002@psf.upfronthosting.co.za> O.R.Senthil Kumaran added the comment: what is this and other series of patches you have submitted, paulsmith? I fail to understand. Why is the need for changing Library? You are just adding up SPAM here. ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 18:14:34 2007 From: report at bugs.python.org (Paul Smith) Date: Fri, 24 Aug 2007 16:14:34 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187972074.64.0.0616021402408.issue1002@psf.upfronthosting.co.za> Paul Smith added the comment: I am participating in the Python Sprint here at Google, and was just going through the Py3k Sprint Tasks spreadsheet, one of them being to rename standard library modules which use CamelCase to lower_and_underscore, the more modern naming. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 18:22:05 2007 From: report at bugs.python.org (Collin Winter) Date: Fri, 24 Aug 2007 16:22:05 -0000 Subject: [issue1007] [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1187972525.45.0.916615860132.issue1007@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- versions: +Python 3.0 -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 18:34:48 2007 From: report at bugs.python.org (O.R.Senthil Kumaran) Date: Fri, 24 Aug 2007 16:34:48 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187973288.38.0.427430164811.issue1002@psf.upfronthosting.co.za> O.R.Senthil Kumaran added the comment: But your "standalone diffs" will break things and dependencies with other modules, so I was worried about them. Are you taking care of them all? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 19:20:50 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 17:20:50 -0000 Subject: [issue1010] Broken bug tracker url Message-ID: <1187976050.28.0.416902684676.issue1010@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in rev. 57394. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 19:23:42 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 17:23:42 -0000 Subject: [issue1011] Wrong documentation for rfc822.Message.getheader Message-ID: <1187976222.11.0.281274341427.issue1011@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in rev. 57395. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 19:24:48 2007 From: report at bugs.python.org (O.R.Senthil Kumaran) Date: Fri, 24 Aug 2007 17:24:48 -0000 Subject: [issue1012] Broken URL at Doc/install/index.rst Message-ID: <1187976288.08.0.0768128809441.issue1012@psf.upfronthosting.co.za> New submission from O.R.Senthil Kumaran: * nair.jitendra at gmail.com [2007-08-24 06:12:52]: > hyperlink "site module documentation" in Section 4.1 on page > http://docs.python.org/inst/search-path.html leads to a nonexistent > page. > > Regards > jitendra nair 1) This needs to be fixed in the online doc, 2) Attaching a patch for the current trunk. ---------- components: Documentation files: module-site-url.patch messages: 55262 nosy: orsenthil severity: minor status: open title: Broken URL at Doc/install/index.rst versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: module-site-url.patch Type: text/x-diff Size: 686 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/4b68a838/attachment.patch From report at bugs.python.org Fri Aug 24 19:24:48 2007 From: report at bugs.python.org (O.R.Senthil Kumaran) Date: Fri, 24 Aug 2007 17:24:48 -0000 Subject: [issue1012] Broken URL at Doc/install/index.rst Message-ID: <1187976288.08.0.0768128809441.issue1012@psf.upfronthosting.co.za> New submission from O.R.Senthil Kumaran: * nair.jitendra at gmail.com [2007-08-24 06:12:52]: > hyperlink "site module documentation" in Section 4.1 on page > http://docs.python.org/inst/search-path.html leads to a nonexistent > page. > > Regards > jitendra nair 1) This needs to be fixed in the online doc, 2) Attaching a patch for the current trunk. ---------- components: Documentation files: module-site-url.patch messages: 55262 nosy: orsenthil severity: minor status: open title: Broken URL at Doc/install/index.rst versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: module-site-url.patch Type: text/x-diff Size: 686 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/4b68a838/attachment-0001.patch From report at bugs.python.org Fri Aug 24 19:39:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 17:39:07 -0000 Subject: [issue1006] Refactor test_winreg.py to use unittest. Message-ID: <1187977147.79.0.205372870095.issue1006@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks! Committed as rev. 57397. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 19:49:04 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 17:49:04 -0000 Subject: [issue1012] Broken URL at Doc/install/index.rst In-Reply-To: <1187976288.08.0.0768128809441.issue1012@psf.upfronthosting.co.za> Message-ID: <46CF1A16.8000107@gmx.net> Georg Brandl added the comment: Fixed in rev. 57398. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 20:08:31 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 18:08:31 -0000 Subject: [issue1008] Refactor test_signal.py to use unittest. In-Reply-To: <1187920447.34.0.203956739279.issue1008@psf.upfronthosting.co.za> Message-ID: <46CF1EA6.904@gmx.net> Georg Brandl added the comment: Fixed and committed as rev. 57399. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 21:02:52 2007 From: report at bugs.python.org (Paul Smith) Date: Fri, 24 Aug 2007 19:02:52 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1187982172.53.0.107668172464.issue1002@psf.upfronthosting.co.za> Paul Smith added the comment: I grep'd for HTMLParser module imports in other standard library modules, renamed, and ran the unit tests. I also updated the mapping in 2to3's fix_imports.py. The only thing I can't do is the actual `svn mv` to rename the module itself. Is part of the problem that this issue was initially flagged as Python 2.6? It's supposed to be 3.0, but that flag wasn't available yesterday when I opened it. ---------- versions: +Python 3.0 -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 21:03:13 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 19:03:13 -0000 Subject: [issue736962] Port tests to unittest (Part 2) Message-ID: <1187982193.38.0.773075122533.issue736962@psf.upfronthosting.co.za> Georg Brandl added the comment: The patches in here have long been applied, and the remaining converts are handled using individual issues. ---------- nosy: +georg.brandl status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Aug 24 21:05:50 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 19:05:50 -0000 Subject: [issue1399935] enhance unittest to define tests that *should* fail Message-ID: <1187982350.22.0.408500092351.issue1399935@psf.upfronthosting.co.za> Georg Brandl added the comment: Shouldn't the decorator name be lowercase? ---------- nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 21:07:11 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 19:07:11 -0000 Subject: [issue1703379] Refactor test_frozen.py to use unittest. Message-ID: <1187982431.42.0.800704148622.issue1703379@psf.upfronthosting.co.za> Georg Brandl added the comment: I've already ported this test a little differently before seeing this patch. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 21:19:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 19:19:47 -0000 Subject: [issue1671298] Refactor test_class to use unittest lib Message-ID: <1187983187.5.0.845158237783.issue1671298@psf.upfronthosting.co.za> Georg Brandl added the comment: I've figured out the problem with your call stack: the comparison of callLst with the expected calls adds more calls to callLst, leading to a failing comparison. I've fixed this, but the new test still fails with regrtest -R:: -- will investigate. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 21:34:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 19:34:25 -0000 Subject: [issue1671298] Refactor test_class to use unittest lib Message-ID: <1187984065.6.0.484365990347.issue1671298@psf.upfronthosting.co.za> Georg Brandl added the comment: Argh, the test modified the state of one of its classes. Fixed that and committed now as rev. 57409. ---------- assignee: collinwinter -> georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 21:39:00 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 19:39:00 -0000 Subject: [issue1706039] Added clearerr() to clear EOF state Message-ID: <1187984340.86.0.370994164651.issue1706039@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- assignee: -> loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 24 21:59:24 2007 From: report at bugs.python.org (Ray Ward) Date: Fri, 24 Aug 2007 19:59:24 -0000 Subject: [issue1013] eval error Message-ID: <1187985564.86.0.804664675786.issue1013@psf.upfronthosting.co.za> New submission from Ray Ward: >>> eval("9") 9 Works but. >>> eval("09") Traceback (most recent call last): File "", line 1, in File "", line 1 09 ^ SyntaxError: invalid token ---------- messages: 55272 nosy: Rayfward severity: normal status: open title: eval error type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 21:59:24 2007 From: report at bugs.python.org (Ray Ward) Date: Fri, 24 Aug 2007 19:59:24 -0000 Subject: [issue1013] eval error Message-ID: <1187985564.86.0.804664675786.issue1013@psf.upfronthosting.co.za> New submission from Ray Ward: >>> eval("9") 9 Works but. >>> eval("09") Traceback (most recent call last): File "", line 1, in File "", line 1 09 ^ SyntaxError: invalid token ---------- messages: 55272 nosy: Rayfward severity: normal status: open title: eval error type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 22:03:50 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 24 Aug 2007 20:03:50 -0000 Subject: [issue1013] eval error In-Reply-To: <1187985564.86.0.804664675786.issue1013@psf.upfronthosting.co.za> Message-ID: <46CF39AD.9040607@gmx.net> Georg Brandl added the comment: This is not a bug. Integers beginning with "0" are octal literals in Python 2.x, and "9" is not a valid octal digit. Closing as Invalid. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 22:54:35 2007 From: report at bugs.python.org (David Jessup) Date: Fri, 24 Aug 2007 20:54:35 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1187988875.14.0.418310958626.issue1014@psf.upfronthosting.co.za> New submission from David Jessup: In Python 2.4.4, cgi.parse_qs(qs='', strict_parsing=True) errors out: Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/cgi.py", line 183, in parse_qs for name, value in parse_qsl(qs, keep_blank_values, strict_parsing): File "/usr/lib/python2.4/cgi.py", line 217, in parse_qsl raise ValueError, "bad query field: %r" % (name_value,) ValueError: bad query field: '' To the best of my knowledge, this is bad behavior, since a large percentage of URLs actually used have empty query strings. ---------- components: Extension Modules messages: 55274 nosy: dljessup severity: normal status: open title: cgi: parse_qs and parse_qsl misbehave on empty strings type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 22:54:35 2007 From: report at bugs.python.org (David Jessup) Date: Fri, 24 Aug 2007 20:54:35 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1187988875.14.0.418310958626.issue1014@psf.upfronthosting.co.za> New submission from David Jessup: In Python 2.4.4, cgi.parse_qs(qs='', strict_parsing=True) errors out: Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/cgi.py", line 183, in parse_qs for name, value in parse_qsl(qs, keep_blank_values, strict_parsing): File "/usr/lib/python2.4/cgi.py", line 217, in parse_qsl raise ValueError, "bad query field: %r" % (name_value,) ValueError: bad query field: '' To the best of my knowledge, this is bad behavior, since a large percentage of URLs actually used have empty query strings. ---------- components: Extension Modules messages: 55274 nosy: dljessup severity: normal status: open title: cgi: parse_qs and parse_qsl misbehave on empty strings type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 24 23:20:08 2007 From: report at bugs.python.org (Keir Mierle) Date: Fri, 24 Aug 2007 21:20:08 -0000 Subject: [issue1015] [PATCH] Updated patch for rich dict view (dict().keys()) comparisons Message-ID: <1187990408.37.0.755658114648.issue1015@psf.upfronthosting.co.za> New submission from Keir Mierle: This an updated version of the patch I submitted earlier to python-3000; it is almost identical except it extends the test case to cover more of the code. ---------- components: Interpreter Core files: dictview_richcompare_ver2.diff messages: 55275 nosy: keir severity: normal status: open title: [PATCH] Updated patch for rich dict view (dict().keys()) comparisons versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictview_richcompare_ver2.diff Type: text/x-patch Size: 4663 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/df97dcdf/attachment.bin From report at bugs.python.org Fri Aug 24 23:20:08 2007 From: report at bugs.python.org (Keir Mierle) Date: Fri, 24 Aug 2007 21:20:08 -0000 Subject: [issue1015] [PATCH] Updated patch for rich dict view (dict().keys()) comparisons Message-ID: <1187990408.37.0.755658114648.issue1015@psf.upfronthosting.co.za> New submission from Keir Mierle: This an updated version of the patch I submitted earlier to python-3000; it is almost identical except it extends the test case to cover more of the code. ---------- components: Interpreter Core files: dictview_richcompare_ver2.diff messages: 55275 nosy: keir severity: normal status: open title: [PATCH] Updated patch for rich dict view (dict().keys()) comparisons versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictview_richcompare_ver2.diff Type: text/x-patch Size: 4663 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/df97dcdf/attachment-0001.bin From report at bugs.python.org Sat Aug 25 00:00:11 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Aug 2007 22:00:11 -0000 Subject: [issue1007] [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1187992811.62.0.339914354722.issue1007@psf.upfronthosting.co.za> Gregory P. Smith added the comment: looks like someone already committed the one liner dumbdbm latin-1 fix. But the meat of this patch is the unit test improvements. I had to fix test_whichdb to exclude dumbdbm as that has no file for whichdb to test. committed to py3k as r57419 ---------- nosy: +greg resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 00:06:52 2007 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Aug 2007 22:06:52 -0000 Subject: [issue1007] [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Message-ID: <1187993212.16.0.5996118783.issue1007@psf.upfronthosting.co.za> Larry Hastings added the comment: Yeah, Neil Norwitz added the one-line dumbdbm fix in r57358. Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 00:40:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 24 Aug 2007 22:40:07 -0000 Subject: [issue1015] [PATCH] Updated patch for rich dict view (dict().keys()) comparisons Message-ID: <1187995207.24.0.104072670575.issue1015@psf.upfronthosting.co.za> Guido van Rossum added the comment: Checked in (after substantial changes, pairing with Keir). ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 00:55:24 2007 From: report at bugs.python.org (Ero Carrera) Date: Fri, 24 Aug 2007 22:55:24 -0000 Subject: [issue1016] [PATCH] Updated fix for string to unicode fixes in time and datetime Message-ID: <1187996124.42.0.404094013819.issue1016@psf.upfronthosting.co.za> New submission from Ero Carrera: Small patch for the references leak in datetime and changed a strlen to PyUnicode_GET_SIZE() in time ---------- files: time_datetime_pystring_patch_2.diff messages: 55279 nosy: ero.carrera severity: normal status: open title: [PATCH] Updated fix for string to unicode fixes in time and datetime versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: time_datetime_pystring_patch_2.diff Type: application/octet-stream Size: 1096 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/429df472/attachment-0002.obj From report at bugs.python.org Sat Aug 25 00:55:24 2007 From: report at bugs.python.org (Ero Carrera) Date: Fri, 24 Aug 2007 22:55:24 -0000 Subject: [issue1016] [PATCH] Updated fix for string to unicode fixes in time and datetime Message-ID: <1187996124.42.0.404094013819.issue1016@psf.upfronthosting.co.za> New submission from Ero Carrera: Small patch for the references leak in datetime and changed a strlen to PyUnicode_GET_SIZE() in time ---------- files: time_datetime_pystring_patch_2.diff messages: 55279 nosy: ero.carrera severity: normal status: open title: [PATCH] Updated fix for string to unicode fixes in time and datetime versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: time_datetime_pystring_patch_2.diff Type: application/octet-stream Size: 1096 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/429df472/attachment-0003.obj From report at bugs.python.org Sat Aug 25 01:23:25 2007 From: report at bugs.python.org (Keir Mierle) Date: Fri, 24 Aug 2007 23:23:25 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1187997805.35.0.216708788919.issue1017@psf.upfronthosting.co.za> New submission from Keir Mierle: This patch adds set operations & | ^ - to dict views ({}.keys(), {}.items()). A set is returned. ---------- components: Interpreter Core files: dictview_set_operations.diff messages: 55280 nosy: keir severity: normal status: open title: [PATCH] Add set operations (and, or, xor, subtract) to dict views versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictview_set_operations.diff Type: text/x-patch Size: 3759 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/da85f58a/attachment.bin From report at bugs.python.org Sat Aug 25 01:23:25 2007 From: report at bugs.python.org (Keir Mierle) Date: Fri, 24 Aug 2007 23:23:25 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1187997805.35.0.216708788919.issue1017@psf.upfronthosting.co.za> New submission from Keir Mierle: This patch adds set operations & | ^ - to dict views ({}.keys(), {}.items()). A set is returned. ---------- components: Interpreter Core files: dictview_set_operations.diff messages: 55280 nosy: keir severity: normal status: open title: [PATCH] Add set operations (and, or, xor, subtract) to dict views versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: dictview_set_operations.diff Type: text/x-patch Size: 3759 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070824/da85f58a/attachment-0001.bin From report at bugs.python.org Sat Aug 25 01:36:23 2007 From: report at bugs.python.org (Keir Mierle) Date: Fri, 24 Aug 2007 23:36:23 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1187998584.0.0.00327722068283.issue1017@psf.upfronthosting.co.za> Changes by Keir Mierle: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 01:37:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 24 Aug 2007 23:37:19 -0000 Subject: [issue1015] [PATCH] Updated patch for rich dict view (dict().keys()) comparisons Message-ID: <1187998639.8.0.371907105478.issue1015@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 01:38:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 24 Aug 2007 23:38:03 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1187998683.43.0.609757997373.issue1017@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 01:46:56 2007 From: report at bugs.python.org (Keir Mierle) Date: Fri, 24 Aug 2007 23:46:56 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1187999216.07.0.410258480769.issue1017@psf.upfronthosting.co.za> Changes by Keir Mierle: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 02:14:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 00:14:24 -0000 Subject: [issue1017] [PATCH] Add set operations (and, or, xor, subtract) to dict views Message-ID: <1188000864.06.0.829106166829.issue1017@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- assignee: -> gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 02:44:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 00:44:30 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188002670.08.0.117613289765.issue1018@psf.upfronthosting.co.za> New submission from Guido van Rossum: Bill Janssen's patch for server-side ssl support (and certificate support). This still needs style cleanup, but is leak-free and passes tests. ---------- assignee: gvanrossum components: Extension Modules files: ssl-svr.diff keywords: patch messages: 55281 nosy: gvanrossum severity: normal status: open title: server-side ssl support type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl-svr.diff Type: text/x-patch Size: 21996 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/5da93bc8/attachment-0002.bin From report at bugs.python.org Sat Aug 25 02:44:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 00:44:30 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188002670.08.0.117613289765.issue1018@psf.upfronthosting.co.za> New submission from Guido van Rossum: Bill Janssen's patch for server-side ssl support (and certificate support). This still needs style cleanup, but is leak-free and passes tests. ---------- assignee: gvanrossum components: Extension Modules files: ssl-svr.diff keywords: patch messages: 55281 nosy: gvanrossum severity: normal status: open title: server-side ssl support type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl-svr.diff Type: text/x-patch Size: 21996 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/5da93bc8/attachment-0003.bin From report at bugs.python.org Sat Aug 25 02:45:19 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 00:45:19 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188002719.45.0.0621334551289.issue1018@psf.upfronthosting.co.za> Guido van Rossum added the comment: And another file that has a utility to be placed in Tools/... __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tools-diff Type: application/octet-stream Size: 2726 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/9f18bda9/attachment.obj From report at bugs.python.org Sat Aug 25 04:29:32 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 02:29:32 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188008972.73.0.313492398702.issue1018@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 04:29:39 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 02:29:39 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188008979.5.0.448894971437.issue1018@psf.upfronthosting.co.za> Changes by Guido van Rossum: __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 06:13:33 2007 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 25 Aug 2007 04:13:33 -0000 Subject: [issue1450807] Python build fails for gcc 4.x from Gnu Message-ID: <1188015213.2.0.810573693752.issue1450807@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin: ---------- nosy: +jyasskin _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Aug 25 07:55:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 25 Aug 2007 05:55:58 -0000 Subject: [issue1542308] Nested finally in generators don't follow PEP 342 Message-ID: <1188021358.6.0.697911002679.issue1542308@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- priority: immediate -> normal _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Aug 25 11:19:54 2007 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 25 Aug 2007 09:19:54 -0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting Message-ID: <1188033594.3.0.373839175377.issue1009@psf.upfronthosting.co.za> Eric V. Smith added the comment: Closed, code was checked in revision 57444. ---------- versions: +Python 3.0 -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 11:21:28 2007 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 25 Aug 2007 09:21:28 -0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting Message-ID: <1188033688.76.0.843972833287.issue1009@psf.upfronthosting.co.za> Eric V. Smith added the comment: I tried to close it, without success. Possible tracker issue, I'll investigate. It should be closed! __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 12:52:06 2007 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Aug 2007 10:52:06 -0000 Subject: [issue1764407] The -m switch does not use the builtin __main__ module Message-ID: <1188039126.44.0.178774128709.issue1764407@psf.upfronthosting.co.za> Nick Coghlan added the comment: Fixed committed to SVN as r57461 ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Aug 25 12:56:51 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Brian_Harring=0A=09=09=09=09?=) Date: Sat, 25 Aug 2007 10:56:51 -0000 Subject: [issue1574217] isinstance swallows exceptions Message-ID: <1188039411.52.0.145967227675.issue1574217@psf.upfronthosting.co.za> Changes by Brian Harring : ---------- versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Aug 25 17:09:20 2007 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Aug 2007 15:09:20 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188054560.69.0.284586407022.issue1018@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 57464. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 19:27:41 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 25 Aug 2007 17:27:41 -0000 Subject: [issue1020] pydoc doesn't work on pyexpat Message-ID: <1188062861.7.0.938537520444.issue1020@psf.upfronthosting.co.za> New submission from Neal Norwitz: help(pyexpat) causes an exception: Traceback (most recent call last): File "", line 1, in File "/home/neal/python/dev/py3k/Lib/site.py", line 350, in __call__ return pydoc.help(*args, **kwds) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1685, in __call__ self.help(request) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1729, in help else: doc(request, 'Help on %s:') File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1512, in doc pager(render_doc(thing, title, forceload)) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1490, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 319, in document if inspect.ismodule(object): return self.docmodule(*args) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1076, in docmodule contents.append(self.document(value, key, name)) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 320, in document if inspect.isclass(object): return self.docclass(*args) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1126, in docclass mro = deque(inspect.getmro(object)) TypeError: 'NoneType' object is not iterable ---------- components: Library (Lib) messages: 55289 nosy: nnorwitz severity: normal status: open title: pydoc doesn't work on pyexpat versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 19:27:41 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 25 Aug 2007 17:27:41 -0000 Subject: [issue1020] pydoc doesn't work on pyexpat Message-ID: <1188062861.7.0.938537520444.issue1020@psf.upfronthosting.co.za> New submission from Neal Norwitz: help(pyexpat) causes an exception: Traceback (most recent call last): File "", line 1, in File "/home/neal/python/dev/py3k/Lib/site.py", line 350, in __call__ return pydoc.help(*args, **kwds) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1685, in __call__ self.help(request) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1729, in help else: doc(request, 'Help on %s:') File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1512, in doc pager(render_doc(thing, title, forceload)) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1490, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 319, in document if inspect.ismodule(object): return self.docmodule(*args) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1076, in docmodule contents.append(self.document(value, key, name)) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 320, in document if inspect.isclass(object): return self.docclass(*args) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1126, in docclass mro = deque(inspect.getmro(object)) TypeError: 'NoneType' object is not iterable ---------- components: Library (Lib) messages: 55289 nosy: nnorwitz severity: normal status: open title: pydoc doesn't work on pyexpat versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 19:33:36 2007 From: report at bugs.python.org (viper) Date: Sat, 25 Aug 2007 17:33:36 -0000 Subject: [issue1021] logging.basicConfig does not allow to set NOTSET level Message-ID: <1188063216.88.0.427568296497.issue1021@psf.upfronthosting.co.za> Changes by viper: ---------- components: Library (Lib) severity: minor status: open title: logging.basicConfig does not allow to set NOTSET level versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 19:47:08 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 25 Aug 2007 17:47:08 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1188064028.04.0.310195892385.issue1022@psf.upfronthosting.co.za> New submission from Neal Norwitz: This patch has a hack to read in marshaled code objects. Bytes can't be marshaled currently (they are stored as strings). So when reading a marshaled code object, the hack converts them to bytes. All tests except test_modulefinder pass. The issue is that since bytes are mutable, they aren't suitable for code objects since a user could change them at any time. ---------- components: Interpreter Core files: code-bytes.patch messages: 55290 nosy: nnorwitz severity: normal status: open title: use bytes for code objects versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: code-bytes.patch Type: application/octet-stream Size: 20125 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/50f4b7be/attachment-0001.obj From report at bugs.python.org Sat Aug 25 19:47:08 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 25 Aug 2007 17:47:08 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1188064028.04.0.310195892385.issue1022@psf.upfronthosting.co.za> New submission from Neal Norwitz: This patch has a hack to read in marshaled code objects. Bytes can't be marshaled currently (they are stored as strings). So when reading a marshaled code object, the hack converts them to bytes. All tests except test_modulefinder pass. The issue is that since bytes are mutable, they aren't suitable for code objects since a user could change them at any time. ---------- components: Interpreter Core files: code-bytes.patch messages: 55290 nosy: nnorwitz severity: normal status: open title: use bytes for code objects versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: code-bytes.patch Type: application/octet-stream Size: 20125 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/50f4b7be/attachment-0002.obj From report at bugs.python.org Sat Aug 25 20:16:27 2007 From: report at bugs.python.org (Ero Carrera) Date: Sat, 25 Aug 2007 18:16:27 -0000 Subject: [issue1023] [PATCH] Unicode fixes in floatobject and moduleobject Message-ID: <1188065787.58.0.785721898944.issue1023@psf.upfronthosting.co.za> New submission from Ero Carrera: Removed calls to _PyUnicode_AsDefaultEncodedString and replaced them wit PyUnicode_AsString. Also removed calls to PyString_* and replaced them by the equivalent PyUnicode_* ---------- files: floatobject_moduleobject_pystring.patch messages: 55291 nosy: ero.carrera severity: normal status: open title: [PATCH] Unicode fixes in floatobject and moduleobject versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: floatobject_moduleobject_pystring.patch Type: application/octet-stream Size: 3735 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/261c66b6/attachment-0001.obj From report at bugs.python.org Sat Aug 25 20:16:27 2007 From: report at bugs.python.org (Ero Carrera) Date: Sat, 25 Aug 2007 18:16:27 -0000 Subject: [issue1023] [PATCH] Unicode fixes in floatobject and moduleobject Message-ID: <1188065787.58.0.785721898944.issue1023@psf.upfronthosting.co.za> New submission from Ero Carrera: Removed calls to _PyUnicode_AsDefaultEncodedString and replaced them wit PyUnicode_AsString. Also removed calls to PyString_* and replaced them by the equivalent PyUnicode_* ---------- files: floatobject_moduleobject_pystring.patch messages: 55291 nosy: ero.carrera severity: normal status: open title: [PATCH] Unicode fixes in floatobject and moduleobject versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: floatobject_moduleobject_pystring.patch Type: application/octet-stream Size: 3735 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/261c66b6/attachment-0002.obj From report at bugs.python.org Sat Aug 25 22:10:21 2007 From: report at bugs.python.org (Bill Janssen) Date: Sat, 25 Aug 2007 20:10:21 -0000 Subject: [issue1018] server-side ssl support Message-ID: <1188072621.76.0.395209174231.issue1018@psf.upfronthosting.co.za> Changes by Bill Janssen: ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Aug 25 22:15:12 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Sat, 25 Aug 2007 20:15:12 -0000 Subject: [issue1467929] %-formatting and dicts Message-ID: <1188072912.3.0.800044376931.issue1467929@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I'm attaching a new version of this which includes AMK's string patch ported over to unicode. Any objections to my committing this to the trunk? Should it also go in for the next 2.5 release? ---------- nosy: +jafo _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: format-v2.patch Type: text/x-patch Size: 3042 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070825/636b9ecc/attachment.bin From report at bugs.python.org Sun Aug 26 04:45:09 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:45:09 -0000 Subject: [issue1024] documentation for new SSL module Message-ID: <1188096309.88.0.45889663508.issue1024@psf.upfronthosting.co.za> New submission from Bill Janssen: Here's a documentation patch for the SSL code that was checked in yesterday. It removes discussion of SSL from the socket documentation, makes a change to the urllib2 doc's discussion of how to test for SSL support, and adds documentation of the SSL module and it's features, including some examples of how to use it. ---------- files: x2 keywords: patch messages: 55293 nosy: janssen priority: normal severity: normal status: open title: documentation for new SSL module type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: x2 Type: application/octet-stream Size: 19302 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/37f543a4/attachment-0001.obj From report at bugs.python.org Sun Aug 26 04:45:10 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:45:10 -0000 Subject: [issue1024] documentation for new SSL module Message-ID: <1188096309.88.0.45889663508.issue1024@psf.upfronthosting.co.za> New submission from Bill Janssen: Here's a documentation patch for the SSL code that was checked in yesterday. It removes discussion of SSL from the socket documentation, makes a change to the urllib2 doc's discussion of how to test for SSL support, and adds documentation of the SSL module and it's features, including some examples of how to use it. ---------- files: x2 keywords: patch messages: 55293 nosy: janssen priority: normal severity: normal status: open title: documentation for new SSL module type: rfe versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: x2 Type: application/octet-stream Size: 19302 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/37f543a4/attachment-0002.obj From report at bugs.python.org Sun Aug 26 04:48:31 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:48:31 -0000 Subject: [issue1024] documentation for new SSL module Message-ID: <1188096511.29.0.964731171821.issue1024@psf.upfronthosting.co.za> Bill Janssen added the comment: Sorry, long day: "...and its features..." __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Aug 26 04:51:17 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:51:17 -0000 Subject: [issue1024] documentation for new SSL module Message-ID: <1188096677.56.0.594648615619.issue1024@psf.upfronthosting.co.za> Changes by Bill Janssen: ---------- components: +Documentation __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Aug 26 04:56:09 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:56:09 -0000 Subject: [issue1114345] Add SSL certificate validation Message-ID: <1188096969.4.0.469179549153.issue1114345@psf.upfronthosting.co.za> Bill Janssen added the comment: I believe this is now fixed with patch 1018. ---------- nosy: +janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 04:56:53 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:56:53 -0000 Subject: [issue1027394] socket.ssl should explain that it is a 2/3 connection Message-ID: <1188097013.21.0.119378647223.issue1027394@psf.upfronthosting.co.za> Bill Janssen added the comment: Patch 1024 is new documentation which addresses this. Is is sufficient? ---------- nosy: +janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 04:57:23 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:57:23 -0000 Subject: [issue889813] making the version of SSL configurable when creating sockets Message-ID: <1188097043.26.0.846258027635.issue889813@psf.upfronthosting.co.za> Bill Janssen added the comment: I believe issue 1018 now fixes this. ---------- nosy: +janssen ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Aug 26 04:59:49 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 02:59:49 -0000 Subject: [issue1583946] SSL "issuer" and "server" names cannot be parsed Message-ID: <1188097189.65.0.0883974581335.issue1583946@psf.upfronthosting.co.za> Bill Janssen added the comment: I believe issue 1018 addressed this, and that it can be closed. Though socket.ssl, and its methods "server" and "issuer", should be deprecated. ---------- nosy: +janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 05:02:57 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 03:02:57 -0000 Subject: [issue1217246] proposed patch for tls wrapped ssl support added to smtplib Message-ID: <1188097377.86.0.459515129212.issue1217246@psf.upfronthosting.co.za> Bill Janssen added the comment: This probably needs to be re-written with the new SSL support in 2.6. See issue 1024. ---------- nosy: +janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 05:04:31 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 03:04:31 -0000 Subject: [issue783188] support for server side transactions in _ssl Message-ID: <1188097471.13.0.529933930843.issue783188@psf.upfronthosting.co.za> Bill Janssen added the comment: I believe issue 1018 renders this one moot. Though more examples in Demo is still a good idea. I'll contribute a threaded server example for that. ---------- nosy: +janssen ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Aug 26 05:06:51 2007 From: report at bugs.python.org (Bill Janssen) Date: Sun, 26 Aug 2007 03:06:51 -0000 Subject: [issue1706815] socket.error exceptions not subclass of StandardError Message-ID: <1188097611.68.0.738023526653.issue1706815@psf.upfronthosting.co.za> Bill Janssen added the comment: It's not clear to me that having the SSL errors inherit from socket.error is a good idea. Many of them have nothing to do with the socket, but are errors in choice of cipher, certificate validation, etc. ---------- nosy: +janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 05:06:51 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Aug 2007 03:06:51 -0000 Subject: [issue1583946] SSL "issuer" and "server" names cannot be parsed Message-ID: <1188097611.27.0.158005200872.issue1583946@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- nosy: -greg _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 05:11:29 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Aug 2007 03:11:29 -0000 Subject: [issue1706815] socket.error exceptions not subclass of StandardError In-Reply-To: <1188097611.68.0.738023526653.issue1706815@psf.upfronthosting.co.za> Message-ID: <52dc1c820708252011l794abc32mdb2165d350cf8124@mail.gmail.com> Gregory P. Smith added the comment: Does the existing python SSL implementation allow it to be used over something other than a socket? If so then yes that makes sense, but otherwise its best to leave its inheritance from socket.error so that code that works when handed a regular socket can work over an SSL socket without knowing the difference. fwiw, regarding this bug the last comment I heard from guido on the python-dev list was that socket.error should at least be a subclass of EnvironmentError. I'm still a fan of having it a subclass of IOError myself for similar reason as above (things already written to use a file object as a stream could use a socket object and still handle errors properly; most code check for IOError rather than EnvironmentError if for no reason other than IOError is easier to type and easier to read and understand what it means) On 8/25/07, Bill Janssen wrote: > > Bill Janssen added the comment: > > It's not clear to me that having the SSL errors inherit from socket.error > is a good idea. Many of them have nothing to do with the socket, but are > errors in choice of cipher, certificate validation, etc. > > ---------- > nosy: +janssen > > _____________________________________ > Tracker > > _____________________________________ > ---------- nosy: +gps _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 05:37:20 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 03:37:20 -0000 Subject: [issue1025] tracebacks from list comps (probably other comps) don't show full stack Message-ID: <1188099440.22.0.56979431714.issue1025@psf.upfronthosting.co.za> New submission from Neal Norwitz: A traceback that occurs within a list comprehension (and probably all comprehensions) only shows the stack from the comprehension, not the entire scope: Traceback (most recent call last): File "Lib/test/test_multibytecodec_support.py", line 35, in test_chunkcoding for f in self.tstring]): File "Lib/test/test_multibytecodec_support.py", line 35, in for f in self.tstring]): UnicodeDecodeError: 'utf8' codec can't decode byte 0xa6 in position 0: unexpected code byte ---------- components: Interpreter Core keywords: py3k messages: 55303 nosy: nnorwitz severity: normal status: open title: tracebacks from list comps (probably other comps) don't show full stack versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Aug 26 05:37:20 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 03:37:20 -0000 Subject: [issue1025] tracebacks from list comps (probably other comps) don't show full stack Message-ID: <1188099440.22.0.56979431714.issue1025@psf.upfronthosting.co.za> New submission from Neal Norwitz: A traceback that occurs within a list comprehension (and probably all comprehensions) only shows the stack from the comprehension, not the entire scope: Traceback (most recent call last): File "Lib/test/test_multibytecodec_support.py", line 35, in test_chunkcoding for f in self.tstring]): File "Lib/test/test_multibytecodec_support.py", line 35, in for f in self.tstring]): UnicodeDecodeError: 'utf8' codec can't decode byte 0xa6 in position 0: unexpected code byte ---------- components: Interpreter Core keywords: py3k messages: 55303 nosy: nnorwitz severity: normal status: open title: tracebacks from list comps (probably other comps) don't show full stack versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Aug 26 07:20:44 2007 From: report at bugs.python.org (Senthil) Date: Sun, 26 Aug 2007 05:20:44 -0000 Subject: [issue1779700] urlparse.urljoin does not obey current uri rfc (rfc 3986) Message-ID: <1188105644.09.0.148115319476.issue1779700@psf.upfronthosting.co.za> Senthil added the comment: The following issue/patch tries to addresses the same. http://bugs.python.org/issue1462525 - It needs work though. ---------- nosy: +orsenthil _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 11:29:15 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Grzegorz_Adam_Hankiewicz=0A=09=09=09=09?=) Date: Sun, 26 Aug 2007 09:29:15 -0000 Subject: [issue1777458] glob doesn't return unicode with unicode parameter Message-ID: <1188120555.11.0.819805404272.issue1777458@psf.upfronthosting.co.za> Grzegorz Adam Hankiewicz added the comment: Previous bug report would be now http://bugs.python.org/issue1001604. ---------- type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 11:30:29 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Grzegorz_Adam_Hankiewicz=0A=09=09=09=09?=) Date: Sun, 26 Aug 2007 09:30:29 -0000 Subject: [issue1739648] zipfile.testzip() using progressive file reads Message-ID: <1188120629.91.0.36751733125.issue1739648@psf.upfronthosting.co.za> Grzegorz Adam Hankiewicz added the comment: Any progress report on this issue, please? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 11:31:58 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Grzegorz_Adam_Hankiewicz=0A=09=09=09=09?=) Date: Sun, 26 Aug 2007 09:31:58 -0000 Subject: [issue1760357] ZipFile.write fails with bad modification time Message-ID: <1188120718.21.0.780477303008.issue1760357@psf.upfronthosting.co.za> Grzegorz Adam Hankiewicz added the comment: Any progress report on this issue, please? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Aug 26 19:21:23 2007 From: report at bugs.python.org (Benjamin Aranguren) Date: Sun, 26 Aug 2007 17:21:23 -0000 Subject: [issue1026] Backport ABC to 2.6 Message-ID: <1188148883.43.0.130535847782.issue1026@psf.upfronthosting.co.za> New submission from Benjamin Aranguren: Worked with Alex Martelli at the Google Python Sprint to backport ABC to 2.6. Added abc.py and test_abc.py to svn trunk. ---------- components: Library (Lib) files: pyABC_backport_to_2_6.patch messages: 55308 nosy: baranguren severity: normal status: open title: Backport ABC to 2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pyABC_backport_to_2_6.patch Type: text/x-patch Size: 14799 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/e51f512e/attachment-0002.bin From report at bugs.python.org Sun Aug 26 19:21:23 2007 From: report at bugs.python.org (Benjamin Aranguren) Date: Sun, 26 Aug 2007 17:21:23 -0000 Subject: [issue1026] Backport ABC to 2.6 Message-ID: <1188148883.43.0.130535847782.issue1026@psf.upfronthosting.co.za> New submission from Benjamin Aranguren: Worked with Alex Martelli at the Google Python Sprint to backport ABC to 2.6. Added abc.py and test_abc.py to svn trunk. ---------- components: Library (Lib) files: pyABC_backport_to_2_6.patch messages: 55308 nosy: baranguren severity: normal status: open title: Backport ABC to 2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pyABC_backport_to_2_6.patch Type: text/x-patch Size: 14799 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/e51f512e/attachment-0003.bin From report at bugs.python.org Sun Aug 26 19:49:52 2007 From: report at bugs.python.org (Senthil) Date: Sun, 26 Aug 2007 17:49:52 -0000 Subject: [issue1014] cgi: parse_qs and parse_qsl misbehave on empty strings Message-ID: <1188150592.56.0.254171871103.issue1014@psf.upfronthosting.co.za> Senthil added the comment: Can query strings be empty? I am unable to find an instance. ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Aug 26 21:02:31 2007 From: report at bugs.python.org (Gregory Dudek) Date: Sun, 26 Aug 2007 19:02:31 -0000 Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached Message-ID: <1188154951.36.0.982331068077.issue1027@psf.upfronthosting.co.za> Changes by Gregory Dudek: ---------- components: Extension Modules severity: normal status: open title: uudecoding (uu.py) does not supprt base64, patch attached type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Aug 26 21:04:18 2007 From: report at bugs.python.org (Gregory Dudek) Date: Sun, 26 Aug 2007 19:04:18 -0000 Subject: [issue1027] uudecoding (uu.py) does not supprt base64, patch attached Message-ID: <1188155058.19.0.438776826235.issue1027@psf.upfronthosting.co.za> New submission from Gregory Dudek: The uu.py library for uuencoding and uudecoding does not support base64 encodins. The patch addached here adds base64 decoding, but does not add encoding support. ---------- nosy: +dudek __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: uu.py-base64ugrade.diff Type: application/octet-stream Size: 2107 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/1b3e1b46/attachment.obj From report at bugs.python.org Sun Aug 26 22:48:32 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 26 Aug 2007 20:48:32 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za> New submission from Kurt B. Kaiser: The control-spacebar binding is used in IDLE to force open the completions window. It's causing IDLE to exit with a utf8 decode error. Attached is a Tkinter cut-down exhibiting the problem and a patch. The cutdown runs ok on 2.6 but not on py3k because the latter uses PyUnicode_FromString on all the arguments and errs out when it encounters a character outside the utf-8 range. Strangely, on my system, control-spacebar is sending a two byte string, C0E8 via the %A parameter. Control-2 does the same. Other keys with combinations of modifier keys send one byte. Linux trader 2.6.18-ARCH #1 SMP PREEMPT Sun Nov 19 09:14:35 CET 2006 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux Can the problem be confirmed? Using PyUnicode_FromUnicode on %A works because the unicode string is copied instead of decoded, and that parameter is supposed to be unicode, in any case. The patch fixes the problem on my system but should be reviewed, especially whether the cast in the call to PyUnicode_FromUnicode is suitably cross- platform. Assigning to Neal since he's working a lot of Unicode issues right now. I can check it in if I get approval. ---------- assignee: nnorwitz components: Tkinter files: tkintertest.py keywords: patch, py3k messages: 55311 nosy: kbk severity: normal status: open title: Tkinter binding involving Control-spacebar raises unicode error versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tkintertest.py Type: application/x-python Size: 725 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/627d2772/attachment.bin From report at bugs.python.org Sun Aug 26 22:48:31 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 26 Aug 2007 20:48:31 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za> New submission from Kurt B. Kaiser: The control-spacebar binding is used in IDLE to force open the completions window. It's causing IDLE to exit with a utf8 decode error. Attached is a Tkinter cut-down exhibiting the problem and a patch. The cutdown runs ok on 2.6 but not on py3k because the latter uses PyUnicode_FromString on all the arguments and errs out when it encounters a character outside the utf-8 range. Strangely, on my system, control-spacebar is sending a two byte string, C0E8 via the %A parameter. Control-2 does the same. Other keys with combinations of modifier keys send one byte. Linux trader 2.6.18-ARCH #1 SMP PREEMPT Sun Nov 19 09:14:35 CET 2006 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux Can the problem be confirmed? Using PyUnicode_FromUnicode on %A works because the unicode string is copied instead of decoded, and that parameter is supposed to be unicode, in any case. The patch fixes the problem on my system but should be reviewed, especially whether the cast in the call to PyUnicode_FromUnicode is suitably cross- platform. Assigning to Neal since he's working a lot of Unicode issues right now. I can check it in if I get approval. ---------- assignee: nnorwitz components: Tkinter files: tkintertest.py keywords: patch, py3k messages: 55311 nosy: kbk severity: normal status: open title: Tkinter binding involving Control-spacebar raises unicode error versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tkintertest.py Type: application/x-python Size: 725 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/627d2772/attachment-0001.bin From report at bugs.python.org Sun Aug 26 22:53:20 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 26 Aug 2007 20:53:20 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188161600.51.0.289167600648.issue1028@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Heh, I see we have the same damn problem SF had: when a comment is edited, it doesn't re-wrap properly when submitted. You have to remove the returns manually after editing. __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _tkinter.c.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/a4630ae0/attachment.txt From report at bugs.python.org Sun Aug 26 22:54:14 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 26 Aug 2007 20:54:14 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188161654.86.0.937861258224.issue1028@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Nope, you have to make sure not to type too wide. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 00:04:04 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 22:04:04 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188165843.93.0.300230591529.issue1029@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: io.StrinIO.getvalue() correctly decodes bytes from the underlying buffer, but does not translate \r\n to \n. Python 3.0x (py3k, Aug 26 2007, 14:39:16) [MSC v.1400 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import io >>> a = io.StringIO() >>> a.write('\n') 2 >>> a.getvalue() '\r\n' The attached patch corrects this and adds a test. ---------- components: Library (Lib), Windows files: stringio.diff messages: 55314 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: io.StringIO.getvalue() returns \r\n type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: stringio.diff Type: application/octet-stream Size: 1013 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/ccb5c883/attachment-0001.obj From report at bugs.python.org Mon Aug 27 00:04:03 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 22:04:03 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188165843.93.0.300230591529.issue1029@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: io.StrinIO.getvalue() correctly decodes bytes from the underlying buffer, but does not translate \r\n to \n. Python 3.0x (py3k, Aug 26 2007, 14:39:16) [MSC v.1400 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import io >>> a = io.StringIO() >>> a.write('\n') 2 >>> a.getvalue() '\r\n' The attached patch corrects this and adds a test. ---------- components: Library (Lib), Windows files: stringio.diff messages: 55314 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: io.StringIO.getvalue() returns \r\n type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: stringio.diff Type: application/octet-stream Size: 1013 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/ccb5c883/attachment-0002.obj From report at bugs.python.org Mon Aug 27 00:08:05 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 22:08:05 -0000 Subject: [issue1030] py3k: Adapt _winreg.c to the new buffer API Message-ID: <1188166085.62.0.766008221618.issue1030@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: ---------- components: Windows files: winreg.diff severity: normal status: open title: py3k: Adapt _winreg.c to the new buffer API type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 00:12:08 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 22:12:08 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188166328.09.0.63889684473.issue1031@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch is necessary to compile inside the PCBuild8 directory ---------- components: Windows files: vc2005.diff messages: 55315 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: compilation with VC2005 type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: vc2005.diff Type: application/octet-stream Size: 8174 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/c0d9a703/attachment-0002.obj From report at bugs.python.org Mon Aug 27 00:12:08 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 22:12:08 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188166328.09.0.63889684473.issue1031@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: This patch is necessary to compile inside the PCBuild8 directory ---------- components: Windows files: vc2005.diff messages: 55315 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: compilation with VC2005 type: compile error versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: vc2005.diff Type: application/octet-stream Size: 8174 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/c0d9a703/attachment-0003.obj From report at bugs.python.org Mon Aug 27 01:04:34 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 23:04:34 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188169474.6.0.398003653754.issue1031@psf.upfronthosting.co.za> Neal Norwitz added the comment: Thanks for the patch. I tried to apply this patch, but almost everything failed. Could you make sure to do a svn update and then generate the patch? The only part of the patch that applied cleanly was to rmpyc.py. That was checked in as: Committed revision 57527. ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:07:36 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 26 Aug 2007 23:07:36 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1188169656.44.0.377858080562.issue1032@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: In distutils.unixccompiler, there is a hack to passing correctly the -R option to gcc (and a few other compilers). However, there is a small bug that causes gcc to not be detected correctly if the compiler name does not start with "gcc" (e.g., "i486-linux-gnu-gcc", or "ccache gcc"). ---------- components: Distutils messages: 55317 nosy: alexandre.vassalotti severity: minor status: open title: Improve the hackish runtime_library_dirs support for gcc type: compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:07:36 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 26 Aug 2007 23:07:36 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1188169656.44.0.377858080562.issue1032@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: In distutils.unixccompiler, there is a hack to passing correctly the -R option to gcc (and a few other compilers). However, there is a small bug that causes gcc to not be detected correctly if the compiler name does not start with "gcc" (e.g., "i486-linux-gnu-gcc", or "ccache gcc"). ---------- components: Distutils messages: 55317 nosy: alexandre.vassalotti severity: minor status: open title: Improve the hackish runtime_library_dirs support for gcc type: compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:07:43 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 23:07:43 -0000 Subject: [issue1030] py3k: Adapt _winreg.c to the new buffer API Message-ID: <1188169663.33.0.920990807137.issue1030@psf.upfronthosting.co.za> New submission from Neal Norwitz: Thanks! I can't test this, but I applied the change. It makes sense to me. Committed revision 57528. ---------- assignee: -> nnorwitz nosy: +nnorwitz resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:09:53 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 23:09:53 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188169793.39.0.436467162908.issue1031@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Sorry, it's probably because I somehow converted the line endings. Attached a new version of the patch. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: vc2005-2.diff Type: application/octet-stream Size: 8547 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/eb225cb9/attachment.obj From report at bugs.python.org Mon Aug 27 01:09:58 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 26 Aug 2007 23:09:58 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1188169798.62.0.68662349959.issue1032@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:16:44 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 23:16:44 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188170204.98.0.565480630898.issue1031@psf.upfronthosting.co.za> Neal Norwitz added the comment: Hmmm, the patch was out of date (I had already removed cPickle). However, I don't think that was the reason for everything failing. I manually applied the changes to the files and python version. Things should be pretty good now. I didn't add the libraries. I'm not sure why they are needed now while they weren't necessary before. Committed revision 57529. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:17:33 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 26 Aug 2007 23:17:33 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188170253.31.0.343843022482.issue1028@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:18:36 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Sun, 26 Aug 2007 23:18:36 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188170316.4.0.622216637391.issue1028@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Well, maybe someday Tk will send a multibyte unicode character. Update the patch. __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: _tkinter.c.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070826/76b17f5c/attachment.txt From report at bugs.python.org Mon Aug 27 01:21:47 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 23:21:47 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188170507.5.0.691613344149.issue1031@psf.upfronthosting.co.za> Neal Norwitz added the comment: I thought it might be line endings so I tried changing them, but that didn't help. I couldn't apply the new version of the patch either. I'm not sure if the problem is on your side or mine. :-( I missed some files from the original checkin. The new one hopefully has all the files and is just missing the libraries. Can you svn update and look at the new differences? Thanks. Committed revision 57530. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:26:30 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 26 Aug 2007 23:26:30 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188170790.83.0.521592576817.issue1029@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: As far as I know, StringIO should not do any string transformations. >From PEP-3116 "New I/O", last paragraph of the section "Text I/O": > Another implementation, StringIO, creates a file-like TextIO > implementation without an underlying Buffered I/O object. [...] It > does not support encodings or newline translations; you always read > back exactly the characters you wrote. ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:35:10 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 23:35:10 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188171310.6.0.995448708369.issue1029@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > As far as I know, StringIO should not do any string transformations. (Not sure if you agree with the patch or not) That's why the current behaviour is not correct: When I write('\n'), getvalue() currently returns '\r\n'. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:40:39 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 23:40:39 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188171638.99.0.942097258544.issue1028@psf.upfronthosting.co.za> Neal Norwitz added the comment: I can confirm the problem and that your patch fixes the problem. Go ahead and check it in. Thanks! ---------- assignee: nnorwitz -> kbk nosy: +nnorwitz resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:43:34 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 Aug 2007 23:43:34 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188171814.24.0.235709007158.issue1031@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, everything compiles now. I discovered that the additional libraries not necessary if I update my VC 2005 Express installation as in this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=133236&SiteID=1 > The problem is that the default installation of VS 8 express > doesn't support the Platform SDK, so, after installing the > platform SDK, you need to make a few modifications... > > 1. Update the corewin_express.vsprops file (NOT the > corewin.vsprops file). (In the c:/Program Files/Microsoft Visual Studio 8/VC/VCProjectDefaults/ directory) > You need to change this... > > AdditionalDependencies="kernel32.lib" > > to this > > AdditionalDependencies="kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib" > And everything compiles fine without further modification. Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 01:48:22 2007 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 26 Aug 2007 23:48:22 -0000 Subject: [issue1031] py3k: compilation with VC2005 Message-ID: <1188172102.07.0.741516336402.issue1031@psf.upfronthosting.co.za> Neal Norwitz added the comment: Awesome! I'm going to close this patch. Let me know if you have any more problems. Feel free to send messages to python-3000. I would like py3k to build on Windows for the alpha which will be coming out in about a week hopefully. ---------- assignee: -> nnorwitz resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 02:10:44 2007 From: report at bugs.python.org (Adam Hupp) Date: Mon, 27 Aug 2007 00:10:44 -0000 Subject: [issue1033] Support for newline and encoding in tempfile module Message-ID: <1188173444.49.0.820359174757.issue1033@psf.upfronthosting.co.za> New submission from Adam Hupp: It would be useful for tempfile.TemporaryFile and friends to pass newline and encoding arguments to the underlying io.open call. For example, several tests in test_csv use TemporaryFile and need to handle unicode file output or preserve exact newlines. This is simpler with direct support in TemporaryFile. The attached patch makes the following changes: 1) tempfile.TemporaryFile, NamedTemporaryFile, and SpooledTemporaryFile now pass newline and encoding to the underlying io.open call. 2) test_tempfile is updated 3) test_csv is updated to use the new arguments. ---------- components: Library (Lib) files: tempfile-newline-encoding.patch messages: 55328 nosy: hupp severity: normal status: open title: Support for newline and encoding in tempfile module type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tempfile-newline-encoding.patch Type: application/octet-stream Size: 12447 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/ea64ffc3/attachment-0001.obj From report at bugs.python.org Mon Aug 27 02:10:44 2007 From: report at bugs.python.org (Adam Hupp) Date: Mon, 27 Aug 2007 00:10:44 -0000 Subject: [issue1033] Support for newline and encoding in tempfile module Message-ID: <1188173444.49.0.820359174757.issue1033@psf.upfronthosting.co.za> New submission from Adam Hupp: It would be useful for tempfile.TemporaryFile and friends to pass newline and encoding arguments to the underlying io.open call. For example, several tests in test_csv use TemporaryFile and need to handle unicode file output or preserve exact newlines. This is simpler with direct support in TemporaryFile. The attached patch makes the following changes: 1) tempfile.TemporaryFile, NamedTemporaryFile, and SpooledTemporaryFile now pass newline and encoding to the underlying io.open call. 2) test_tempfile is updated 3) test_csv is updated to use the new arguments. ---------- components: Library (Lib) files: tempfile-newline-encoding.patch messages: 55328 nosy: hupp severity: normal status: open title: Support for newline and encoding in tempfile module type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: tempfile-newline-encoding.patch Type: application/octet-stream Size: 12447 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/ea64ffc3/attachment-0002.obj From report at bugs.python.org Mon Aug 27 02:14:05 2007 From: report at bugs.python.org (Adam Hupp) Date: Mon, 27 Aug 2007 00:14:05 -0000 Subject: [issue1033] Support for newline and encoding in tempfile module Message-ID: <1188173645.31.0.354611457643.issue1033@psf.upfronthosting.co.za> Adam Hupp added the comment: One change I forgot to mention that may need discussion. I've changed the 'bufsize' arguments in tempfile to 'buffering', since that is consistent with the same change in os.fdopen. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 03:57:04 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 27 Aug 2007 01:57:04 -0000 Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode error Message-ID: <1188179824.13.0.735234774686.issue1028@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: OK, thanks for the review! I suppose Tk is sending a bad string. r57540 ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 04:20:52 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Mon, 27 Aug 2007 02:20:52 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za> New submission from Adrian Holovaty: Per a Python-3000 mailing list discussion here -- http://mail.python.org/pipermail/python-3000/2007-August/009835.html -- I have implemented an addition to the 2to3 utility that enables warnings to be output as comments in Python source code instead of being logged to stdout. See the attached patch and a description of the changes here: http://mail.python.org/pipermail/python-3000/2007-August/009881.html ---------- components: Demos and Tools files: 2to3_insert_comment.diff messages: 55331 nosy: adrianholovaty severity: normal status: open title: [patch] Add 2to3 support for displaying warnings as Python comments __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 2to3_insert_comment.diff Type: application/octet-stream Size: 11032 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/1be486fe/attachment-0001.obj From report at bugs.python.org Mon Aug 27 04:20:52 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Mon, 27 Aug 2007 02:20:52 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za> New submission from Adrian Holovaty: Per a Python-3000 mailing list discussion here -- http://mail.python.org/pipermail/python-3000/2007-August/009835.html -- I have implemented an addition to the 2to3 utility that enables warnings to be output as comments in Python source code instead of being logged to stdout. See the attached patch and a description of the changes here: http://mail.python.org/pipermail/python-3000/2007-August/009881.html ---------- components: Demos and Tools files: 2to3_insert_comment.diff messages: 55331 nosy: adrianholovaty severity: normal status: open title: [patch] Add 2to3 support for displaying warnings as Python comments __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 2to3_insert_comment.diff Type: application/octet-stream Size: 11032 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/1be486fe/attachment-0002.obj From report at bugs.python.org Mon Aug 27 04:21:54 2007 From: report at bugs.python.org (Adrian Holovaty) Date: Mon, 27 Aug 2007 02:21:54 -0000 Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as Python comments Message-ID: <1188181314.16.0.533651951796.issue1034@psf.upfronthosting.co.za> Adrian Holovaty added the comment: I'm also attaching 2to3_comment_warnings.diff, which is an example of how we could integrate the insert_comment() method from the first patch to replace the current functionality of fixes.basefix.BaseFix.warning(). __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 2to3_comment_warnings.diff Type: application/octet-stream Size: 741 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/04a42727/attachment.obj From report at bugs.python.org Mon Aug 27 09:42:49 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 07:42:49 -0000 Subject: [issue1035] bytes buffer API needs to support PyBUF_LOCKDATA Message-ID: <1188200568.98.0.237862868597.issue1035@psf.upfronthosting.co.za> New submission from Gregory P. Smith: I've converted _bsddb.c to use the py3k buffer API for all data and keys it takes as input. All tests now fail with this error: BufferError: Cannot make this object read-only. This presumably results from this call: PyObject_GetBuffer(obj, view, PyBUF_LOCKDATA) I need to lock the data so that the GIL can be released during database operations (I/O). Allowing bytes objects to have an immutability or readonly bit (internal or otherwise) has been a recent topic on the python-3000 mailing list; that would allow bytes' buffer API to satisfy this GetBuffer LOCKDATA request... ---------- components: Interpreter Core keywords: py3k messages: 55333 nosy: gregory.p.smith priority: normal severity: normal status: open title: bytes buffer API needs to support PyBUF_LOCKDATA type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 09:42:48 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 07:42:48 -0000 Subject: [issue1035] bytes buffer API needs to support PyBUF_LOCKDATA Message-ID: <1188200568.98.0.237862868597.issue1035@psf.upfronthosting.co.za> New submission from Gregory P. Smith: I've converted _bsddb.c to use the py3k buffer API for all data and keys it takes as input. All tests now fail with this error: BufferError: Cannot make this object read-only. This presumably results from this call: PyObject_GetBuffer(obj, view, PyBUF_LOCKDATA) I need to lock the data so that the GIL can be released during database operations (I/O). Allowing bytes objects to have an immutability or readonly bit (internal or otherwise) has been a recent topic on the python-3000 mailing list; that would allow bytes' buffer API to satisfy this GetBuffer LOCKDATA request... ---------- components: Interpreter Core keywords: py3k messages: 55333 nosy: gregory.p.smith priority: normal severity: normal status: open title: bytes buffer API needs to support PyBUF_LOCKDATA type: rfe versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 09:45:53 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 07:45:53 -0000 Subject: [issue1036] py3k _bsddb.c patch to use the new buffer API Message-ID: <1188200753.37.0.488727674557.issue1036@psf.upfronthosting.co.za> New submission from Gregory P. Smith: This is my svn diff of a py3k Modules/_bsddb.c converted to use the buffer API. I'm submitting it here as so it doesn't get misplaced as it currently won't work until bytes objects support PyBUF_LOCKDATA (a separate bug) ---------- assignee: gregory.p.smith components: Extension Modules files: py3k-_bsddb-bufferAPI-001.patch keywords: patch, py3k messages: 55334 nosy: gregory.p.smith severity: normal status: open title: py3k _bsddb.c patch to use the new buffer API versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-_bsddb-bufferAPI-001.patch Type: text/x-patch Size: 27792 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/47bbdbf7/attachment-0002.bin From report at bugs.python.org Mon Aug 27 09:45:53 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 07:45:53 -0000 Subject: [issue1036] py3k _bsddb.c patch to use the new buffer API Message-ID: <1188200753.37.0.488727674557.issue1036@psf.upfronthosting.co.za> New submission from Gregory P. Smith: This is my svn diff of a py3k Modules/_bsddb.c converted to use the buffer API. I'm submitting it here as so it doesn't get misplaced as it currently won't work until bytes objects support PyBUF_LOCKDATA (a separate bug) ---------- assignee: gregory.p.smith components: Extension Modules files: py3k-_bsddb-bufferAPI-001.patch keywords: patch, py3k messages: 55334 nosy: gregory.p.smith severity: normal status: open title: py3k _bsddb.c patch to use the new buffer API versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: py3k-_bsddb-bufferAPI-001.patch Type: text/x-patch Size: 27792 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/47bbdbf7/attachment-0003.bin From report at bugs.python.org Mon Aug 27 09:48:19 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 07:48:19 -0000 Subject: [issue1035] bytes buffer API needs to support PyBUF_LOCKDATA Message-ID: <1188200899.14.0.264483277953.issue1035@psf.upfronthosting.co.za> Changes by Gregory P. Smith: ---------- priority: normal -> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 14:43:25 2007 From: report at bugs.python.org (Hye-Shik Chang) Date: Mon, 27 Aug 2007 12:43:25 -0000 Subject: [issue1037] Ill-coded identifier crashes python when coding spec is utf-8 Message-ID: <1188218605.0.0.993381507884.issue1037@psf.upfronthosting.co.za> New submission from Hye-Shik Chang: Illegal identifier makes python crash on UTF-8 source codes/interpreters. Python 3.0x (py3k:57555M, Aug 27 2007, 21:23:47) [GCC 3.4.6 [FreeBSD] 20060305] on freebsd6 >>> compile(b'#coding:utf-8\n\xfc', '', 'exec') zsh: segmentation fault (core dumped) ./python The problem is that tokenizer.c:verify_identifer doesn't check return value from PyUnicode_DecodeUTF8 but some invalid utf8 sequences could be there. ---------- components: Unicode keywords: py3k messages: 55335 nosy: hyeshik.chang priority: high severity: normal status: open title: Ill-coded identifier crashes python when coding spec is utf-8 type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 14:43:25 2007 From: report at bugs.python.org (Hye-Shik Chang) Date: Mon, 27 Aug 2007 12:43:25 -0000 Subject: [issue1037] Ill-coded identifier crashes python when coding spec is utf-8 Message-ID: <1188218605.0.0.993381507884.issue1037@psf.upfronthosting.co.za> New submission from Hye-Shik Chang: Illegal identifier makes python crash on UTF-8 source codes/interpreters. Python 3.0x (py3k:57555M, Aug 27 2007, 21:23:47) [GCC 3.4.6 [FreeBSD] 20060305] on freebsd6 >>> compile(b'#coding:utf-8\n\xfc', '', 'exec') zsh: segmentation fault (core dumped) ./python The problem is that tokenizer.c:verify_identifer doesn't check return value from PyUnicode_DecodeUTF8 but some invalid utf8 sequences could be there. ---------- components: Unicode keywords: py3k messages: 55335 nosy: hyeshik.chang priority: high severity: normal status: open title: Ill-coded identifier crashes python when coding spec is utf-8 type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 15:43:20 2007 From: report at bugs.python.org (Armin Rigo) Date: Mon, 27 Aug 2007 13:43:20 -0000 Subject: [issue1202533] a bunch of infinite C recursions Message-ID: <1188222200.4.0.088848456331.issue1202533@psf.upfronthosting.co.za> Armin Rigo added the comment: Assigning to Brett instead of me (according to the tracker history). ---------- assignee: arigo -> brett.cannon _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Aug 27 19:45:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Aug 2007 17:45:27 -0000 Subject: [issue1771364] Misc improvements for the io module Message-ID: <1188236727.88.0.065203622162.issue1771364@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks!! Committed revision 57564. SocketIO was recently moved to socket.py because that's the only place that uses it. So I've removed it from io.__all__. The only other change I applied was related to the isatty check -- you accidentally changed things so that buffering would *always* be set to 1 if raw.isatty is true. The intention was for this to affect the default only. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Aug 27 20:11:34 2007 From: report at bugs.python.org (Phillip J. Eby) Date: Mon, 27 Aug 2007 18:11:34 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1188238294.01.0.0928033489046.issue1739468@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Patch implementing an alternate approach: support automatically importing __main__ when sys.argv[0] is an importable path. This allows zip files, directories, and any future importable locations (e.g. URLs) to be used on the command line. Note that this also means that you don't need an option on the #! line in a zip file, which avoids hairy #! issues on platforms like Linux (where a #! line can have at most one argument). __main__ is used instead of __zipmain__, since it is not zipfile specific. ---------- nosy: +pje _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Aug 27 20:12:20 2007 From: report at bugs.python.org (Phillip J. Eby) Date: Mon, 27 Aug 2007 18:12:20 -0000 Subject: [issue1739468] Add a -z interpreter flag to execute a zip file Message-ID: <1188238340.6.0.637147552487.issue1739468@psf.upfronthosting.co.za> Changes by Phillip J. Eby: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Aug 27 21:11:48 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Aug 2007 19:11:48 -0000 Subject: [issue1024] documentation for new SSL module Message-ID: <1188241908.87.0.367076911547.issue1024@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 57570. I didn't review it though. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Aug 27 22:51:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Aug 2007 20:51:14 -0000 Subject: [issue1739906] Add reduce to functools in 2.6 Message-ID: <1188247874.04.0.077706605489.issue1739906@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 57574. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 00:38:50 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 27 Aug 2007 22:38:50 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188254330.68.0.752574943468.issue1029@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > That's why the current behaviour is not correct: When I write('\n'), > getvalue() currently returns '\r\n'. Oh, I missed your example in your initial message. So yes, I agree that StringIO shouldn't translate newlines like that. I attached a patch that should fix the bug. However, I would favor removing the "newline" keyword argument, instead. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: no_write_nl_translate.patch Type: text/x-diff Size: 371 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070827/ec75e860/attachment.patch From report at bugs.python.org Tue Aug 28 01:32:11 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 23:32:11 -0000 Subject: [issue1038] [py3k] pdb does not work in python 3000 Message-ID: <1188257531.14.0.772690749596.issue1038@psf.upfronthosting.co.za> New submission from Gregory P. Smith: The Lib/pdb.py debugger fails in the py3k branch. Traceback (most recent call last): File "/usr/local/gps/python/py3k/Lib/pdb.py", line 1247, in main pdb._runscript(mainpyfile) File "/usr/local/gps/python/py3k/Lib/pdb.py", line 1173, in _runscript self.run(statement) File "/usr/local/gps/python/py3k/Lib/bdb.py", line 365, in run exec(cmd, globals, locals) File "", line 1 exec("# bla bla bla first line of your file being debugged ^ SyntaxError: EOL while scanning single-quoted string Uncaught exception. Entering post mortem debugging ---------- components: Library (Lib) keywords: py3k messages: 55342 nosy: gregory.p.smith severity: normal status: open title: [py3k] pdb does not work in python 3000 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 01:32:11 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Aug 2007 23:32:11 -0000 Subject: [issue1038] [py3k] pdb does not work in python 3000 Message-ID: <1188257531.14.0.772690749596.issue1038@psf.upfronthosting.co.za> New submission from Gregory P. Smith: The Lib/pdb.py debugger fails in the py3k branch. Traceback (most recent call last): File "/usr/local/gps/python/py3k/Lib/pdb.py", line 1247, in main pdb._runscript(mainpyfile) File "/usr/local/gps/python/py3k/Lib/pdb.py", line 1173, in _runscript self.run(statement) File "/usr/local/gps/python/py3k/Lib/bdb.py", line 365, in run exec(cmd, globals, locals) File "", line 1 exec("# bla bla bla first line of your file being debugged ^ SyntaxError: EOL while scanning single-quoted string Uncaught exception. Entering post mortem debugging ---------- components: Library (Lib) keywords: py3k messages: 55342 nosy: gregory.p.smith severity: normal status: open title: [py3k] pdb does not work in python 3000 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 02:32:37 2007 From: report at bugs.python.org (Martin von Gagern) Date: Tue, 28 Aug 2007 00:32:37 -0000 Subject: [issue1670765] email.Generator: no header wrapping for multipart/signed Message-ID: <1188261157.31.0.633528338059.issue1670765@psf.upfronthosting.co.za> Martin von Gagern added the comment: Looks like I missed your comments on this patch. What kind of tests do you have in mind? Tests demonstrating where current implementation fails and my patch will help? Or rather tests checking that this patch won't break anything else? The former would be easy enough, but for the latter I'm not sure how far this would go, as people tend to make strange assumptions I would never have thought of. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 02:37:59 2007 From: report at bugs.python.org (Collin Winter) Date: Tue, 28 Aug 2007 00:37:59 -0000 Subject: [issue1670765] email.Generator: no header wrapping for multipart/signed Message-ID: <1188261479.33.0.738596017543.issue1670765@psf.upfronthosting.co.za> Collin Winter added the comment: I'd like some tests demonstrating where the current implementation fails and your patch helps, yes. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 03:14:05 2007 From: report at bugs.python.org (Seo Sanghyeon) Date: Tue, 28 Aug 2007 01:14:05 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1188263645.82.0.46005381111.issue1032@psf.upfronthosting.co.za> Seo Sanghyeon added the comment: The patch is incorrect since find returns -1 on failure. This is also a duplicate of #1254718. ---------- nosy: +sanxiyn __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 03:55:08 2007 From: report at bugs.python.org (Martin von Gagern) Date: Tue, 28 Aug 2007 01:55:08 -0000 Subject: [issue1670765] email.Generator: no header wrapping for multipart/signed Message-ID: <1188266108.44.0.614013799164.issue1670765@psf.upfronthosting.co.za> Martin von Gagern added the comment: Take the attached test5.eml. Run it through the following python script: import email print (email.message_from_file(open("test5.eml")).as_string(False)) The result will have both instances of the X-Long-Line header rewrapped. As the second instance is included in the digest calculation, the signature verification will now fail. This is a real world signature algorithm, following RFC 3156 (if I didn't make a mistake). If you have an OpenPGP-enabled mailreader (e.g. enigmail for Thunderbird) and have some way of injecting a mail as is into your mail folders (e.g. a maildir-based server), then you can use this setup to verify that the signature was correct in the first place and is broken after parsing and reconstruction by python. If you don't have such a setup available, and you don't believe me that rewrapping the header breaks the signature, then I could either devise some unrealistic but easy-to-check signing process, or could try to get this working with an S/MIME signature using an X.509 certificate. I would rather avoid this, though. _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 1343 Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/9bb22ecd/attachment.eml From report at bugs.python.org Tue Aug 28 03:58:09 2007 From: report at bugs.python.org (Ismail Donmez) Date: Tue, 28 Aug 2007 01:58:09 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188266289.59.0.179742603001.issue1528802@psf.upfronthosting.co.za> Ismail Donmez added the comment: This works fine with python 2.4 : >>> import locale >>> locale.setlocale(locale.LC_ALL,"tr_TR.UTF-8") 'tr_TR.UTF-8' >>> print u"May?s".upper() MAYIS ---------- nosy: +cartman _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 05:25:14 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 03:25:14 -0000 Subject: [issue459007] Document sys.path on Windows Message-ID: <1188271514.71.0.833317237984.issue459007@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This is a high priority item that hasn't been touched in half a decade. Mark: Consider this a reminder if this is still on your agenda to do. If not, shall we just close it? Is there anyone else that could do this? ---------- nosy: +jafo ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Aug 28 05:30:24 2007 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Aug 2007 03:30:24 -0000 Subject: [issue1033] Support for newline and encoding in tempfile module Message-ID: <1188271824.44.0.46722008843.issue1033@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Committed revision 57594. General note: please run Tools/scripts/reindent.py over your files after editing so I won't have to. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 07:48:57 2007 From: report at bugs.python.org (Ali Gholami Rudi) Date: Tue, 28 Aug 2007 05:48:57 -0000 Subject: [issue1774736] Binding fails Message-ID: <1188280137.03.0.652410364702.issue1774736@psf.upfronthosting.co.za> Changes by Ali Gholami Rudi: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 08:01:59 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:01:59 -0000 Subject: [issue1039] Asssertion in Windows debug build Message-ID: <1188280918.82.0.842547677227.issue1039@psf.upfronthosting.co.za> New submission from Thomas Heller: In a windows debug build, an assertion is triggered when os.execvpe is called with an empty argument list: self.assertRaises(OSError, os.execvpe, 'no such app-', [], None) The same problem is present in the trunk version. Attached is a patch that fixes this, with a test. ---------- components: Windows files: os.diff messages: 55350 nosy: theller severity: normal status: open title: Asssertion in Windows debug build type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: os.diff Type: text/x-diff Size: 1082 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/fa4c99c8/attachment.diff From report at bugs.python.org Tue Aug 28 08:01:58 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:01:58 -0000 Subject: [issue1039] Asssertion in Windows debug build Message-ID: <1188280918.82.0.842547677227.issue1039@psf.upfronthosting.co.za> New submission from Thomas Heller: In a windows debug build, an assertion is triggered when os.execvpe is called with an empty argument list: self.assertRaises(OSError, os.execvpe, 'no such app-', [], None) The same problem is present in the trunk version. Attached is a patch that fixes this, with a test. ---------- components: Windows files: os.diff messages: 55350 nosy: theller severity: normal status: open title: Asssertion in Windows debug build type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: os.diff Type: text/x-diff Size: 1082 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/fa4c99c8/attachment-0001.diff From report at bugs.python.org Tue Aug 28 08:05:53 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:05:53 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188281153.24.0.208218954264.issue1040@psf.upfronthosting.co.za> New submission from Thomas Heller: In my german version of winXP SP2, python3 cannot import the time module: c:\svn\py3k\PCbuild>python_d Python 3.0x (py3k:57600M, Aug 28 2007, 07:58:23) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf8' codec can't decode bytes in position 9-11: invalid data [36719 refs] >>> ^Z The problem is that the libc '_tzname' variable contains umlauts. For comparison, here is what Python2.5 does: c:\svn\py3k\PCbuild>\python25\python Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('Westeurop\xe4ische Normalzeit', 'Westeurop\xe4ische Normalzeit') >>> ---------- components: Windows messages: 55351 nosy: theller severity: normal status: open title: Unicode problem with TZ versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:05:53 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:05:53 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188281153.24.0.208218954264.issue1040@psf.upfronthosting.co.za> New submission from Thomas Heller: In my german version of winXP SP2, python3 cannot import the time module: c:\svn\py3k\PCbuild>python_d Python 3.0x (py3k:57600M, Aug 28 2007, 07:58:23) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf8' codec can't decode bytes in position 9-11: invalid data [36719 refs] >>> ^Z The problem is that the libc '_tzname' variable contains umlauts. For comparison, here is what Python2.5 does: c:\svn\py3k\PCbuild>\python25\python Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('Westeurop\xe4ische Normalzeit', 'Westeurop\xe4ische Normalzeit') >>> ---------- components: Windows messages: 55351 nosy: theller severity: normal status: open title: Unicode problem with TZ versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:06:52 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:06:52 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188281212.16.0.929864322978.issue1040@psf.upfronthosting.co.za> Thomas Heller added the comment: BTW, setting the environment variable TZ to, say, 'GMT' makes the problem go away. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:09:59 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:09:59 -0000 Subject: [issue1041] io.py problems on Windows Message-ID: <1188281399.05.0.285209324523.issue1041@psf.upfronthosting.co.za> New submission from Thomas Heller: Running the PCBuild\rt.bat script fails when it compares the expected output with the actual output. Some inspection shows that the comparison fails because there are '\n' linefeeds in the expected and '\n\r' linefeeds in the actual output: c:\svn\py3k\PCbuild>python_d -E -tt ../lib/test/regrtest.py test_grammar test test_grammar produced unexpected output: ********************************************************************** *** mismatch between line 1 of expected output and line 1 of actual output: - test_grammar + test_grammar ? + (['test_grammar\n'], ['test_grammar\r\n']) ... and so on ... (The last line is printed by some code I added to Lib\regrtest.py.) It seems that this behaviour was introduced by r57186: New I/O code from Tony Lownds implement newline feature correctly, and implements .newlines attribute in a 2.x-compatible fashion. The patch at http://bugs.python.org/issue1029 apparently fixes this problem. ---------- components: Windows messages: 55353 nosy: theller severity: normal status: open title: io.py problems on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:09:59 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:09:59 -0000 Subject: [issue1041] io.py problems on Windows Message-ID: <1188281399.05.0.285209324523.issue1041@psf.upfronthosting.co.za> New submission from Thomas Heller: Running the PCBuild\rt.bat script fails when it compares the expected output with the actual output. Some inspection shows that the comparison fails because there are '\n' linefeeds in the expected and '\n\r' linefeeds in the actual output: c:\svn\py3k\PCbuild>python_d -E -tt ../lib/test/regrtest.py test_grammar test test_grammar produced unexpected output: ********************************************************************** *** mismatch between line 1 of expected output and line 1 of actual output: - test_grammar + test_grammar ? + (['test_grammar\n'], ['test_grammar\r\n']) ... and so on ... (The last line is printed by some code I added to Lib\regrtest.py.) It seems that this behaviour was introduced by r57186: New I/O code from Tony Lownds implement newline feature correctly, and implements .newlines attribute in a 2.x-compatible fashion. The patch at http://bugs.python.org/issue1029 apparently fixes this problem. ---------- components: Windows messages: 55353 nosy: theller severity: normal status: open title: io.py problems on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:11:28 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:11:28 -0000 Subject: [issue1042] test_glob fails with UnicodeDecodeError Message-ID: <1188281488.85.0.654479324079.issue1042@psf.upfronthosting.co.za> New submission from Thomas Heller: Unicode errors in various tests - not only in test_glob: test_glob test test_glob failed -- Traceback (most recent call last): File "c:\svn\py3k\lib\test\test_glob.py", line 87, in test_glob_directory_names eq(self.glob('*', '*a'), []) File "c:\svn\py3k\lib\test\test_glob.py", line 41, in glob res = glob.glob(p) File "c:\svn\py3k\lib\glob.py", line 16, in glob return list(iglob(pathname)) File "c:\svn\py3k\lib\glob.py", line 42, in iglob for name in glob_in_dir(dirname, basename): File "c:\svn\py3k\lib\glob.py", line 56, in glob1 names = os.listdir(dirname) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 27-31: unexpected end of data ---------- components: Windows messages: 55354 nosy: theller severity: normal status: open title: test_glob fails with UnicodeDecodeError versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:11:28 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:11:28 -0000 Subject: [issue1042] test_glob fails with UnicodeDecodeError Message-ID: <1188281488.85.0.654479324079.issue1042@psf.upfronthosting.co.za> New submission from Thomas Heller: Unicode errors in various tests - not only in test_glob: test_glob test test_glob failed -- Traceback (most recent call last): File "c:\svn\py3k\lib\test\test_glob.py", line 87, in test_glob_directory_names eq(self.glob('*', '*a'), []) File "c:\svn\py3k\lib\test\test_glob.py", line 41, in glob res = glob.glob(p) File "c:\svn\py3k\lib\glob.py", line 16, in glob return list(iglob(pathname)) File "c:\svn\py3k\lib\glob.py", line 42, in iglob for name in glob_in_dir(dirname, basename): File "c:\svn\py3k\lib\glob.py", line 56, in glob1 names = os.listdir(dirname) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 27-31: unexpected end of data ---------- components: Windows messages: 55354 nosy: theller severity: normal status: open title: test_glob fails with UnicodeDecodeError versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:12:10 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:12:10 -0000 Subject: [issue1043] test_builtin failure on Windows Message-ID: <1188281529.99.0.469968116024.issue1043@psf.upfronthosting.co.za> New submission from Thomas Heller: test test_builtin failed -- Traceback (most recent call last): File "c:\svn\py3k\lib\test\test_builtin.py", line 1473, in test_round self.assertEqual(round(1e20), 1e20) AssertionError: 0 != 1e+020 ---------- components: Windows messages: 55355 nosy: theller severity: normal status: open title: test_builtin failure on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 08:12:10 2007 From: report at bugs.python.org (Thomas Heller) Date: Tue, 28 Aug 2007 06:12:10 -0000 Subject: [issue1043] test_builtin failure on Windows Message-ID: <1188281529.99.0.469968116024.issue1043@psf.upfronthosting.co.za> New submission from Thomas Heller: test test_builtin failed -- Traceback (most recent call last): File "c:\svn\py3k\lib\test\test_builtin.py", line 1473, in test_round self.assertEqual(round(1e20), 1e20) AssertionError: 0 != 1e+020 ---------- components: Windows messages: 55355 nosy: theller severity: normal status: open title: test_builtin failure on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 10:24:57 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 28 Aug 2007 08:24:57 -0000 Subject: [issue1036] py3k _bsddb.c patch to use the new buffer API Message-ID: <1188289497.24.0.283471005673.issue1036@psf.upfronthosting.co.za> Gregory P. Smith added the comment: committed to py3k branch using SIMPLE instead of LOCKDATA: r57610 ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 10:29:22 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 08:29:22 -0000 Subject: [issue515751] Missing docs for module imputil Message-ID: <1188289762.11.0.266912362615.issue515751@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I've committed some *very* basic documentation as Doc/library/imputil.rst. This is mostly pulling the documentation I could find in the web and in the code and setting it up in Python doc format. I'm adding people who have recently touched the module, as well as Greg, to the nosy list. If someone could expand it, particularly the sections marked "Undocumented", that'd be great. Though the documentation is not perfect, it is something. I'm going to close this bug, let me know if there are any objections. ---------- nosy: +georg.brandl, gstein, jafo, loewis, tim_one status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Aug 28 10:37:05 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 08:37:05 -0000 Subject: [issue1530559] struct.pack raises TypeError where it used to convert Message-ID: <1188290225.21.0.39956712928.issue1530559@psf.upfronthosting.co.za> Sean Reifschneider added the comment: etrepum: Can you fix the test which caused this to be re-opened? I'm tempted to push this down in priority from urgent to high, since the code is (apparently) fixed, just the test is failing, but ideally this could just get fixed. ---------- nosy: +jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 10:40:18 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 08:40:18 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1188290418.47.0.144063922135.issue1692335@psf.upfronthosting.co.za> Changes by Sean Reifschneider: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 10:40:38 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 08:40:38 -0000 Subject: [issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__ Message-ID: <1188290438.26.0.627530256343.issue1692335@psf.upfronthosting.co.za> Changes by Sean Reifschneider: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 11:00:55 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 09:00:55 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188291655.95.0.00919860563892.issue1029@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a new version of the class, which removes the 'newline' argument from the constructor. I also removed the 'encoding' argument, since this is really an implementation detail of the underlying buffer. Index: Lib/io.py =================================================================== --- Lib/io.py (revision 57564) +++ Lib/io.py (working copy) @@ -1390,10 +1390,10 @@ # XXX This is really slow, but fully functional - def __init__(self, initial_value="", encoding="utf-8", newline=None): + def __init__(self, initial_value=""): super(StringIO, self).__init__(BytesIO(), - encoding=encoding, - newline=newline) + encoding="utf-8", + newline='\n') if initial_value: if not isinstance(initial_value, basestring): initial_value = str(initial_value) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 11:14:55 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 09:14:55 -0000 Subject: [issue775964] fix test_grp failing on RedHat 6.2 Message-ID: <1188292495.58.0.420896885979.issue775964@psf.upfronthosting.co.za> Sean Reifschneider added the comment: A few comments on this one: Perhaps the tests should be patched instead of the grp module? Because it may be useful for someone to know that old-style NIS maps are being referenced. I presume if the change is made in grp that it should also be made in pwd? Shouldn't the patch do a "continue" instead of a break? I believe the "+" entry means "include the contents of the NIS map here (I don't believe it can be used for LDAP), and as far as I know does not HAVE to be included at the end of the file. We probably don't care, but just to be canonical it seems that there are also "+name" and "-name" entries in /etc/group and /etc/passwd. "+name" in an entry is the same as a "name" entry, but the additional fields are read from NIS. "-name" means that "name" is not a valid user (in other words, don't let "name" login, even if they exist in NIS). I can't imagine we want to implement those though, because... Note that the "+" syntax is the old syntax from before nsswitch was introduced. As far as I know, + syntax was deprecated back in 1995 when nsswitch.conf was added. In conclusion, I think the tests that the tests that annoy Anthony should be fixed, but I'm not convinced the behavior of grp should be changed. Particularly without a corresponding change in pwd. Thoughts? See the following URL for more information about the +/- syntax: http://bama.ua.edu/cgi-bin/man-cgi?nsswitch.conf+4 ---------- nosy: +jafo ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Aug 28 12:08:23 2007 From: report at bugs.python.org (Huang Peng) Date: Tue, 28 Aug 2007 10:08:23 -0000 Subject: [issue708374] add offset to mmap Message-ID: <1188295703.73.0.731343190053.issue708374@psf.upfronthosting.co.za> Changes by Huang Peng: ---------- nosy: +phuang ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Aug 28 12:09:24 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 28 Aug 2007 10:09:24 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188295764.62.0.164889561412.issue1044@psf.upfronthosting.co.za> New submission from Lars Gust?bel: tarfile does not check pathnames or linknames on extraction. This can lead to data loss or attack scenarios when members with absolute pathnames or pathnames outside of the archive's scope overwrite or overlay existing files or directories. Example for a symlink attack against /etc/passwd: foo -> /etc foo/passwd ---------- assignee: lars.gustaebel components: Library (Lib) files: insecure_pathnames.diff keywords: patch messages: 55361 nosy: lars.gustaebel, matejcik priority: normal severity: normal status: open title: tarfile insecure pathname extraction type: security versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: insecure_pathnames.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/e4895b3c/attachment.txt From report at bugs.python.org Tue Aug 28 12:09:24 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 28 Aug 2007 10:09:24 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188295764.62.0.164889561412.issue1044@psf.upfronthosting.co.za> New submission from Lars Gust?bel: tarfile does not check pathnames or linknames on extraction. This can lead to data loss or attack scenarios when members with absolute pathnames or pathnames outside of the archive's scope overwrite or overlay existing files or directories. Example for a symlink attack against /etc/passwd: foo -> /etc foo/passwd ---------- assignee: lars.gustaebel components: Library (Lib) files: insecure_pathnames.diff keywords: patch messages: 55361 nosy: lars.gustaebel, matejcik priority: normal severity: normal status: open title: tarfile insecure pathname extraction type: security versions: Python 2.6 __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: insecure_pathnames.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/e4895b3c/attachment-0001.txt From report at bugs.python.org Tue Aug 28 12:10:12 2007 From: report at bugs.python.org (Huang Peng) Date: Tue, 28 Aug 2007 10:10:12 -0000 Subject: [issue1089974] mmap missing offset parameter Message-ID: <1188295812.71.0.443283609951.issue1089974@psf.upfronthosting.co.za> Changes by Huang Peng: ---------- nosy: +phuang _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 12:22:34 2007 From: report at bugs.python.org (jan matejek) Date: Tue, 28 Aug 2007 10:22:34 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188296554.66.0.0227551850849.issue1044@psf.upfronthosting.co.za> jan matejek added the comment: no change to extract() ? otherwise looks good to me. if you don't object, i am applying this to SUSE's python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 12:26:08 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 10:26:08 -0000 Subject: [issue1597011] Reading with bz2.BZ2File() returns one garbage character Message-ID: <1188296768.17.0.940722994522.issue1597011@psf.upfronthosting.co.za> Sean Reifschneider added the comment: There are some bugs in the bz2 module. The problem boils down to the following code, notice how *c is assigned *BEFORE* the check to see if there was a read error: do { BZ2_bzRead(&bzerror, f->fp, &c, 1); f->pos++; *buf++ = c; } while (bzerror == BZ_OK && c != '\n' && buf != end); This could be fixed by putting a "if (bzerror == BZ_OK) break;" after the BZ2_bzRead() call. However, I also noticed that in the universal newline section of the code it is reading a character, incrementing f->pos, *THEN* checking if buf == end and if so is throwing away the character. I changed the code around so that the read loop is unified between universal newlines and regular newlines. I guess this is a small performance penalty, since it's checking the newline mode for each character read, however we're already doing a system call for every character so one additional comparison and jump to merge duplicate code for maintenance reasons is probably a good plan. Especially since the reason for this bug only existed in one of the two duplicated parts of the code. Please let me know if this looks good to commit. ---------- nosy: +jafo _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-trunk-bz2.patch Type: text/x-patch Size: 1694 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/72e7a164/attachment-0001.bin From report at bugs.python.org Tue Aug 28 12:26:52 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 10:26:52 -0000 Subject: [issue1597011] Reading with bz2.BZ2File() returns one garbage character Message-ID: <1188296812.18.0.0967332718817.issue1597011@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- assignee: -> jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 12:31:43 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 10:31:43 -0000 Subject: [issue1403221] 2.3.5 source RPM install fails w/o tk-devel Message-ID: <1188297103.69.0.700886228665.issue1403221@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I'm going to call this closed because this is basically a build environment problem and the RPM can't really detect it at build time. This is noted in the RPM building FAQ, and if you search for the "unclear" message you will find the resolution (either installing the TK development package or removing the TK runtime package, depending on your exact needs). ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 12:32:53 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 10:32:53 -0000 Subject: [issue1000] Patch to rename *Server modules to lower-case Message-ID: <1188297173.24.0.953310575998.issue1000@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 12:45:21 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 28 Aug 2007 10:45:21 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188297921.2.0.976837560951.issue1044@psf.upfronthosting.co.za> Lars Gust?bel added the comment: In principle I do not object, but this is a preliminary patch. I am still not happy with the naming of the "check_paths" argument. Also, the patch was made against the trunk which means that it contains hunks with the new reStructuredText documentation. Please be patient. I do not change extract() because it has become more and more a low-level method over the years, that makes promises it cannot keep and should not be used at all. I try to discourage its use in the documentation. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 17:06:24 2007 From: report at bugs.python.org (Andreas Kloeckner) Date: Tue, 28 Aug 2007 15:06:24 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1188313584.39.0.0655511033178.issue1045@psf.upfronthosting.co.za> New submission from Andreas Kloeckner: The attached program uncovers a two-fold performance regression in Python 2.5 with respect to Python 2.4. Below, the "element-wise" case goes from 2.5 seconds in 2.4 to about 4 in 2.5. Since that's a pretty serious increase, I thought I'd point it out. $ python2.5 periodic_test.py elwise 3.91989398003 collective 1.21577095985 $ python2.4 periodic_test.py elwise 2.50014710426 tuplewise 1.35589385033 ---------- components: Interpreter Core, Library (Lib) files: periodic_test.py messages: 55366 nosy: inducer severity: normal status: open title: Performance regression in 2.5 type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: periodic_test.py Type: text/x-python Size: 1053 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/0e3458ce/attachment.py From report at bugs.python.org Tue Aug 28 17:06:24 2007 From: report at bugs.python.org (Andreas Kloeckner) Date: Tue, 28 Aug 2007 15:06:24 -0000 Subject: [issue1045] Performance regression in 2.5 Message-ID: <1188313584.39.0.0655511033178.issue1045@psf.upfronthosting.co.za> New submission from Andreas Kloeckner: The attached program uncovers a two-fold performance regression in Python 2.5 with respect to Python 2.4. Below, the "element-wise" case goes from 2.5 seconds in 2.4 to about 4 in 2.5. Since that's a pretty serious increase, I thought I'd point it out. $ python2.5 periodic_test.py elwise 3.91989398003 collective 1.21577095985 $ python2.4 periodic_test.py elwise 2.50014710426 tuplewise 1.35589385033 ---------- components: Interpreter Core, Library (Lib) files: periodic_test.py messages: 55366 nosy: inducer severity: normal status: open title: Performance regression in 2.5 type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: periodic_test.py Type: text/x-python Size: 1053 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/0e3458ce/attachment-0001.py From report at bugs.python.org Tue Aug 28 17:30:02 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:30:02 -0000 Subject: [issue1617682] specialcase simple sliceobj in tuple/str/unicode Message-ID: <1188315002.85.0.368562245521.issue1617682@psf.upfronthosting.co.za> Thomas Wouters added the comment: Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:30:34 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:30:34 -0000 Subject: [issue1617691] Extended slicing for UserString Message-ID: <1188315034.53.0.957974306198.issue1617691@psf.upfronthosting.co.za> Thomas Wouters added the comment: Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:30:56 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:30:56 -0000 Subject: [issue1617698] Extended slicing for array objects Message-ID: <1188315056.35.0.974077497746.issue1617698@psf.upfronthosting.co.za> Thomas Wouters added the comment: Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:31:18 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:31:18 -0000 Subject: [issue1617700] slice-object support for mmap Message-ID: <1188315078.45.0.151820102633.issue1617700@psf.upfronthosting.co.za> Thomas Wouters added the comment: Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:31:35 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:31:35 -0000 Subject: [issue1617701] extended slicing for structseq Message-ID: <1188315095.11.0.106318605999.issue1617701@psf.upfronthosting.co.za> Thomas Wouters added the comment: Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:31:59 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:31:59 -0000 Subject: [issue1617702] extended slicing for buffer objects Message-ID: <1188315119.15.0.954131118266.issue1617702@psf.upfronthosting.co.za> Thomas Wouters added the comment: Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:36:04 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:36:04 -0000 Subject: [issue1617687] specialcase simple sliceobj in list (and bugfixes) Message-ID: <1188315364.7.0.417619690409.issue1617687@psf.upfronthosting.co.za> Thomas Wouters added the comment: I prefer the current method, as it's more obviously walking in two strides across the same array. I also dislike hiding the final memmove() of the tail bit inside the loop. As for which is more obvious, I would submit neither is obvious, as it took me quite a bit of brainsweat to figure out how either version was supposed to work after not looking at the code for months :) Committed revision 57619. ---------- assignee: -> twouters resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:37:44 2007 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 28 Aug 2007 15:37:44 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188315464.43.0.699764273011.issue1617699@psf.upfronthosting.co.za> Thomas Wouters added the comment: I'd like to check this into the trunk, without the non-step-1 support for now, so that we can remove simple slicing from the py3k branch. We can always add non-step-1 support later (all the sooner if someone who isn't me volunteers to do the painful bits of that support, probably by copy-pasting from the array module ;-) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 17:53:22 2007 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 28 Aug 2007 15:53:22 -0000 Subject: [issue1032] Improve the hackish runtime_library_dirs support for gcc Message-ID: <1188316402.07.0.0917284090405.issue1032@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > The patch is incorrect since find returns -1 on failure. Oops, that is right. I attached the corrected patch. __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: better_gcc_detection-2.patch Type: text/x-diff Size: 572 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/fefdb0eb/attachment.patch From report at bugs.python.org Tue Aug 28 18:07:04 2007 From: report at bugs.python.org (inefab) Date: Tue, 28 Aug 2007 16:07:04 -0000 Subject: [issue1046] HTMLCalendar.formatyearpage not behaving as documented Message-ID: <1188317224.86.0.133502540854.issue1046@psf.upfronthosting.co.za> New submission from inefab: The function HTMLCalendar.formatyearpage in module calendar takes at most 5 arguments (year, month, css, encoding) whereas documentation (http://docs.python.org/lib/module-calendar.html) says it takes at most 6 (theyear, themonth[, width[, css[, encoding]]]). Also, the title tag in the head of the produced document with (year, month, css) as arguments isn't properly closed ; the line is Calendar for 2008Calendar for 2008 This happend with linux (debian sid), with Python 2.5.1 Note: I haven't tested if the encoding did what it should Joined files : - HTMLyearbug.py: reproduces the bug - 2008cal.html: the output produced by this file ---------- components: Extension Modules files: cal.py messages: 55376 nosy: inefab severity: normal status: open title: HTMLCalendar.formatyearpage not behaving as documented type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cal.py Type: text/x-python Size: 557 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/8de7785e/attachment.py From report at bugs.python.org Tue Aug 28 18:07:05 2007 From: report at bugs.python.org (inefab) Date: Tue, 28 Aug 2007 16:07:05 -0000 Subject: [issue1046] HTMLCalendar.formatyearpage not behaving as documented Message-ID: <1188317224.86.0.133502540854.issue1046@psf.upfronthosting.co.za> New submission from inefab: The function HTMLCalendar.formatyearpage in module calendar takes at most 5 arguments (year, month, css, encoding) whereas documentation (http://docs.python.org/lib/module-calendar.html) says it takes at most 6 (theyear, themonth[, width[, css[, encoding]]]). Also, the title tag in the head of the produced document with (year, month, css) as arguments isn't properly closed ; the line is Calendar for 2008Calendar for 2008 This happend with linux (debian sid), with Python 2.5.1 Note: I haven't tested if the encoding did what it should Joined files : - HTMLyearbug.py: reproduces the bug - 2008cal.html: the output produced by this file ---------- components: Extension Modules files: cal.py messages: 55376 nosy: inefab severity: normal status: open title: HTMLCalendar.formatyearpage not behaving as documented type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cal.py Type: text/x-python Size: 557 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/8de7785e/attachment-0001.py From report at bugs.python.org Tue Aug 28 18:07:43 2007 From: report at bugs.python.org (inefab) Date: Tue, 28 Aug 2007 16:07:43 -0000 Subject: [issue1046] HTMLCalendar.formatyearpage not behaving as documented Message-ID: <1188317263.76.0.400108457817.issue1046@psf.upfronthosting.co.za> inefab added the comment: uploaded 2008cal.html __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2008cal.html Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/9d94dc4a/attachment-0001.txt From report at bugs.python.org Tue Aug 28 18:38:51 2007 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Tue, 28 Aug 2007 16:38:51 -0000 Subject: [issue1046] HTMLCalendar.formatyearpage not behaving as documented Message-ID: <1188319131.0.0.640384589964.issue1046@psf.upfronthosting.co.za> Walter D?rwald added the comment: Fixed in r57620 ---------- nosy: +doerwalter resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Aug 28 19:57:22 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 Aug 2007 17:57:22 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1188323842.07.0.368638234616.issue1779871@psf.upfronthosting.co.za> Ronald Oussoren added the comment: jyasskin: could you test apple_gcc_flags.diff? That's a version of your patch where configure tests if GCC supports -Wno-long-double and -no- cpp-precomp. NOTE: the patch doesn't update configure, you'll have to run autoconf after applying it. NOTE2: the patch is relative to python's trunk, but should apply to 2.5.x as well. ---------- resolution: -> accepted _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: apple_gcc_flags.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/bbaf6f10/attachment.txt From report at bugs.python.org Tue Aug 28 20:03:11 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 Aug 2007 18:03:11 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1188324191.76.0.332553912784.issue1779871@psf.upfronthosting.co.za> Changes by Ronald Oussoren: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 20:03:25 2007 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 Aug 2007 18:03:25 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1188324205.86.0.611753003133.issue1779871@psf.upfronthosting.co.za> Changes by Ronald Oussoren: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 20:04:54 2007 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 28 Aug 2007 18:04:54 -0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1188324294.37.0.914265191687.issue1779871@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I'm not going to get to this for about a week, but I'll test the patch then. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 20:33:46 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 28 Aug 2007 18:33:46 -0000 Subject: [issue1778376] Segfault closing a file from concurrent threads Message-ID: <1188326026.01.0.0427386682258.issue1778376@psf.upfronthosting.co.za> Georg Brandl added the comment: Actually, this is a dupe of #815646. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> thread unsafe file objects cause crash _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 20:34:36 2007 From: report at bugs.python.org (Georg Brandl) Date: Tue, 28 Aug 2007 18:34:36 -0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1188326076.13.0.731651522285.issue815646@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- priority: normal -> urgent severity: normal -> major type: -> crash ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Aug 28 23:20:14 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 21:20:14 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1188336014.87.0.609690741652.issue1598083@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I don't suppose you could wrangle up a proposed patch to fix this? ---------- nosy: +jafo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 23:26:18 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 28 Aug 2007 21:26:18 -0000 Subject: [issue837234] Tk.quit and sys.exit cause Fatal Error Message-ID: <1188336378.32.0.908730722539.issue837234@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Is this a bug or just incorrect usage? From reading the message it sounds like it may just have been an incorrect usage. If it's a bug, can we get a sample that reproduces the problem? ---------- nosy: +jafo ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Aug 28 23:54:50 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 Aug 2007 21:54:50 -0000 Subject: [issue1202533] a bunch of infinite C recursions Message-ID: <1188338090.36.0.135345402995.issue1202533@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- keywords: +patch priority: normal -> high severity: normal -> major type: -> crash versions: +Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Aug 28 23:55:15 2007 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 Aug 2007 21:55:15 -0000 Subject: [issue1202533] a bunch of infinite C recursions Message-ID: <1188338115.51.0.941931782739.issue1202533@psf.upfronthosting.co.za> Changes by Brett Cannon: ---------- priority: high -> urgent _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Aug 29 00:33:09 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 22:33:09 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1188340389.55.0.548105159725.issue1047@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: I join three patches for py3k on Windows: 1/ getargs.diff adds the 'Z' and 'Z#' format specifiers for PyArg_ParseTuple. They mimic z and z# for unicode strings, by accepting a Unicode or None (in which case the Py_UNICODE* pointer is set to NULL). With doc and tests. 2/ subprocess.diff converts file PC/_subprocess.c to unicode. We use the Unicode version of the win32 api (and Z conversion from previous patch) 3/ stdout.diff: sys.stdout must not convert the line endings, Windows already does it. Without this patch, when redirecting the output of python, the file contains \r\r\n for each line. (test_subprocess did catch this) ---------- components: Interpreter Core, Windows files: getargs.diff messages: 55384 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: corrections for test_subprocess on windows versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: getargs.diff Type: application/octet-stream Size: 4318 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/1700cced/attachment-0001.obj From report at bugs.python.org Wed Aug 29 00:33:09 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 22:33:09 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1188340389.55.0.548105159725.issue1047@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: I join three patches for py3k on Windows: 1/ getargs.diff adds the 'Z' and 'Z#' format specifiers for PyArg_ParseTuple. They mimic z and z# for unicode strings, by accepting a Unicode or None (in which case the Py_UNICODE* pointer is set to NULL). With doc and tests. 2/ subprocess.diff converts file PC/_subprocess.c to unicode. We use the Unicode version of the win32 api (and Z conversion from previous patch) 3/ stdout.diff: sys.stdout must not convert the line endings, Windows already does it. Without this patch, when redirecting the output of python, the file contains \r\r\n for each line. (test_subprocess did catch this) ---------- components: Interpreter Core, Windows files: getargs.diff messages: 55384 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: corrections for test_subprocess on windows versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: getargs.diff Type: application/octet-stream Size: 4318 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/1700cced/attachment-0002.obj From report at bugs.python.org Wed Aug 29 00:34:11 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 22:34:11 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1188340451.02.0.820550439182.issue1047@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Did I say that test_subprocess now passes on windows? __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: subprocess.diff Type: application/octet-stream Size: 4456 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/9c755268/attachment.obj From report at bugs.python.org Wed Aug 29 00:34:52 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 22:34:52 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1188340492.43.0.743285569979.issue1047@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 00:38:16 2007 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 28 Aug 2007 22:38:16 -0000 Subject: [issue813986] robotparser interactively prompts for username and password Message-ID: <1188340696.18.0.555440137743.issue813986@psf.upfronthosting.co.za> Skip Montanaro added the comment: I'll take this one. Looks like an easy fix. ---------- assignee: loewis -> skip.montanaro nosy: +skip.montanaro priority: high -> normal type: -> behavior ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 01:27:18 2007 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 28 Aug 2007 23:27:18 -0000 Subject: [issue813986] robotparser interactively prompts for username and password Message-ID: <1188343638.77.0.792750020478.issue813986@psf.upfronthosting.co.za> Skip Montanaro added the comment: Checked in as r57626 on trunk and r57627 on 2.5. ---------- resolution: -> accepted status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 01:28:26 2007 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 28 Aug 2007 23:28:26 -0000 Subject: [issue813986] robotparser interactively prompts for username and password Message-ID: <1188343706.23.0.262309756166.issue813986@psf.upfronthosting.co.za> Skip Montanaro added the comment: For those monitoring this, note that I am no unittest whiz, especially with oddball test files like test_robotparser.py. Please feel free to rewrite that code. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 01:29:48 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 23:29:48 -0000 Subject: [issue1048] py3k: correction for test_float on Windows Message-ID: <1188343788.48.0.865747020485.issue1048@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: test_float crashes on Windows, because the %zd format is used in a call to PyOS_snprintf(). The attached patch properly uses PY_FORMAT_SIZE_T. ---------- components: Windows files: formatter.diff messages: 55389 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: correction for test_float on Windows type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: formatter.diff Type: application/octet-stream Size: 670 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/ceebf901/attachment-0001.obj From report at bugs.python.org Wed Aug 29 01:29:48 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 28 Aug 2007 23:29:48 -0000 Subject: [issue1048] py3k: correction for test_float on Windows Message-ID: <1188343788.48.0.865747020485.issue1048@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: test_float crashes on Windows, because the %zd format is used in a call to PyOS_snprintf(). The attached patch properly uses PY_FORMAT_SIZE_T. ---------- components: Windows files: formatter.diff messages: 55389 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: correction for test_float on Windows type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: formatter.diff Type: application/octet-stream Size: 670 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070828/ceebf901/attachment-0002.obj From report at bugs.python.org Wed Aug 29 01:46:32 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 28 Aug 2007 23:46:32 -0000 Subject: [issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows behavior Message-ID: <1188344792.32.0.918453115921.issue1049@psf.upfronthosting.co.za> New submission from Bill Janssen: The behavior and return value for calling socket.socket.getsockname() on an unconnected unbound socket is unspecified. On UNIX, it returns an address ('0.0.0.0', 0), while on Windows it raises an obscure exception "error: (10022, 'Invalid argument')". This should be regularized; I'd suggest returning None if there is no name (address) for the socket. ---------- components: Library (Lib) messages: 55390 nosy: janssen priority: normal severity: normal status: open title: socket.socket.getsockname() has inconsistent UNIX/Windows behavior type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 01:46:32 2007 From: report at bugs.python.org (Bill Janssen) Date: Tue, 28 Aug 2007 23:46:32 -0000 Subject: [issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows behavior Message-ID: <1188344792.32.0.918453115921.issue1049@psf.upfronthosting.co.za> New submission from Bill Janssen: The behavior and return value for calling socket.socket.getsockname() on an unconnected unbound socket is unspecified. On UNIX, it returns an address ('0.0.0.0', 0), while on Windows it raises an obscure exception "error: (10022, 'Invalid argument')". This should be regularized; I'd suggest returning None if there is no name (address) for the socket. ---------- components: Library (Lib) messages: 55390 nosy: janssen priority: normal severity: normal status: open title: socket.socket.getsockname() has inconsistent UNIX/Windows behavior type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 02:05:54 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 Aug 2007 00:05:54 -0000 Subject: [issue1050] py3k: correction for test_marshal on Windows Message-ID: <1188345954.11.0.861533701797.issue1050@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: On Windows, debug builds insert stack probes, and recursive functions tend to exhaust the stack faster. This patch reduces the marshal maximum depth from 2000 to 1500 for debug builds only. Optimized builds are not affected. ---------- components: Windows files: marshall.diff messages: 55391 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: correction for test_marshal on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: marshall.diff Type: application/octet-stream Size: 1315 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070829/9a81d0e3/attachment.obj From report at bugs.python.org Wed Aug 29 02:05:54 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 Aug 2007 00:05:54 -0000 Subject: [issue1050] py3k: correction for test_marshal on Windows Message-ID: <1188345954.11.0.861533701797.issue1050@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: On Windows, debug builds insert stack probes, and recursive functions tend to exhaust the stack faster. This patch reduces the marshal maximum depth from 2000 to 1500 for debug builds only. Optimized builds are not affected. ---------- components: Windows files: marshall.diff messages: 55391 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: correction for test_marshal on Windows versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: marshall.diff Type: application/octet-stream Size: 1315 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070829/9a81d0e3/attachment-0001.obj From report at bugs.python.org Wed Aug 29 02:06:42 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 Aug 2007 00:06:42 -0000 Subject: [issue1050] py3k: correction for test_marshal on Windows Message-ID: <1188346002.0.0.199911576039.issue1050@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I forgot to say that this allows test_marshal to pass with debug builds. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 02:39:36 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 00:39:36 -0000 Subject: [issue1051] certificate in Lib/test/test_ssl.py expires in February 2013 Message-ID: <1188347976.5.0.452651938293.issue1051@psf.upfronthosting.co.za> New submission from Bill Janssen: Just a note that the certificate in Lib/test/test_ssl.py will expire in February of 2013 and have to be re-made. ---------- components: Tests messages: 55393 nosy: janssen priority: low severity: minor status: open title: certificate in Lib/test/test_ssl.py expires in February 2013 type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 02:39:36 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 00:39:36 -0000 Subject: [issue1051] certificate in Lib/test/test_ssl.py expires in February 2013 Message-ID: <1188347976.5.0.452651938293.issue1051@psf.upfronthosting.co.za> New submission from Bill Janssen: Just a note that the certificate in Lib/test/test_ssl.py will expire in February of 2013 and have to be re-made. ---------- components: Tests messages: 55393 nosy: janssen priority: low severity: minor status: open title: certificate in Lib/test/test_ssl.py expires in February 2013 type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 02:58:19 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 00:58:19 -0000 Subject: [issue527668] pydoc should respect __all__ Message-ID: <1188349099.29.0.874713688278.issue527668@psf.upfronthosting.co.za> Skip Montanaro added the comment: This was fixed in r36142 (i.e., ages ago). ---------- nosy: +skip.montanaro resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:04:27 2007 From: report at bugs.python.org (billiejoex) Date: Wed, 29 Aug 2007 01:04:27 -0000 Subject: [issue1053] bogus attributes reported in asyncore doc Message-ID: <1188349467.74.0.122599631068.issue1053@psf.upfronthosting.co.za> New submission from billiejoex: http://docs.python.org/lib/module-asyncore.html asyncore documentation erroneously report "ac_in_buffer_size" and "ac_out_buffer_size" attributes which does not exist in asyncore.dispatcher class. They're used in asynchat.async_chat class, instead. Moreover, asynchat documentation does not mention them. ---------- components: Documentation messages: 55396 nosy: billiejoex, josiahcarlson severity: normal status: open title: bogus attributes reported in asyncore doc versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 03:04:27 2007 From: report at bugs.python.org (billiejoex) Date: Wed, 29 Aug 2007 01:04:27 -0000 Subject: [issue1053] bogus attributes reported in asyncore doc Message-ID: <1188349467.74.0.122599631068.issue1053@psf.upfronthosting.co.za> New submission from billiejoex: http://docs.python.org/lib/module-asyncore.html asyncore documentation erroneously report "ac_in_buffer_size" and "ac_out_buffer_size" attributes which does not exist in asyncore.dispatcher class. They're used in asynchat.async_chat class, instead. Moreover, asynchat documentation does not mention them. ---------- components: Documentation messages: 55396 nosy: billiejoex, josiahcarlson severity: normal status: open title: bogus attributes reported in asyncore doc versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 03:05:12 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:05:12 -0000 Subject: [issue602893] cgitb tracebacks not accessible Message-ID: <1188349512.46.0.0573674130703.issue602893@psf.upfronthosting.co.za> Skip Montanaro added the comment: I have no easy way to check if this change works. Can you apply it to your Python installation and give it a whirl? Thx, Skip ---------- assignee: -> skip.montanaro nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cgitb.diff Type: text/x-diff Size: 1191 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070829/fc19a9c9/attachment.diff From report at bugs.python.org Wed Aug 29 03:23:22 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:23:22 -0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir Message-ID: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> New submission from Skip Montanaro: I tried running make scriptsinstall from my build directory. It failed with this error message: error: file 'byteyears.py' does not exist I added os.path.abspath() around the source file name in the error message. It's looking for byteyears.py in the current directory. From where I executed make it's in ../Tools/scripts. I'm not sure it would work if executed from the top-level source directory either. ---------- components: Build messages: 55398 nosy: skip.montanaro priority: normal severity: normal status: open title: scriptsinstall target fails in alternate build dir type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 03:23:22 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:23:22 -0000 Subject: [issue1054] scriptsinstall target fails in alternate build dir Message-ID: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za> New submission from Skip Montanaro: I tried running make scriptsinstall from my build directory. It failed with this error message: error: file 'byteyears.py' does not exist I added os.path.abspath() around the source file name in the error message. It's looking for byteyears.py in the current directory. From where I executed make it's in ../Tools/scripts. I'm not sure it would work if executed from the top-level source directory either. ---------- components: Build messages: 55398 nosy: skip.montanaro priority: normal severity: normal status: open title: scriptsinstall target fails in alternate build dir type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 03:27:54 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:27:54 -0000 Subject: [issue642309] pygettext should be installed Message-ID: <1188350874.28.0.20888735026.issue642309@psf.upfronthosting.co.za> Skip Montanaro added the comment: I checked in a change to Tools/scripts/setup.py to install ../i18n/pygettext.py. The main scriptsinstall makefile target still needs work though (opened a ticket about that). ---------- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:35:54 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:35:54 -0000 Subject: [issue658407] email: minimal header encoding Message-ID: <1188351354.5.0.436760373809.issue658407@psf.upfronthosting.co.za> Skip Montanaro added the comment: Marked as out-of-date. Might as well close it. ---------- nosy: +skip.montanaro status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:36:32 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:36:32 -0000 Subject: [issue683910] zipfile should have a tarfile-like API Message-ID: <1188351392.8.0.267973310283.issue683910@psf.upfronthosting.co.za> Skip Montanaro added the comment: Anthony, has this been fixed? ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:43:17 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:43:17 -0000 Subject: [issue444582] Finding programs in PATH, addition to os Message-ID: <1188351797.37.0.610382855365.issue444582@psf.upfronthosting.co.za> Skip Montanaro added the comment: Commenting on Brett's reply... We use this sort of facility in SpamBayes to search for the OCR program. I crafted something by hand which didn't work on Windows. Mark Hammond had to clean up the mess I made. Having this as a canned function in os would be handy. Have a look at find_program in this file: http://spambayes.svn.sourceforge.net/viewvc/*checkout*/spambayes/trunk/spambayes/spambayes/ImageStripper.py?content-type=text%2Fplain ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:45:29 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:45:29 -0000 Subject: [issue751260] Thread in threading.py can only be started once Message-ID: <1188351929.26.0.623281418018.issue751260@psf.upfronthosting.co.za> Skip Montanaro added the comment: Closing as won't fix. Python's threads work as designed. There are plenty of solutions available to get the desired behavior. ---------- nosy: +skip.montanaro resolution: -> wont fix ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:47:35 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:47:35 -0000 Subject: [issue766910] fix one or two bugs in trace.py Message-ID: <1188352055.61.0.902775161564.issue766910@psf.upfronthosting.co.za> Skip Montanaro added the comment: Zooko, is this patch still necessary? ---------- assignee: -> skip.montanaro nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:50:58 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:50:58 -0000 Subject: [issue756576] Recursion limit too high for MacOSX Message-ID: <1188352258.42.0.628870480965.issue756576@psf.upfronthosting.co.za> Skip Montanaro added the comment: This problem seems to have been fixed. The submitted test case yields maximum recursion depth exceeded on both 2.5 and 2.6a0. ---------- nosy: +skip.montanaro resolution: -> out of date ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:52:09 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:52:09 -0000 Subject: [issue761863] readline module that checks signals Message-ID: <1188352329.09.0.42957440548.issue761863@psf.upfronthosting.co.za> Skip Montanaro added the comment: kdart - do you have any response to Guido's question? ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:54:40 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:54:40 -0000 Subject: [issue815753] SCO_SV: many modules cannot be imported Message-ID: <1188352480.6.0.307809511387.issue815753@psf.upfronthosting.co.za> Skip Montanaro added the comment: No activity since late 2003. Do we even have a SCO system to test anything on? Should SCO support be dropped? ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 03:57:38 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 01:57:38 -0000 Subject: [issue849662] reading shelves is really slow Message-ID: <1188352658.58.0.259983851038.issue849662@psf.upfronthosting.co.za> Skip Montanaro added the comment: Raymond - can we close this ticket? ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 04:00:03 2007 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 Aug 2007 02:00:03 -0000 Subject: [issue877124] configure links unnecessary library libdl Message-ID: <1188352803.8.0.590738504192.issue877124@psf.upfronthosting.co.za> Skip Montanaro added the comment: Martin, can I close this? ---------- nosy: +skip.montanaro resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 04:38:17 2007 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 29 Aug 2007 02:38:17 -0000 Subject: [issue1598083] Top-level exception handler writes to stdout unsafely Message-ID: <1188355097.46.0.619097270231.issue1598083@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: Not likely, given the number of things on my plate already. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Aug 29 05:09:59 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 29 Aug 2007 03:09:59 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1188356999.65.0.989907115136.issue1001@psf.upfronthosting.co.za> Changes by Sean Reifschneider: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 05:26:58 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 29 Aug 2007 03:26:58 -0000 Subject: [issue889544] win32 raw socket support Message-ID: <1188358018.5.0.73688936524.issue889544@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Removed the "works for me" resolution because I think the poster accidentally selected this. No patch was attached, and the referenced URL for the information is gone now. Can the original submitter attach a patch for this. Once we have the patch I'm thinking about assigning to mhammond because Mark recently touched some of the Windows sections of the socket module. ---------- assignee: -> mhammond nosy: +jafo resolution: works for me -> ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 07:13:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 05:13:57 -0000 Subject: [issue837234] Tk.quit and sys.exit cause Fatal Error Message-ID: <1188364437.74.0.585958683079.issue837234@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It should not be possible to trigger Py_FatalError through pure Python code. I still haven't tried reproducing the problem, but if it is reproducable, it's a bug. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 07:24:55 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 05:24:55 -0000 Subject: [issue877124] configure links unnecessary library libdl Message-ID: <1188365095.69.0.164384757326.issue877124@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Yes, nobody seems to be interested in fixing it. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 08:14:30 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 29 Aug 2007 06:14:30 -0000 Subject: [issue837234] Tk.quit and sys.exit cause Fatal Error Message-ID: <1188368070.01.0.690515793421.issue837234@psf.upfronthosting.co.za> Sean Reifschneider added the comment: blaforge: I know it's been years, but can you provide code that reproduces this? I'm going to switch it to "pending" state, please re-open when you include some code to reproduce it. ---------- status: open -> pending ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Aug 29 08:15:24 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 06:15:24 -0000 Subject: [issue1535659] NNTPS support in nntplib Message-ID: <1188368124.35.0.391529229227.issue1535659@psf.upfronthosting.co.za> Bill Janssen added the comment: I'll take a look at this. ---------- assignee: -> janssen nosy: +janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Aug 29 10:43:50 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 08:43:50 -0000 Subject: [issue1055] argument parsing in datetime_strptime Message-ID: <1188377030.9.0.393410939189.issue1055@psf.upfronthosting.co.za> New submission from Martin v. L?wis: In r57374, the ParseTuple string for datetime_strptime was changed from ss:datetime to uu:datetime, without adjusting the output arguments. It's not clear to me what the rationale of this change was; it is incorrect as u outputs Py_UNICODE, not char. ---------- assignee: gvanrossum messages: 55417 nosy: loewis severity: normal status: open title: argument parsing in datetime_strptime versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 10:43:51 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 08:43:51 -0000 Subject: [issue1055] argument parsing in datetime_strptime Message-ID: <1188377030.9.0.393410939189.issue1055@psf.upfronthosting.co.za> New submission from Martin v. L?wis: In r57374, the ParseTuple string for datetime_strptime was changed from ss:datetime to uu:datetime, without adjusting the output arguments. It's not clear to me what the rationale of this change was; it is incorrect as u outputs Py_UNICODE, not char. ---------- assignee: gvanrossum messages: 55417 nosy: loewis severity: normal status: open title: argument parsing in datetime_strptime versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 10:44:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 08:44:25 -0000 Subject: [issue1055] argument parsing in datetime_strptime Message-ID: <1188377065.01.0.0444686738484.issue1055@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 10:44:57 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 08:44:57 -0000 Subject: [issue1055] argument parsing in datetime_strptime Message-ID: <1188377097.28.0.413869349777.issue1055@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- nosy: -gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 15:12:48 2007 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 29 Aug 2007 13:12:48 -0000 Subject: [issue1056] test_cmd_line starts python without -E Message-ID: <1188393168.01.0.0728508548094.issue1056@psf.upfronthosting.co.za> New submission from Thomas Wouters: test_cmd_line tests various things by spawning sys.executable. Unfortunately it does so without passing the -E argument (which 'make test' does do) so environment variables like PYTHONHOME and PYTHONPATH can cause the test to fail. ---------- assignee: ncoghlan components: Tests messages: 55418 nosy: twouters priority: high severity: normal status: open title: test_cmd_line starts python without -E type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 15:12:48 2007 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 29 Aug 2007 13:12:48 -0000 Subject: [issue1056] test_cmd_line starts python without -E Message-ID: <1188393168.01.0.0728508548094.issue1056@psf.upfronthosting.co.za> New submission from Thomas Wouters: test_cmd_line tests various things by spawning sys.executable. Unfortunately it does so without passing the -E argument (which 'make test' does do) so environment variables like PYTHONHOME and PYTHONPATH can cause the test to fail. ---------- assignee: ncoghlan components: Tests messages: 55418 nosy: twouters priority: high severity: normal status: open title: test_cmd_line starts python without -E type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 15:43:44 2007 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 29 Aug 2007 13:43:44 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188395024.87.0.139236827123.issue1617699@psf.upfronthosting.co.za> Thomas Wouters added the comment: Added tests (by duplicating any slicing operations in the test suite with extended slice syntax, to force the use of slice-objects ;) _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: noslice.ctypes.diff Type: text/x-patch Size: 17570 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070829/c4fe4f31/attachment-0001.bin From report at bugs.python.org Wed Aug 29 15:43:51 2007 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 29 Aug 2007 13:43:51 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188395031.91.0.853782271719.issue1617699@psf.upfronthosting.co.za> Changes by Thomas Wouters: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Aug 29 16:01:13 2007 From: report at bugs.python.org (Huang Peng) Date: Wed, 29 Aug 2007 14:01:13 -0000 Subject: [issue708374] add offset to mmap Message-ID: <1188396073.79.0.769873795128.issue708374@psf.upfronthosting.co.za> Huang Peng added the comment: I updated the patch for trunk (r57652). In this patch, find, move and flush methods use offset in mmap buffer instead of offset in file. It also fix a bug in test_mmap.py and modified mmap document. Please review it. ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.diff Type: application/octet-stream Size: 11703 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070829/fc4c648e/attachment.obj From report at bugs.python.org Wed Aug 29 17:02:11 2007 From: report at bugs.python.org (Aaron Bingham) Date: Wed, 29 Aug 2007 15:02:11 -0000 Subject: [issue1057] Incorrect URL with webbrowser and firefox under Gnome Message-ID: <1188399731.78.0.486127314397.issue1057@psf.upfronthosting.co.za> New submission from Aaron Bingham: Under Gnome, Firefox will open the wrong URL when launched by webbrowser. For example after running the following interactive session: bingham at grizzly:~> python Python 2.5.1 (r251:54863, Jun 6 2007, 13:42:30) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import webbrowser >>> webbrowser.open('http://www.python.org') True Firefox attempts to open the URL file:///home/bingham/%22http://www.python.org%22. This is caused by a bug in the Python standard library's webbrowser module that only affects machines running Gnome. On Gnome, webbrowser runs the command gconftool-2 -g /desktop/gnome/url-handlers/http/command 2>/dev/null to find the web browser, which prints out a browser command line like /pkgs/Firefox/2.0/firefox "%s" The quotes around "%s" are preserved when passing the command-line arguments. The quotes prevent firefox from recognizing the URL and firefox falls back to treating it as a file name. The webbrowser module already handles extra quoting around the URL for the BROWSER environment variable and this same treatment should be applied to the result of gconftool-2. The BROWSER environment variable issue, now fixed, is described at http://bugs.python.org/issue1684254. The present issue was discussed in an Ubuntu bug report (https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/83974) but was not resolved. ---------- components: Library (Lib) messages: 55421 nosy: bingham severity: normal status: open title: Incorrect URL with webbrowser and firefox under Gnome type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 17:02:11 2007 From: report at bugs.python.org (Aaron Bingham) Date: Wed, 29 Aug 2007 15:02:11 -0000 Subject: [issue1057] Incorrect URL with webbrowser and firefox under Gnome Message-ID: <1188399731.78.0.486127314397.issue1057@psf.upfronthosting.co.za> New submission from Aaron Bingham: Under Gnome, Firefox will open the wrong URL when launched by webbrowser. For example after running the following interactive session: bingham at grizzly:~> python Python 2.5.1 (r251:54863, Jun 6 2007, 13:42:30) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import webbrowser >>> webbrowser.open('http://www.python.org') True Firefox attempts to open the URL file:///home/bingham/%22http://www.python.org%22. This is caused by a bug in the Python standard library's webbrowser module that only affects machines running Gnome. On Gnome, webbrowser runs the command gconftool-2 -g /desktop/gnome/url-handlers/http/command 2>/dev/null to find the web browser, which prints out a browser command line like /pkgs/Firefox/2.0/firefox "%s" The quotes around "%s" are preserved when passing the command-line arguments. The quotes prevent firefox from recognizing the URL and firefox falls back to treating it as a file name. The webbrowser module already handles extra quoting around the URL for the BROWSER environment variable and this same treatment should be applied to the result of gconftool-2. The BROWSER environment variable issue, now fixed, is described at http://bugs.python.org/issue1684254. The present issue was discussed in an Ubuntu bug report (https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/83974) but was not resolved. ---------- components: Library (Lib) messages: 55421 nosy: bingham severity: normal status: open title: Incorrect URL with webbrowser and firefox under Gnome type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 17:31:52 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 29 Aug 2007 15:31:52 -0000 Subject: [issue1057] Incorrect URL with webbrowser and firefox under Gnome Message-ID: <1188401512.06.0.25059204089.issue1057@psf.upfronthosting.co.za> Georg Brandl added the comment: The current code in the 2.5 branch uses shlex.split to postprocess the command line returned by gconftool too, so this should be already fixed. ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 17:43:56 2007 From: report at bugs.python.org (Kenneth Love) Date: Wed, 29 Aug 2007 15:43:56 -0000 Subject: [issue1058] Code Example for 'property' bug Message-ID: <1188402236.38.0.727151700445.issue1058@psf.upfronthosting.co.za> New submission from Kenneth Love: The code example for 'property' in the online documentation appears to have several syntax errors. In the class C, the functions getx, setx, and delx all refer to '_x', but __init__ assigns '__x'. In other words, single underscores were used where double underscores were intended (or vice versa?). NOTE: I was unsure what "Type" of issue this was based on the provided list. I chose "compile error" because it seemed to be the best fit. ---------- components: Documentation messages: 55423 nosy: KennethLove severity: minor status: open title: Code Example for 'property' bug type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 17:43:56 2007 From: report at bugs.python.org (Kenneth Love) Date: Wed, 29 Aug 2007 15:43:56 -0000 Subject: [issue1058] Code Example for 'property' bug Message-ID: <1188402236.38.0.727151700445.issue1058@psf.upfronthosting.co.za> New submission from Kenneth Love: The code example for 'property' in the online documentation appears to have several syntax errors. In the class C, the functions getx, setx, and delx all refer to '_x', but __init__ assigns '__x'. In other words, single underscores were used where double underscores were intended (or vice versa?). NOTE: I was unsure what "Type" of issue this was based on the provided list. I chose "compile error" because it seemed to be the best fit. ---------- components: Documentation messages: 55423 nosy: KennethLove severity: minor status: open title: Code Example for 'property' bug type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 18:36:32 2007 From: report at bugs.python.org (Georg Brandl) Date: Wed, 29 Aug 2007 16:36:32 -0000 Subject: [issue1058] Code Example for 'property' bug In-Reply-To: <1188402236.38.0.727151700445.issue1058@psf.upfronthosting.co.za> Message-ID: <46D5A086.9010309@gmx.net> Georg Brandl added the comment: Kenneth Love schrieb: > New submission from Kenneth Love: > > The code example for 'property' in the online documentation appears to > have several syntax errors. > > In the class C, the functions getx, setx, and delx all refer to '_x', > but __init__ assigns '__x'. In other words, single underscores were > used where double underscores were intended (or vice versa?). This is already fixed in SVN and will be in the next released docs version. Thanks for reporting! ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 18:48:05 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 16:48:05 -0000 Subject: [issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows behavior Message-ID: <1188406085.37.0.787817946498.issue1049@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think it is neither possible nor "good" to produce a uniform result. Python traditionally exposes APIs "as-is", providing the system actually has an API with the same name. It never tries to hide differing system behaviors in the Python wrapper; if systems vary and it is desirable to provide a uniform API, a different API is added. However, it is also not possible to make that uniform, as getsockname(3) gives an unspecified result, so it is not possible for Python to actually determine whether there was a meaningful result. Closing as rejected. ---------- nosy: +loewis resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 18:49:28 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 16:49:28 -0000 Subject: [issue1055] argument parsing in datetime_strptime Message-ID: <1188406168.48.0.166857226696.issue1055@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 18:50:51 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 29 Aug 2007 16:50:51 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188406251.72.0.685652384967.issue1040@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 19:06:03 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 Aug 2007 17:06:03 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188407163.35.0.0194631076846.issue1040@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I have a patch for this, which uses MBCS conversion instead of relying on the default utf-8 (here and several other places). Tested on a French version of winXP. Which leads me to the question: should Windows use MBCS encoding by default when converting between char* and PyUnicode, and not utf-8? There are some other tracker items which would benefit from this. After all, C strings can only come from 1) python code, 2) system i/o and messages, and 3) constants in source code. IMO, 1) can use the representation it prefers, 2) would clearly lead to less error if handled as MBCS and 3) only uses 7bit ascii. There is very little need for utf-8 here. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 20:01:21 2007 From: report at bugs.python.org (Thomas Heller) Date: Wed, 29 Aug 2007 18:01:21 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188410481.58.0.614651387035.issue1040@psf.upfronthosting.co.za> Thomas Heller added the comment: IMO the very best would be to avoid as many conversions as possible by using the wide apis on Windows. Not for _tzname maybe, but for env vars, sys.argv, sys.path, and so on. Not that I would have time to work on that... __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 20:32:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 18:32:14 -0000 Subject: [issue1029] py3k: io.StringIO.getvalue() returns \r\n Message-ID: <1188412334.82.0.734671164565.issue1029@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'ev fixed this slightly differently, by simply changing the *default* of the newline argument to StringIO to be "\n". This is a good default; but I see no reason to prevent users from messing with it if they have a need. ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 20:39:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 18:39:08 -0000 Subject: [issue1047] py3k: corrections for test_subprocess on windows Message-ID: <1188412748.2.0.517353393314.issue1047@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 57669. I have no way to test this so you'll have to watch the buildbot. However, I didn't include the patch to _fileio.c that prevents closing fds 0, 1, 2; I think that's the wrong thing to do and if it causes problems it needs to be addressed in a different way. ---------- nosy: +gvanrossum resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 20:42:34 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 18:42:34 -0000 Subject: [issue1048] py3k: correction for test_float on Windows Message-ID: <1188412954.53.0.923214966763.issue1048@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 57670. You will have to watch the buildbots to see if this worked. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 20:45:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 18:45:08 -0000 Subject: [issue1050] py3k: correction for test_marshal on Windows Message-ID: <1188413108.62.0.391529867104.issue1050@psf.upfronthosting.co.za> Guido van Rossum added the comment: Committed revision 57672. You'll have to watch the buildbots. ---------- nosy: +gvanrossum resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 20:55:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 18:55:13 -0000 Subject: [issue1037] Ill-coded identifier crashes python when coding spec is utf-8 Message-ID: <1188413713.85.0.545926946152.issue1037@psf.upfronthosting.co.za> Guido van Rossum added the comment: r57674. I'm not sure this is the right fix though... ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:33:37 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:33:37 -0000 Subject: [issue1016] [PATCH] Updated fix for string to unicode fixes in time and datetime Message-ID: <1188419617.78.0.105455359496.issue1016@psf.upfronthosting.co.za> Guido van Rossum added the comment: The issue in datetimemodule.c was already fixed. The fix to timemodule.c is wrong -- when there are non-ASCII characters in the unicode string, the length of the UTF-8 conversion is not equal to that of the original Unicode string. ---------- nosy: +gvanrossum resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:33:59 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:33:59 -0000 Subject: [issue1009] Implementation of PEP 3101, Advanced String Formatting Message-ID: <1188419639.41.0.535178220451.issue1009@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:34:22 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 29 Aug 2007 20:34:22 -0000 Subject: [issue1059] *args and **kwargs in function definitions Message-ID: <1188419662.35.0.01051370867.issue1059@psf.upfronthosting.co.za> New submission from Lars Gust?bel: For example in tarfile.rst and logging.rst there are function definitions using *args and/or **kwargs like: .. function:: debug(msg[, *args[, **kwargs]]) The * and ** should be escaped IMO, so that they are not mistaken as reStructuredText markup, which confuses the syntax coloring of my Vim. While escaping * with a backslash works fine in normal text, it does not work in a function definition and the backslash appears in the HTML output. ---------- assignee: georg.brandl components: Documentation messages: 55434 nosy: lars.gustaebel priority: low severity: minor status: open title: *args and **kwargs in function definitions versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:34:22 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 29 Aug 2007 20:34:22 -0000 Subject: [issue1059] *args and **kwargs in function definitions Message-ID: <1188419662.35.0.01051370867.issue1059@psf.upfronthosting.co.za> New submission from Lars Gust?bel: For example in tarfile.rst and logging.rst there are function definitions using *args and/or **kwargs like: .. function:: debug(msg[, *args[, **kwargs]]) The * and ** should be escaped IMO, so that they are not mistaken as reStructuredText markup, which confuses the syntax coloring of my Vim. While escaping * with a backslash works fine in normal text, it does not work in a function definition and the backslash appears in the HTML output. ---------- assignee: georg.brandl components: Documentation messages: 55434 nosy: lars.gustaebel priority: low severity: minor status: open title: *args and **kwargs in function definitions versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:40:27 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:40:27 -0000 Subject: [issue1019] Cleanup pass on _curses and _curses_panel Message-ID: <1188420027.09.0.478012382219.issue1019@psf.upfronthosting.co.za> Guido van Rossum added the comment: I tried to run the various demos in Demo/curses/ with the new version. They all work except for xmas.py. Before your patch, they all ran. So I cannot apply this yet. (No time to look into it further, alas.) ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:42:04 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:42:04 -0000 Subject: [issue1022] use bytes for code objects Message-ID: <1188420124.82.0.450753721801.issue1022@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll defer thinking about this until post-a1. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:43:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:43:41 -0000 Subject: [issue1023] [PATCH] Unicode fixes in floatobject and moduleobject Message-ID: <1188420221.79.0.540087557888.issue1023@psf.upfronthosting.co.za> Guido van Rossum added the comment: Is this still relevant? The patch fails applying with quit a bit of fireworks: patching file moduleobject.c Hunk #1 FAILED at 66. Hunk #2 succeeded at 86 (offset -5 lines). Hunk #3 FAILED at 115. Hunk #4 FAILED at 128. 3 out of 4 hunks FAILED -- saving rejects to file moduleobject.c.rej patching file floatobject.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] n Skipping patch. 3 out of 3 hunks ignored -- saving rejects to file floatobject.c.rej ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:46:40 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:46:40 -0000 Subject: [issue1038] [py3k] pdb does not work in python 3000 Message-ID: <1188420400.25.0.842498658041.issue1038@psf.upfronthosting.co.za> Guido van Rossum added the comment: Why are you using _runscript(), which is an internal routine? I've had a fair amount of success with other invocations, like pdb.run(). ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:47:30 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:47:30 -0000 Subject: [issue1039] Asssertion in Windows debug build Message-ID: <1188420450.71.0.637726363357.issue1039@psf.upfronthosting.co.za> Guido van Rossum added the comment: If it works for you, can you submit it? ---------- assignee: -> theller nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:48:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:48:05 -0000 Subject: [issue1041] io.py problems on Windows Message-ID: <1188420485.59.0.0321783139812.issue1041@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm guessing this is fixed now that that patch is submitted. ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 22:52:13 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 20:52:13 -0000 Subject: [issue1055] argument parsing in datetime_strptime Message-ID: <1188420733.74.0.763344134779.issue1055@psf.upfronthosting.co.za> Guido van Rossum added the comment: Should be fixed by r57665. I'm guessing we went a little too fast with this change. ---------- nosy: +gvanrossum resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 23:26:28 2007 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 29 Aug 2007 21:26:28 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188422788.97.0.84131387766.issue1617699@psf.upfronthosting.co.za> Thomas Wouters added the comment: Implemented actual extended slicing support for the Array and Pointer types. The semantics of negative and ommitted indices in the Pointer case are somewhat muddy, but I took the approach the simple slicing code took: pretend the programmer knows what they're doing, and that the 'sequence' that is the pointer is actually PY_SSIZE_T_MAX elements long. I'm not sure I like that approach at all, but the actual problem is the unbounded nature of the pointers, and this is the only approach I can think of that makes sense, short of completely disallowing negative or missing indices. This patch is pretty much done now, I think. Note that it's entirely backward compatible, the incompatible bits (removing simple slicing) happen in Py3K. _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: noslice.ctypes.diff Type: application/octet-stream Size: 21952 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070829/ecf618fe/attachment-0001.obj From report at bugs.python.org Wed Aug 29 23:26:37 2007 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 29 Aug 2007 21:26:37 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188422797.38.0.0936967587355.issue1617699@psf.upfronthosting.co.za> Changes by Thomas Wouters: _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Aug 29 23:28:10 2007 From: report at bugs.python.org (Ero Carrera) Date: Wed, 29 Aug 2007 21:28:10 -0000 Subject: [issue1023] [PATCH] Unicode fixes in floatobject and moduleobject Message-ID: <1188422890.82.0.00907777515429.issue1023@psf.upfronthosting.co.za> Ero Carrera added the comment: Just took a look. Seems it was fixed in some other patch hence the fireworks __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 23:31:07 2007 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Aug 2007 21:31:07 -0000 Subject: [issue1023] [PATCH] Unicode fixes in floatobject and moduleobject Message-ID: <1188423067.3.0.5776958615.issue1023@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 23:34:55 2007 From: report at bugs.python.org (Kevin Ar18) Date: Wed, 29 Aug 2007 21:34:55 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188423295.47.0.201015368946.issue1060@psf.upfronthosting.co.za> New submission from Kevin Ar18: Summary: If you have a zip file that contains a file inside of it greater than 2GB, then the zipfile module is unable to read that file. Steps to Reproduce: 1. Create a zip file several GB in size with a file inside of it that is over 2GB in size. 2. Attempt to read the large file inside the zip file. Here's some sample code: import zipfile import re dataObj = zipfile.ZipFile("zip.zip","r") for i in dataObj.namelist(): if(i[-1] == "/"): print "dir" else: fileName = re.split(r".*/",i,0)[1] fileData = dataObj.read(i) Result: Python returns the following error: File "...\zipfile.py", line 491, in read bytes = self.fp.read(zinfo.compress_size) OverflowError: long it too large to convert to int Expected Result: It should copy the data into the variable fileData... I'll try to post more info in a follow-up. ---------- components: Library (Lib) messages: 55444 nosy: Kevin Ar18 severity: normal status: open title: zipfile cannot handle files larger than 2GB (inside archive) type: compile error versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Aug 29 23:34:55 2007 From: report at bugs.python.org (Kevin Ar18) Date: Wed, 29 Aug 2007 21:34:55 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188423295.47.0.201015368946.issue1060@psf.upfronthosting.co.za> New submission from Kevin Ar18: Summary: If you have a zip file that contains a file inside of it greater than 2GB, then the zipfile module is unable to read that file. Steps to Reproduce: 1. Create a zip file several GB in size with a file inside of it that is over 2GB in size. 2. Attempt to read the large file inside the zip file. Here's some sample code: import zipfile import re dataObj = zipfile.ZipFile("zip.zip","r") for i in dataObj.namelist(): if(i[-1] == "/"): print "dir" else: fileName = re.split(r".*/",i,0)[1] fileData = dataObj.read(i) Result: Python returns the following error: File "...\zipfile.py", line 491, in read bytes = self.fp.read(zinfo.compress_size) OverflowError: long it too large to convert to int Expected Result: It should copy the data into the variable fileData... I'll try to post more info in a follow-up. ---------- components: Library (Lib) messages: 55444 nosy: Kevin Ar18 severity: normal status: open title: zipfile cannot handle files larger than 2GB (inside archive) type: compile error versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 00:49:11 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 22:49:11 -0000 Subject: [issue1052] SSL patch for Windows buildbots problem Message-ID: <1188427751.7.0.150385293998.issue1052@psf.upfronthosting.co.za> Bill Janssen added the comment: Checked in. ---------- assignee: nnorwitz -> janssen resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 00:54:31 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 22:54:31 -0000 Subject: [issue1583946] SSL "issuer" and "server" names cannot be parsed Message-ID: <1188428071.08.0.268447042051.issue1583946@psf.upfronthosting.co.za> Bill Janssen added the comment: Actually, looking at it further, I'm not sure that it is fixed by the new SSL code. If in fact the issuer or subject field can contain multiple name-value pairs with the same name, the dictionary-based approach currently used won't work. We'll need more of an alist approach, with name-value tuples in it. I'd better look into this. ---------- assignee: -> janssen _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 00:57:08 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 22:57:08 -0000 Subject: [issue783188] support for server side transactions in _ssl Message-ID: <1188428228.52.0.0677405035795.issue783188@psf.upfronthosting.co.za> Bill Janssen added the comment: I'll take on providing the server example. ---------- assignee: akuchling -> janssen ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 01:00:38 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 23:00:38 -0000 Subject: [issue889813] making the version of SSL configurable when creating sockets Message-ID: <1188428438.98.0.749369042101.issue889813@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed with 2.6 SSL support. ---------- resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 01:01:38 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 23:01:38 -0000 Subject: [issue1027394] socket.ssl should explain that it is a 2/3 connection Message-ID: <1188428498.84.0.589421122015.issue1027394@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed with the 2.6 SSL work. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 01:03:05 2007 From: report at bugs.python.org (Bill Janssen) Date: Wed, 29 Aug 2007 23:03:05 -0000 Subject: [issue1114345] Add SSL certificate validation Message-ID: <1188428585.38.0.236944268383.issue1114345@psf.upfronthosting.co.za> Bill Janssen added the comment: Fixed in 2.6. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:22:03 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:22:03 -0000 Subject: [issue1678077] improve telnetlib.Telnet so option negotiation becomes easie Message-ID: <1188433323.95.0.442206439675.issue1678077@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:22:14 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:22:14 -0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1188433334.69.0.922197681019.issue1683368@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:22:29 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:22:29 -0000 Subject: [issue1677872] Efficient reverse line iterator Message-ID: <1188433349.5.0.445359662952.issue1677872@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- title: Efficient reverse line iterator -> Efficient reverse line iterator versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:22:41 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:22:41 -0000 Subject: [issue1720390] Remove backslash escapes from tokenize.c. Message-ID: <1188433361.16.0.61111602655.issue1720390@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:22:52 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:22:52 -0000 Subject: [issue1752184] PyHeapTypeObject fix Message-ID: <1188433372.1.0.787868038917.issue1752184@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:23:01 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:23:01 -0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1188433381.02.0.880665380504.issue1762972@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:23:12 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:23:12 -0000 Subject: [issue1774369] Unify __builtins__ -> __builtin__ Message-ID: <1188433392.83.0.230045664409.issue1774369@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:23:36 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:23:36 -0000 Subject: [issue1771260] Errors in site.py not reported properly Message-ID: <1188433416.55.0.942664075385.issue1771260@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:23:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:23:45 -0000 Subject: [issue1753395] struni: assertion in Windows debug build Message-ID: <1188433425.08.0.343048018928.issue1753395@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:24:23 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 00:24:23 -0000 Subject: [issue1766304] improve xrange.__contains__ Message-ID: <1188433463.13.0.163797345002.issue1766304@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 02:59:20 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 30 Aug 2007 00:59:20 -0000 Subject: [issue1038] [py3k] pdb does not work in python 3000 Message-ID: <1188435560.94.0.584121730551.issue1038@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I was running it by typing "./python Lib/pdb.py Lib/test_foo.py" __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 04:14:06 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 30 Aug 2007 02:14:06 -0000 Subject: [issue504152] rfc822 long header continuation broken Message-ID: <1188440046.47.0.892867411534.issue504152@psf.upfronthosting.co.za> Skip Montanaro added the comment: Is this still an issue? No activity since 2003-11. ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 04:16:34 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 30 Aug 2007 02:16:34 -0000 Subject: [issue857888] Modules/Setup needs a suppress flag? Message-ID: <1188440194.61.0.529654011932.issue857888@psf.upfronthosting.co.za> Skip Montanaro added the comment: That's what the comment character is for. Closing since there's already a good way to achieve the desired behavior and because Modules/Setup is generally not the primary way to build extensions anymore. ---------- assignee: -> skip.montanaro nosy: +skip.montanaro resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 05:11:22 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 30 Aug 2007 03:11:22 -0000 Subject: [issue1035] bytes buffer API needs to support PyBUF_LOCKDATA Message-ID: <1188443482.98.0.785951916054.issue1035@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I sent an initial patch to the mailing list. Its too late to be ready for 3.0a1; I'll fix it up next week. ---------- assignee: -> gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 05:36:08 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 03:36:08 -0000 Subject: [issue504152] rfc822 long header continuation broken Message-ID: <1188444968.67.0.366339586526.issue504152@psf.upfronthosting.co.za> Guido van Rossum added the comment: How about this patch? It basically does self.dict[headerseen] += line.rstrip() which should be what the RFC prescribes, maintaining the invariant that the dict values don't end in whitespace. I haven't written a test for this behavior. ____________________________________ Tracker ____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: rfc822.diff Type: text/x-patch Size: 593 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/6e8af345/attachment-0001.bin From report at bugs.python.org Thu Aug 30 05:36:58 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 03:36:58 -0000 Subject: [issue504152] rfc822 long header continuation broken Message-ID: <1188445018.6.0.894670001873.issue504152@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 2.4, Python 2.5, Python 2.6, Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 06:22:06 2007 From: report at bugs.python.org (Senthil) Date: Thu, 30 Aug 2007 04:22:06 -0000 Subject: [issue1057] Incorrect URL with webbrowser and firefox under Gnome Message-ID: <1188447726.42.0.241011467883.issue1057@psf.upfronthosting.co.za> Senthil added the comment: I am on Fedora Core 3, gnome 2.6 and I am unable to reproduce this issue. Could this be a Ubuntu configuration bug. Like adding " quotes after %s for the firefox command? ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 06:23:04 2007 From: report at bugs.python.org (Senthil) Date: Thu, 30 Aug 2007 04:23:04 -0000 Subject: [issue1057] Incorrect URL with webbrowser and firefox under Gnome Message-ID: <1188447784.23.0.38613324134.issue1057@psf.upfronthosting.co.za> Senthil added the comment: Okay. I found the status later. It was fixed then with Python 2.6 which I am using. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 06:44:26 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 30 Aug 2007 04:44:26 -0000 Subject: [issue1189216] zipfile module and 2G boundary Message-ID: <1188449066.34.0.340772132715.issue1189216@psf.upfronthosting.co.za> Gregory P. Smith added the comment: i'll take care of this. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 06:48:04 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 30 Aug 2007 04:48:04 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188449284.83.0.433918130187.issue1060@psf.upfronthosting.co.za> Gregory P. Smith added the comment: i'll take care of it. any more info in the interim will be appreciated. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 06:51:24 2007 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 30 Aug 2007 04:51:24 -0000 Subject: [issue1003] zipfile password fails validation Message-ID: <1188449484.0.0.674634142127.issue1003@psf.upfronthosting.co.za> Gregory P. Smith added the comment: can you provide a test zip file demonstrating the problem? ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 08:54:19 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09vila-sf=0A=09=09=09=09?=) Date: Thu, 30 Aug 2007 06:54:19 -0000 Subject: [issue1114345] Add SSL certificate validation In-Reply-To: <1188428585.38.0.236944268383.issue1114345@psf.upfronthosting.co.za> (Bill Janssen's message of "Wed, 29 Aug 2007 23:03:05 -0000") Message-ID: vila-sf added the comment: >>>>> "Bill" == Bill Janssen writes: Bill> Bill Janssen added the comment: Bill> Fixed in 2.6. Bill> ---------- Bill> resolution: -> fixed Bill> status: open -> closed Thanks for the work on the server side ! But there is still one bit missing for the client side, the original patch allowed the handling of self-certified sites which, AIUI, you don't provide. Am I wrong ? Vincent _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 10:03:25 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 30 Aug 2007 08:03:25 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188461005.29.0.39932624847.issue1044@psf.upfronthosting.co.za> Lars Gust?bel added the comment: After careful consideration and a private discussion with Martin I do no longer think that we have a security issue here. tarfile.py does nothing wrong, its behaviour conforms to the pax definition and pathname resolution guidelines in POSIX. There is no known or possible practical exploit. I update the documentation with a warning, that it might be dangerous to extract archives from untrusted sources. That is the only thing to be done IMO. ---------- type: security -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 10:05:16 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 08:05:16 -0000 Subject: [issue1059] *args and **kwargs in function definitions In-Reply-To: <1188419662.35.0.01051370867.issue1059@psf.upfronthosting.co.za> Message-ID: <46D67A42.5040606@gmx.net> Georg Brandl added the comment: Lars Gust?bel schrieb: > For example in tarfile.rst and logging.rst there are function > definitions using *args and/or **kwargs like: > > .. function:: debug(msg[, *args[, **kwargs]]) > > The * and ** should be escaped IMO, so that they are not mistaken as > reStructuredText markup, which confuses the syntax coloring of my Vim. > While escaping * with a backslash works fine in normal text, it does not > work in a function definition and the backslash appears in the HTML output. This was done deliberately since for C function descriptions .. cfunction:: PyObject *Py_DoSomething(PyObject *obj1, ...) it's a PITA to escape all the stars. The reST highlighting of Vim seems to be insufficient not only in this regard (inline markup can't span paragraphs); may I convince you to use a real editor like Emacs? :) *ducks* Fine, fine, I'll see if I can add backslash processing there. But I won't add backslashes for all of the existing definitions. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 10:36:28 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 08:36:28 -0000 Subject: [issue1059] *args and **kwargs in function definitions In-Reply-To: <1188462709.59.0.0815423271441.issue1059@psf.upfronthosting.co.za> Message-ID: <46D68193.5080205@python.org> Georg Brandl added the comment: Lars Gust?bel schrieb: > Lars Gust?bel added the comment: > > Oh, I thought Emacs was an operating system, I didn't know you could > edit text files with it. You live and learn ;-) > > I suspected that this was intentional. If you make backslash escaping > optional, that's fine with me. Okay, fixed in rev. 57712. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 11:18:55 2007 From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09TH=0A=09=09=09=09?=) Date: Thu, 30 Aug 2007 09:18:55 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1188465535.82.0.14004109622.issue1686386@psf.upfronthosting.co.za> TH added the comment: Here is a patch correcting the problem, with tests. It doesn't have much to do with exception, it's mainly a problem with PyObject_Str and PyObject_Repr, that I corrected with Py_EnterRecursiveCall calls. Maybe the bug should be reclassified, at least the title changed. ---------- nosy: +therve type: -> crash _____________________________________ Tracker _____________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1686386.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/c83acc0f/attachment.txt From report at bugs.python.org Thu Aug 30 11:39:57 2007 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 30 Aug 2007 09:39:57 -0000 Subject: [issue1597011] Reading with bz2.BZ2File() returns one garbage character Message-ID: <1188466797.25.0.105862169352.issue1597011@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Found some problems in the previous version, this one passes the tests and I've also spent time reviewing the code and I think this is correct. Part of the problem is that only bzerror was being checked, not the number of bytes read. When bzerror is not BZ_OK, the code expects that it returns a byte that was read, but in some cases it returns an error when no bytes were read. This code passes the test and also correctly handles the bz2 file that is the object of this bug. _____________________________________ Tracker _____________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-trunk-bz2-v2.patch Type: text/x-patch Size: 2109 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/a9685f25/attachment-0001.bin From report at bugs.python.org Thu Aug 30 12:10:12 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 10:10:12 -0000 Subject: [issue1170311] zipfile UnicodeDecodeError Message-ID: <1188468612.42.0.0124782196486.issue1170311@psf.upfronthosting.co.za> Georg Brandl added the comment: The docs say (at least the development docs) that Unicode filenames must be encoded to str before passing them to ZipFile.write(). (This issue will have to be solved differently for Py3k, I'll look into it.) ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 12:14:40 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 10:14:40 -0000 Subject: [issue1193061] Python and Turkish Locale Message-ID: <1188468880.42.0.104832347448.issue1193061@psf.upfronthosting.co.za> Georg Brandl added the comment: Dupe of #1528802. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> Turkish Character _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 12:16:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 10:16:38 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188468998.53.0.0684035968286.issue1528802@psf.upfronthosting.co.za> Georg Brandl added the comment: If I'm not mistaken, "i".upper() will never be LATIN CAPITAL LETTER I WITH DOT ABOVE, regardless of the locale? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 12:22:30 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 10:22:30 -0000 Subject: [issue883466] quopri encoding & Unicode Message-ID: <1188469350.09.0.316742350765.issue883466@psf.upfronthosting.co.za> Georg Brandl added the comment: This is the same issue you can see with cStringIO.StringIO(u"abc").getvalue(). This behavior will not be changed, as per #1730114. Marc-Andre: would it be okay to add an explicit str() call in the StringIO calls in quopri_codec and uu_codec, so that non-ASCII unicode strings give an error on decode(), as binascii.b2a_qp() does? ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 12:29:28 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 10:29:28 -0000 Subject: [issue1709599] run test_1565150(test_os.py) only on NTFS Message-ID: <1188469768.55.0.746672320477.issue1709599@psf.upfronthosting.co.za> Georg Brandl added the comment: Affects 2.5 only. ---------- nosy: +georg.brandl versions: +Python 2.5 -Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 12:39:06 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 10:39:06 -0000 Subject: [issue1680959] Add tests for pipes module (test_pipes) Message-ID: <1188470346.16.0.487812003622.issue1680959@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as rev. 57716. ---------- assignee: facundobatista -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 13:46:01 2007 From: report at bugs.python.org (Ismail Donmez) Date: Thu, 30 Aug 2007 11:46:01 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188474361.05.0.581008842844.issue1528802@psf.upfronthosting.co.za> Ismail Donmez added the comment: @George, "i".upper() WILL be I-with-a-dot-above in Turkish.i _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 15:15:56 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 30 Aug 2007 13:15:56 -0000 Subject: [issue883466] quopri encoding & Unicode Message-ID: <1188479756.3.0.685610787661.issue883466@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Georg: Yes, sure. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Aug 30 15:21:54 2007 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 30 Aug 2007 13:21:54 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188480114.55.0.733989100015.issue1528802@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Unassigning this. Unless someone provides a patch to add context sensitivity to the Unicode upper/lower conversions, I don't think anything will change. The mapping you see in Python (for Unicode) is taken straight from the Unicode database and there's nothing we can or want to do to change those predefined mappings. The 8-bit string mappings OTOH are taken from the underlying C library - again nothing we can change. ---------- assignee: lemburg -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 15:43:41 2007 From: report at bugs.python.org (Ismail Donmez) Date: Thu, 30 Aug 2007 13:43:41 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188481421.56.0.0338659340939.issue1528802@psf.upfronthosting.co.za> Ismail Donmez added the comment: There is no need to unassign this, the bug is invalid. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 15:48:44 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 13:48:44 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1188481724.92.0.363576520364.issue1061@psf.upfronthosting.co.za> New submission from Guido van Rossum: The various caches in abc.py should be turned into weak sets so that the caches don't keep the subclass objects alive forever. ---------- messages: 55480 nosy: gvanrossum severity: normal status: open title: ABC caches should use weak refs versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 15:48:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 13:48:45 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1188481724.92.0.363576520364.issue1061@psf.upfronthosting.co.za> New submission from Guido van Rossum: The various caches in abc.py should be turned into weak sets so that the caches don't keep the subclass objects alive forever. ---------- messages: 55480 nosy: gvanrossum severity: normal status: open title: ABC caches should use weak refs versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 16:40:27 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 14:40:27 -0000 Subject: [issue1040] Unicode problem with TZ Message-ID: <1188484827.47.0.0407724493617.issue1040@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is now fixed in r57720. Using wide APIs would be possible through GetTimeZoneInformation, however, then TZ won't be supported anymore (unless the CRT code to parse TZ is duplicated). ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 16:52:28 2007 From: report at bugs.python.org (Kevin Ar18) Date: Thu, 30 Aug 2007 14:52:28 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188485548.62.0.401098664314.issue1060@psf.upfronthosting.co.za> Kevin Ar18 added the comment: Here's another bug report that talks about a 2GB file limit: http://bugs.python.org/issue1189216 The diff offered there does not solve the problem; actually it's possible that the diff may not have anything to do with fixing the problem (though I'm not certain), but may just be a readability change. I tried to program a solution based on other stuff I saw/read on the internet, but ran into different problems.... I took the line: bytes = self.fp.read(zinfo.compress_size) and made it read a little bit at a time and add the result to bytes as it went along. This was really slow (as it had to add the result to the larger and larger bytes string each time); I tried with a list, but I couldn't find how to join the list back together into a string when done (similar to the javascript join() method). However, even with the list method, I ran into an odd "memory error," as it looped through into the higher numbers, that I have no idea why it was happening, so I gave up at that point. Also, I have no idea if this one line in the zipfile module is the only problem or if there are others that will pop up once you get that part fixed. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 17:07:19 2007 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 30 Aug 2007 15:07:19 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1188486439.08.0.435269150235.issue1061@psf.upfronthosting.co.za> Thomas Wouters added the comment: Here's a working version of that idea, with a WeakSet implementation I had lying around (but never really used.) It seems to work, and fixes the refcount issues, but the WeakSet could do with some extra tests ;-) ---------- nosy: +twouters __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: abc_weakref_set.diff Type: application/octet-stream Size: 5076 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/7e10369b/attachment.obj From report at bugs.python.org Thu Aug 30 17:23:37 2007 From: report at bugs.python.org (toxik) Date: Thu, 30 Aug 2007 15:23:37 -0000 Subject: [issue1686386] Python SEGFAULT on invalid superclass access Message-ID: <1188487417.56.0.851390655796.issue1686386@psf.upfronthosting.co.za> toxik added the comment: Minor note: The patch mixes tabs and spaces. AFAIK, PEP 7 says to use four spaces when making new code, and follow suite in legacy, or convert it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 17:33:29 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 15:33:29 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188488009.19.0.937740530618.issue1060@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I now see the problem. What you want to do cannot possibly work. You are trying to create a string object that is larger than 2GB; this is not possible on a 32-bit system (which I assume you are using). No matter how you modify the read() function, it would always return a string that is so large it cannot fit into the address space. This will be fixed in Python 2.6, which has a separate .open method, allowing to read the individual files in the zipfile as streams. ---------- nosy: +loewis versions: +Python 2.5 -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 17:34:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 15:34:30 -0000 Subject: [issue1039] Asssertion in Windows debug build Message-ID: <1188488070.28.0.223209651209.issue1039@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 17:43:53 2007 From: report at bugs.python.org (Kevin Ar18) Date: Thu, 30 Aug 2007 15:43:53 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188488633.85.0.256139868374.issue1060@psf.upfronthosting.co.za> Kevin Ar18 added the comment: Just some thoughts.... In posting about this problem elsewhere, it has been argued that you shouldn't be copying that much stuff into memory anyways (though there are possible cases for a need for that). However, the question is what should the zipfile module do. At the very least it should account for this 2GB limitation and say it can't do it. However, how it should interact with the programmer is another question. In one of the replies, I am told that strings have a 2GB limitation, which means the zipfile module can't be used in it's current form, even if fixed. Does this mean that the zipfile module needs to add some additional methods for incrementally getting data and writing data? Or does it mean that programmers should be the ones to program an incremental system when they need it... Or? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 17:45:24 2007 From: report at bugs.python.org (Kevin Ar18) Date: Thu, 30 Aug 2007 15:45:24 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188488724.53.0.826795600241.issue1060@psf.upfronthosting.co.za> Kevin Ar18 added the comment: So, just add an error to the module (so it won't crash)? BTW, is Python 2.6 ready for use? I could use that feature now. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 17:46:31 2007 From: report at bugs.python.org (Kevin Ar18) Date: Thu, 30 Aug 2007 15:46:31 -0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) Message-ID: <1188488791.4.0.227850346472.issue1060@psf.upfronthosting.co.za> Kevin Ar18 added the comment: Maybe a message that says that strings on 32-bit CPUs cannot handle more than 2GB of data; use the stream instead? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 18:23:50 2007 From: report at bugs.python.org (jan matejek) Date: Thu, 30 Aug 2007 16:23:50 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188491030.35.0.841280335447.issue1044@psf.upfronthosting.co.za> jan matejek added the comment: if that can be considered "official stance", it's fine by me. feel free to close the bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 18:34:13 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 16:34:13 -0000 Subject: [issue1675334] Draft implementation for PEP 364 Message-ID: <1188491653.9.0.485570313781.issue1675334@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- versions: +Python 3.0 -Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 18:34:24 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 16:34:24 -0000 Subject: [issue1001] 2to3 crashes on input files with no trailing newlines Message-ID: <1188491664.08.0.504029696944.issue1001@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 18:36:25 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 16:36:25 -0000 Subject: [issue1061] ABC caches should use weak refs In-Reply-To: <1188486439.08.0.435269150235.issue1061@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On 8/30/07, Thomas Wouters wrote: > > Thomas Wouters added the comment: > > Here's a working version of that idea, with a WeakSet implementation I > had lying around (but never really used.) It seems to work, and fixes > the refcount issues, but the WeakSet could do with some extra tests ;-) I was torturing the WeakSet implementation, but didn't get very far: Python 3.0x (py3k, Aug 30 2007, 09:27:35) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from weakref import WeakSet as WS [40407 refs] >>> a = WS([1, 2, 3]) Fatal Python error: Cannot recover from stack overflow. Aborted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 18:37:21 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 16:37:21 -0000 Subject: [issue1463370] Add .format() method to str and unicode Message-ID: <1188491841.8.0.185980485141.issue1463370@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 18:46:25 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 16:46:25 -0000 Subject: [issue1753395] struni: assertion in Windows debug build Message-ID: <1188492385.46.0.749008339005.issue1753395@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch looks fine to me, please apply. ---------- assignee: loewis -> georg.brandl resolution: -> accepted _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 18:55:28 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 16:55:28 -0000 Subject: [issue1467929] %-formatting and dicts Message-ID: <1188492928.69.0.260218942393.issue1467929@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- priority: immediate -> normal _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 19:15:43 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 30 Aug 2007 17:15:43 -0000 Subject: [issue1039] Asssertion in Windows debug build Message-ID: <1188494143.01.0.576407676571.issue1039@psf.upfronthosting.co.za> Thomas Heller added the comment: Applied in rev. 57731. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 19:42:08 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 17:42:08 -0000 Subject: [issue1114345] Add SSL certificate validation Message-ID: <1188495728.66.0.356372628423.issue1114345@psf.upfronthosting.co.za> Bill Janssen added the comment: The new SSL code does work with self-signed certs, either by skipping validation with CERT_NONE, or by adding the cert to the ca_certs file. I don't believe there are any other options that make sense, but if you can suggest one, let's hear it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 19:53:19 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 17:53:19 -0000 Subject: [issue1062] issue message copy Message-ID: <1188496399.92.0.368162629574.issue1062@psf.upfronthosting.co.za> New submission from Bill Janssen: It would be useful to have a way to determine whether a socket is or is not already bound to a local port (i.e., has had "bind" or "connect" called on it). It's tempting to call socket.socket.getsockname(), but the behavior of this method is essentially undefined (i.e., it's whatever the underlying platform feels like doing, and there seem to be no constraints on that -- Unix systems typically return what seems to be someone's idea of a null address, while Windows systems currently raise an exception.). So an extension API is needed to probe this state. Suggest adding a method "is_bound" which returns a boolean. ---------- messages: 55494 nosy: janssen severity: normal status: open __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 19:53:20 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 17:53:20 -0000 Subject: [issue1062] issue message copy Message-ID: <1188496399.92.0.368162629574.issue1062@psf.upfronthosting.co.za> New submission from Bill Janssen: It would be useful to have a way to determine whether a socket is or is not already bound to a local port (i.e., has had "bind" or "connect" called on it). It's tempting to call socket.socket.getsockname(), but the behavior of this method is essentially undefined (i.e., it's whatever the underlying platform feels like doing, and there seem to be no constraints on that -- Unix systems typically return what seems to be someone's idea of a null address, while Windows systems currently raise an exception.). So an extension API is needed to probe this state. Suggest adding a method "is_bound" which returns a boolean. ---------- messages: 55494 nosy: janssen severity: normal status: open __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 19:54:45 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 30 Aug 2007 17:54:45 -0000 Subject: [issue1002] Patch to rename HTMLParser module to lower_case Message-ID: <1188496485.12.0.311232236513.issue1002@psf.upfronthosting.co.za> Collin Winter added the comment: orsenthil: that this will break external modules is completely acceptable. Those modules won't work out-of-the-box with Python 3 anyway, and hopefully Paul's patch to 2to3 will alleviate some of the burden. ---------- nosy: +collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 19:55:11 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 17:55:11 -0000 Subject: [issue1062] nice to have a way to tell if a socket is bound Message-ID: <1188496511.06.0.277970300285.issue1062@psf.upfronthosting.co.za> Bill Janssen added the comment: What happened to my issue metadata? ---------- assignee: -> janssen priority: -> low title: None -> nice to have a way to tell if a socket is bound type: -> rfe versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 20:15:18 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 30 Aug 2007 18:15:18 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188497718.88.0.66098561933.issue1617699@psf.upfronthosting.co.za> Thomas Heller added the comment: Set to accepted. As pointed out in private email, please apply it to the trunk. Your thoughts about the 'length' of pointers make sense, and are very similar to what I had in mind when I implemented pointer indexing. For indexing pointers, negative indices (in the C sense, not the usual Python sense) absolutely are needed, IMO. For slicing, missing indices do not really have a meaning - would it be possible to disallow them? ---------- resolution: -> accepted _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 20:15:47 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 30 Aug 2007 18:15:47 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188497747.04.0.594562492017.issue1617699@psf.upfronthosting.co.za> Changes by Thomas Heller: ---------- assignee: theller -> twouters _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 20:30:11 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 18:30:11 -0000 Subject: [issue1753395] struni: assertion in Windows debug build In-Reply-To: <1188492385.46.0.749008339005.issue1753395@psf.upfronthosting.co.za> Message-ID: <46D70CB7.70409@python.org> Georg Brandl added the comment: Martin v. L?wis schrieb: > Martin v. L?wis added the comment: > > The patch looks fine to me, please apply. Done in rev. 57752. ---------- status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 20:39:20 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 18:39:20 -0000 Subject: [issue1746880] AMD64 installer does not place python25.dll in system dir Message-ID: <1188499160.61.0.846864114798.issue1746880@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now fixed it in 57750, 57751, 57754. I leave the bug open until I can actually test it. ---------- resolution: -> fixed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 20:41:58 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 18:41:58 -0000 Subject: [issue1062] nice to have a way to tell if a socket is bound Message-ID: <1188499318.23.0.632144963487.issue1062@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Given that the underlying platform has no support for that, it will be difficult to implement correctly across all systems. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 20:46:31 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 18:46:31 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188499591.95.0.141391577225.issue1528802@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I agree with cartman: Python behaves as designed in all cases discussed here. Closing this report as invalid. ---------- nosy: +loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 21:02:39 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 19:02:39 -0000 Subject: [issue1061] ABC caches should use weak refs In-Reply-To: Message-ID: <46D71456.9040905@gmx.net> Georg Brandl added the comment: Guido van Rossum schrieb: > Guido van Rossum added the comment: > > On 8/30/07, Thomas Wouters wrote: >> >> Thomas Wouters added the comment: >> >> Here's a working version of that idea, with a WeakSet implementation I >> had lying around (but never really used.) It seems to work, and fixes >> the refcount issues, but the WeakSet could do with some extra tests ;-) > > I was torturing the WeakSet implementation, but didn't get very far: > > Python 3.0x (py3k, Aug 30 2007, 09:27:35) > [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> from weakref import WeakSet as WS > [40407 refs] >>>> a = WS([1, 2, 3]) > Fatal Python error: Cannot recover from stack overflow. > Aborted The update() method can not be implemented in terms of converting the argument to a WeakSet, since that leads to infinite recursion on creation (as to why you get this fatal error, not a RuntimeError, no idea). Also, the fact that the operator-versions of set operations only support other sets as their second operands, while the method-versions support any iterable, is not preserved. Georg ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 21:03:07 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 19:03:07 -0000 Subject: [issue1528802] Turkish Character Message-ID: <1188500587.36.0.388986258353.issue1528802@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> invalid status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 21:05:06 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 19:05:06 -0000 Subject: [issue1709599] run test_1565150(test_os.py) only on NTFS Message-ID: <1188500706.38.0.770560558046.issue1709599@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r57759 and r57760. I added it to the trunk as well, as it might be possible that the test is run on FAT even if the operating system is Windows XP. ---------- nosy: +loewis resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 21:10:38 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 19:10:38 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1188501038.05.0.329044853902.issue1061@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The fatal error is raised if the stack overflows in the process of handling RuntimeError. In certain cases, the C algorithms won't bail out if a RuntimeError is raised, and just catch it. If that then causes another stack overflow, Python gives up. One such case is an overflow occuring during a comparison operation of a dictionary lookup, IIRC. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 21:36:22 2007 From: report at bugs.python.org (Carsten Grohmann) Date: Thu, 30 Aug 2007 19:36:22 -0000 Subject: [issue1063] Small typo in properties example Message-ID: <1188502582.95.0.0929628871565.issue1063@psf.upfronthosting.co.za> New submission from Carsten Grohmann: The example for property() contains a typo / small bug: class C(object): def __init__(self): self.__x = None [...] should be: class C(object): def __init__(self): self._x = None [...] Source: http://docs.python.org/lib/built-in-funcs.html ---------- components: Documentation messages: 55505 nosy: cgrohmann severity: minor status: open title: Small typo in properties example versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 21:36:23 2007 From: report at bugs.python.org (Carsten Grohmann) Date: Thu, 30 Aug 2007 19:36:23 -0000 Subject: [issue1063] Small typo in properties example Message-ID: <1188502582.95.0.0929628871565.issue1063@psf.upfronthosting.co.za> New submission from Carsten Grohmann: The example for property() contains a typo / small bug: class C(object): def __init__(self): self.__x = None [...] should be: class C(object): def __init__(self): self._x = None [...] Source: http://docs.python.org/lib/built-in-funcs.html ---------- components: Documentation messages: 55505 nosy: cgrohmann severity: minor status: open title: Small typo in properties example versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:10:18 2007 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 30 Aug 2007 20:10:18 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188504618.74.0.85938481184.issue1617699@psf.upfronthosting.co.za> Thomas Wouters added the comment: Well, that's not quite how I implemented the slicing, and it's also not how the existing simple-slicing was implemented: A negative start index is taken to mean 0, and a stop index below the start index is taken to mean 'the start index' (leading to an empty slice.) However, it isn't too hard to do what I think you want done: a negative index means indexing before the pointer, not from the end of the pointer, and missing indices are only okay if they clearly mean '0' ('start' when step > 0, 'stop' when step < 0.) So: P[5:10] would slice from P[5] up to but not including P[10], P[-5:5] would slice from P[-5] up to but not including P[5], P[:5] would slice from P[0] up to but not including P[5], P[5::-1] would slice from P[5] down to *and including* P[0] but the following would all be errors: P[5:] P[:5:-1] P[:] P[::-1] Does that sound like what you wanted? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 22:19:10 2007 From: report at bugs.python.org (Thomas Heller) Date: Thu, 30 Aug 2007 20:19:10 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188505150.61.0.179632552159.issue1617699@psf.upfronthosting.co.za> Thomas Heller added the comment: Yes. But looking at your examples I think it would be better to forbid missing indices completely instead of allowing them only where they clearly mean 0. Writing (and reading!) a 0 is faster than thinking about if a missing index is allowed or what it means. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 22:26:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 20:26:30 -0000 Subject: [issue1064] Test issue Message-ID: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Let's see who gets this ---------- assignee: georg.brandl messages: 55508 nosy: georg.brandl, loewis severity: normal status: open title: Test issue __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:26:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 20:26:30 -0000 Subject: [issue1064] Test issue Message-ID: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Let's see who gets this ---------- assignee: georg.brandl messages: 55508 nosy: georg.brandl, loewis severity: normal status: open title: Test issue __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:27:14 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 30 Aug 2007 20:27:14 -0000 Subject: [issue1064] Test issue Message-ID: <1188505634.05.0.306414295344.issue1064@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:28:31 2007 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 30 Aug 2007 20:28:31 -0000 Subject: [issue1044] tarfile insecure pathname extraction Message-ID: <1188505711.69.0.455511517181.issue1044@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I updated the documentation, r57764 (trunk) and r57765 (2.5). ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:36:11 2007 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 30 Aug 2007 20:36:11 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188506171.25.0.2821358065.issue1617699@psf.upfronthosting.co.za> Thomas Wouters added the comment: Hmmm.... Well, that's fine by me, but it changes current behaviour, and in a way that ctypes own testsuite was testing, even ;) (it does, e.g., 'p[:4]' in a couple of places.) Requiring the start always would possibly break a lot of code. We could make only the start (and step) optional, and the start only if the step is positive, perhaps? That would change no existing, sane behaviour. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Aug 30 22:45:45 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 20:45:45 -0000 Subject: [issue1061] ABC caches should use weak refs Message-ID: <1188506745.56.0.323400028685.issue1061@psf.upfronthosting.co.za> Guido van Rossum added the comment: Georg, would you have time to submit an improved patch? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:49:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 20:49:47 -0000 Subject: [issue1064] Test issue In-Reply-To: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za> Message-ID: <46D72D71.4070901@python.org> Georg Brandl added the comment: Martin v. L?wis schrieb: > New submission from Martin v. L?wis: > > Let's see who gets this I did. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 22:54:00 2007 From: report at bugs.python.org (Georg Brandl) Date: Thu, 30 Aug 2007 20:54:00 -0000 Subject: [issue1063] Small typo in properties example In-Reply-To: <1188502582.95.0.0929628871565.issue1063@psf.upfronthosting.co.za> Message-ID: <46D72E6F.3000605@gmx.net> Georg Brandl added the comment: Thanks, this is already fixed in the development docs (http://docs.python.org/dev). ---------- nosy: +georg.brandl resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 23:41:18 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 21:41:18 -0000 Subject: [issue1062] nice to have a way to tell if a socket is bound In-Reply-To: <1188499318.23.0.632144963487.issue1062@psf.upfronthosting.co.za> Message-ID: <4b3e516a0708301441o3487eaeev9d3ff1c2bf5bc90f@mail.gmail.com> Bill Janssen added the comment: Indeed. Calls for some design chops. Again, it's a question of what the socket.socket class really is. Bill On 8/30/07, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Given that the underlying platform has no support for that, it will be > difficult to implement correctly across all systems. > > ---------- > nosy: +loewis > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 23:46:15 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 21:46:15 -0000 Subject: [issue1065] ssl.py shouldn't change class names from 2.6 to 3.x Message-ID: <1188510375.86.0.454173087952.issue1065@psf.upfronthosting.co.za> New submission from Bill Janssen: It seems like a bad idea to have ssl.sslsocket(socket) suddenly become ssl.SSLSocket(fileno) in 2.3. Since no user code is currently using the ssl module, it would be a good idea to change it upfront (if possible) so that code written against 2.6's version of the ssl module doesn't break gratuitously in 3.x. Would suggest changing the class name now, not documenting the initializer, and adding a function (say, "wrap_socket") which takes a socket and the other init arguments to the current ssl.sslsocket(), which would continue to work the same way in 3.x. ---------- assignee: janssen components: Library (Lib) keywords: py3k messages: 55516 nosy: janssen priority: normal severity: normal status: open title: ssl.py shouldn't change class names from 2.6 to 3.x type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Aug 30 23:46:15 2007 From: report at bugs.python.org (Bill Janssen) Date: Thu, 30 Aug 2007 21:46:15 -0000 Subject: [issue1065] ssl.py shouldn't change class names from 2.6 to 3.x Message-ID: <1188510375.86.0.454173087952.issue1065@psf.upfronthosting.co.za> New submission from Bill Janssen: It seems like a bad idea to have ssl.sslsocket(socket) suddenly become ssl.SSLSocket(fileno) in 2.3. Since no user code is currently using the ssl module, it would be a good idea to change it upfront (if possible) so that code written against 2.6's version of the ssl module doesn't break gratuitously in 3.x. Would suggest changing the class name now, not documenting the initializer, and adding a function (say, "wrap_socket") which takes a socket and the other init arguments to the current ssl.sslsocket(), which would continue to work the same way in 3.x. ---------- assignee: janssen components: Library (Lib) keywords: py3k messages: 55516 nosy: janssen priority: normal severity: normal status: open title: ssl.py shouldn't change class names from 2.6 to 3.x type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 00:26:17 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 30 Aug 2007 22:26:17 -0000 Subject: [issue1462525] URI parsing library Message-ID: <1188512777.66.0.237056801508.issue1462525@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- nosy: +skip.montanaro _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 31 00:26:57 2007 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 30 Aug 2007 22:26:57 -0000 Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support Message-ID: <1188512817.06.0.367611287431.issue1675455@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- nosy: +skip.montanaro _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 31 01:01:36 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 30 Aug 2007 23:01:36 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188514896.49.0.507791174924.issue1066@psf.upfronthosting.co.za> New submission from Collin Winter: This does not implement __context__; it turned out to be much more difficult than expected and will require some more thought. The new raise syntax and the __traceback__ and __cause__ attributes are implemented, however. This does not yet include a docs patch, though I'm working on that now. ---------- assignee: gvanrossum components: Interpreter Core, Library (Lib), Tests files: raise.patch keywords: patch, py3k messages: 55517 nosy: collinwinter, gvanrossum severity: normal status: open title: Implement PEPs 3109, 3134 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: raise.patch Type: text/x-patch Size: 27839 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/697ec670/attachment-0002.bin From report at bugs.python.org Fri Aug 31 01:01:36 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 30 Aug 2007 23:01:36 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188514896.49.0.507791174924.issue1066@psf.upfronthosting.co.za> New submission from Collin Winter: This does not implement __context__; it turned out to be much more difficult than expected and will require some more thought. The new raise syntax and the __traceback__ and __cause__ attributes are implemented, however. This does not yet include a docs patch, though I'm working on that now. ---------- assignee: gvanrossum components: Interpreter Core, Library (Lib), Tests files: raise.patch keywords: patch, py3k messages: 55517 nosy: collinwinter, gvanrossum severity: normal status: open title: Implement PEPs 3109, 3134 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: raise.patch Type: text/x-patch Size: 27839 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/697ec670/attachment-0003.bin From report at bugs.python.org Fri Aug 31 01:01:47 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 30 Aug 2007 23:01:47 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188514907.93.0.86111488903.issue1066@psf.upfronthosting.co.za> Changes by Collin Winter: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 01:01:58 2007 From: report at bugs.python.org (Collin Winter) Date: Thu, 30 Aug 2007 23:01:58 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188514918.04.0.72368458087.issue1066@psf.upfronthosting.co.za> Changes by Collin Winter: __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 01:49:52 2007 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 30 Aug 2007 23:49:52 -0000 Subject: [issue1617699] slice-object support for ctypes Pointer/Array Message-ID: <1188517792.3.0.193616265317.issue1617699@psf.upfronthosting.co.za> Thomas Wouters added the comment: Checked in a slightly newer version. ---------- resolution: accepted -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Aug 31 01:52:35 2007 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Aug 2007 23:52:35 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188517955.44.0.202595017452.issue1066@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please check it in yourself. ---------- assignee: gvanrossum -> collinwinter resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 01:53:48 2007 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 30 Aug 2007 23:53:48 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188518028.47.0.00150831255995.issue1067@psf.upfronthosting.co.za> New submission from Thomas Wouters: test_smtplib fails because asyncore uses bytes(data) where data may be bytes or str or some undefined type. The attached patch fixes it to the extend that test_smtplib works again (plus a small fix in test_smtplib itself.) I'm not sure if this is the right thing to do -- maybe it should be using iso-8859-1, or maybe asyncore and asynchat should be ripped out by the roots and burned at the stake. ---------- assignee: gvanrossum files: asyncore.diff keywords: patch messages: 55520 nosy: gvanrossum, twouters severity: normal status: open title: test_smtplib failures (caused by asyncore) __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: asyncore.diff Type: application/octet-stream Size: 2411 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/d96bd774/attachment.obj From report at bugs.python.org Fri Aug 31 01:53:48 2007 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 30 Aug 2007 23:53:48 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188518028.47.0.00150831255995.issue1067@psf.upfronthosting.co.za> New submission from Thomas Wouters: test_smtplib fails because asyncore uses bytes(data) where data may be bytes or str or some undefined type. The attached patch fixes it to the extend that test_smtplib works again (plus a small fix in test_smtplib itself.) I'm not sure if this is the right thing to do -- maybe it should be using iso-8859-1, or maybe asyncore and asynchat should be ripped out by the roots and burned at the stake. ---------- assignee: gvanrossum files: asyncore.diff keywords: patch messages: 55520 nosy: gvanrossum, twouters severity: normal status: open title: test_smtplib failures (caused by asyncore) __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: asyncore.diff Type: application/octet-stream Size: 2411 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070830/d96bd774/attachment-0001.obj From report at bugs.python.org Fri Aug 31 02:17:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 31 Aug 2007 00:17:46 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188519466.42.0.141407139872.issue1067@psf.upfronthosting.co.za> Changes by Guido van Rossum: ---------- versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 02:18:46 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 31 Aug 2007 00:18:46 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188519526.93.0.170564426138.issue1067@psf.upfronthosting.co.za> Guido van Rossum added the comment: Great, please check it in. This is close to what I had sitting somewhere, but I hadn't finished it. ---------- assignee: gvanrossum -> twouters resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 02:20:22 2007 From: report at bugs.python.org (Thomas Wouters) Date: Fri, 31 Aug 2007 00:20:22 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188519622.26.0.859968580232.issue1067@psf.upfronthosting.co.za> Thomas Wouters added the comment: Checked in. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 02:21:02 2007 From: report at bugs.python.org (Collin Winter) Date: Fri, 31 Aug 2007 00:21:02 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188519662.08.0.636656319904.issue1066@psf.upfronthosting.co.za> Changes by Collin Winter: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 02:23:41 2007 From: report at bugs.python.org (Collin Winter) Date: Fri, 31 Aug 2007 00:23:41 -0000 Subject: [issue1066] Implement PEPs 3109, 3134 Message-ID: <1188519821.29.0.528625097621.issue1066@psf.upfronthosting.co.za> Collin Winter added the comment: Committed as r57783. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 02:44:57 2007 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 31 Aug 2007 00:44:57 -0000 Subject: [issue980098] Module to dynamically generate structseq objects Message-ID: <1188521097.33.0.784491581779.issue980098@psf.upfronthosting.co.za> Changes by Skip Montanaro: ---------- nosy: +skip.montanaro ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Aug 31 04:40:05 2007 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 31 Aug 2007 02:40:05 -0000 Subject: [issue504152] rfc822 long header continuation broken Message-ID: <1188528005.89.0.221577449551.issue504152@psf.upfronthosting.co.za> Guido van Rossum added the comment: Barry, what do you think of this patch? How does the email package handle this case? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Aug 31 08:13:20 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 31 Aug 2007 06:13:20 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188540800.09.0.868025361489.issue1067@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think it's incorrect: asynchat operates on bytes, not strings, as it directly interfaces with the socket, and no encoding is specified for the protocol. So, IMO, callers should be expected to pass bytes only, as terminator and as data. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 08:48:20 2007 From: report at bugs.python.org (Talin) Date: Fri, 31 Aug 2007 06:48:20 -0000 Subject: [issue1068] Documentation Updates for PEP 3101 string formatting Message-ID: <1188542900.18.0.891798686686.issue1068@psf.upfronthosting.co.za> New submission from Talin: This patch contains documentation updates for the Python Library Reference pertaining to PEP 3101 "Advanced String Formatting". ---------- components: Documentation files: docupdates.diff messages: 55526 nosy: talin severity: normal status: open title: Documentation Updates for PEP 3101 string formatting versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: docupdates.diff Type: application/octet-stream Size: 21294 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/bdcb7882/attachment-0002.obj From report at bugs.python.org Fri Aug 31 08:48:20 2007 From: report at bugs.python.org (Talin) Date: Fri, 31 Aug 2007 06:48:20 -0000 Subject: [issue1068] Documentation Updates for PEP 3101 string formatting Message-ID: <1188542900.18.0.891798686686.issue1068@psf.upfronthosting.co.za> New submission from Talin: This patch contains documentation updates for the Python Library Reference pertaining to PEP 3101 "Advanced String Formatting". ---------- components: Documentation files: docupdates.diff messages: 55526 nosy: talin severity: normal status: open title: Documentation Updates for PEP 3101 string formatting versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: docupdates.diff Type: application/octet-stream Size: 21294 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/bdcb7882/attachment-0003.obj From report at bugs.python.org Fri Aug 31 09:08:29 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 07:08:29 -0000 Subject: [issue1069] invalid file encoding results in "SyntaxError: None" Message-ID: <1188544109.07.0.0440582794516.issue1069@psf.upfronthosting.co.za> New submission from Georg Brandl: With attached file (which contains a single latin-1 instead of utf-8 encoded character), Python prints "SyntaxError: None" instead of a more helpful analysis of the problem. ---------- assignee: loewis files: x.py keywords: py3k messages: 55527 nosy: georg.brandl, loewis severity: normal status: open title: invalid file encoding results in "SyntaxError: None" type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: x.py Type: text/x-python-script Size: 26 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/8d2efcd4/attachment.bin From report at bugs.python.org Fri Aug 31 09:08:29 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 07:08:29 -0000 Subject: [issue1069] invalid file encoding results in "SyntaxError: None" Message-ID: <1188544109.07.0.0440582794516.issue1069@psf.upfronthosting.co.za> New submission from Georg Brandl: With attached file (which contains a single latin-1 instead of utf-8 encoded character), Python prints "SyntaxError: None" instead of a more helpful analysis of the problem. ---------- assignee: loewis files: x.py keywords: py3k messages: 55527 nosy: georg.brandl, loewis severity: normal status: open title: invalid file encoding results in "SyntaxError: None" type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: x.py Type: text/x-python-script Size: 26 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/8d2efcd4/attachment-0001.bin From report at bugs.python.org Fri Aug 31 09:10:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 07:10:38 -0000 Subject: [issue1070] unicode identifiers in error messages Message-ID: <1188544238.64.0.905111871367.issue1070@psf.upfronthosting.co.za> New submission from Georg Brandl: When showing a name in a NameError, the encoding is messed up. (File y.py, encoded in UTF-8, contains only only the line shown in the traceback; the terminal encoding is set to UTF-8.) $ python3k y.py Traceback (most recent call last): File "y.py", line 1, in print(?) NameError: name '??' is not defined ---------- assignee: loewis keywords: py3k messages: 55528 nosy: georg.brandl, loewis severity: normal status: open title: unicode identifiers in error messages type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 09:10:38 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 07:10:38 -0000 Subject: [issue1070] unicode identifiers in error messages Message-ID: <1188544238.64.0.905111871367.issue1070@psf.upfronthosting.co.za> New submission from Georg Brandl: When showing a name in a NameError, the encoding is messed up. (File y.py, encoded in UTF-8, contains only only the line shown in the traceback; the terminal encoding is set to UTF-8.) $ python3k y.py Traceback (most recent call last): File "y.py", line 1, in print(?) NameError: name '??' is not defined ---------- assignee: loewis keywords: py3k messages: 55528 nosy: georg.brandl, loewis severity: normal status: open title: unicode identifiers in error messages type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 11:23:25 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 09:23:25 -0000 Subject: [issue1068] Documentation Updates for PEP 3101 string formatting Message-ID: <1188552205.37.0.918662323079.issue1068@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks! Committed as part of rev. 57829. ---------- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 12:30:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 10:30:33 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188556233.28.0.810619239992.issue1071@psf.upfronthosting.co.za> New submission from Georg Brandl: While it's documented that unicode.translate()s table maps ordinals to strings/ordinals/None, if you give a unicode key in the table it will just be ignored. This is quite surprising. ---------- assignee: lemburg components: Unicode messages: 55530 nosy: georg.brandl, lemburg, loewis priority: normal severity: normal status: open title: unicode.translate() doesn't error out on invalid translation table type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 12:30:33 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 10:30:33 -0000 Subject: [issue1071] unicode.translate() doesn't error out on invalid translation table Message-ID: <1188556233.28.0.810619239992.issue1071@psf.upfronthosting.co.za> New submission from Georg Brandl: While it's documented that unicode.translate()s table maps ordinals to strings/ordinals/None, if you give a unicode key in the table it will just be ignored. This is quite surprising. ---------- assignee: lemburg components: Unicode messages: 55530 nosy: georg.brandl, lemburg, loewis priority: normal severity: normal status: open title: unicode.translate() doesn't error out on invalid translation table type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 13:01:44 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 31 Aug 2007 11:01:44 -0000 Subject: [issue1070] unicode identifiers in error messages Message-ID: <1188558104.46.0.815886376294.issue1070@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is now fixed in r57837 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 13:12:43 2007 From: report at bugs.python.org (Thomas Wouters) Date: Fri, 31 Aug 2007 11:12:43 -0000 Subject: [issue1067] test_smtplib failures (caused by asyncore) Message-ID: <1188558763.64.0.767633304454.issue1067@psf.upfronthosting.co.za> Thomas Wouters added the comment: I agree, but the change wasn't actually mine. I merely adjusted the already-implemented strategy to the fact that bytes(str) no longer works. I think the original change was Jeremy H's. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 13:18:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 31 Aug 2007 11:18:04 -0000 Subject: [issue1069] invalid file encoding results in "SyntaxError: None" Message-ID: <1188559084.62.0.223612783382.issue1069@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is now fixed in r57838. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 20:08:12 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 31 Aug 2007 18:08:12 -0000 Subject: [issue1072] Documentaion font size too small Message-ID: <1188583692.91.0.062799176062.issue1072@psf.upfronthosting.co.za> New submission from Nir Soffer: The css uses font-size of 13px. This is way too small and hard to read specially on high resolution screens used typically on laptops. Font size for body text should be 100%. A user can select the preferred font size using the browser. Python 2.x documentation is much more readable. ---------- components: Documentation messages: 55534 nosy: nirs severity: major status: open title: Documentaion font size too small versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 20:08:13 2007 From: report at bugs.python.org (Nir Soffer) Date: Fri, 31 Aug 2007 18:08:13 -0000 Subject: [issue1072] Documentaion font size too small Message-ID: <1188583692.91.0.062799176062.issue1072@psf.upfronthosting.co.za> New submission from Nir Soffer: The css uses font-size of 13px. This is way too small and hard to read specially on high resolution screens used typically on laptops. Font size for body text should be 100%. A user can select the preferred font size using the browser. Python 2.x documentation is much more readable. ---------- components: Documentation messages: 55534 nosy: nirs severity: major status: open title: Documentaion font size too small versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 20:15:47 2007 From: report at bugs.python.org (Georg Brandl) Date: Fri, 31 Aug 2007 18:15:47 -0000 Subject: [issue1072] Documentaion font size too small Message-ID: <1188584147.21.0.35495886707.issue1072@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, I wanted to change that even a while ago. ---------- assignee: -> georg.brandl components: +Documentation tools (Sphinx) -Documentation nosy: +georg.brandl severity: major -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 21:01:38 2007 From: report at bugs.python.org (Aki) Date: Fri, 31 Aug 2007 19:01:38 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188586898.81.0.0470760748559.issue1073@psf.upfronthosting.co.za> Changes by Aki: ---------- severity: major status: open title: Mysterious failure under Windows versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 21:06:22 2007 From: report at bugs.python.org (Bill Janssen) Date: Fri, 31 Aug 2007 19:06:22 -0000 Subject: [issue1072] Documentaion font size too small Message-ID: <1188587182.95.0.769269052906.issue1072@psf.upfronthosting.co.za> Bill Janssen added the comment: I agree. It shouldn't be an absolute size, and it is too small. ---------- nosy: +janssen __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 21:14:12 2007 From: report at bugs.python.org (Aki) Date: Fri, 31 Aug 2007 19:14:12 -0000 Subject: [issue1073] Mysterious failure under Windows Message-ID: <1188587652.29.0.942099361448.issue1073@psf.upfronthosting.co.za> New submission from Aki: Hi, I'm not sure this is a right place to write in the problem I found. What I found was: (1) create a thread (2) open a file in the thread (3) everything works fine under Solaris (4) Openning a file in the thread fails intermittenly under Windows Not always it fails. The file is there but it returns: File "h:\prj\socgear\unidbg\tkunidbg\sub.py", line 94, in thread_worker fd = open(fn, 'rb') IOError: [Errno 2] No such file or directory: './XXX.dat' (5) The problem goes away (under Windows) if I have the main thread wait until the file is opened using Event. // The program also uses Tkinter but I'm not sure that is relevant. I cannot submit the whole program as it is too big to submit. Aki- ---------- nosy: +akineko __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 21:51:11 2007 From: report at bugs.python.org (Koen van de Sande) Date: Fri, 31 Aug 2007 19:51:11 -0000 Subject: [issue1074] python3.0-config script does not run on py3k Message-ID: <1188589871.51.0.0440948032602.issue1074@psf.upfronthosting.co.za> New submission from Koen van de Sande: The python3.0-config script, installed into the py3k bin folder, does not run on Python 3.0a1, because of the syntax change in the "print" statement. Possibly there are other compatibility issues. ---------- components: None messages: 55538 nosy: koen severity: normal status: open title: python3.0-config script does not run on py3k versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 21:51:11 2007 From: report at bugs.python.org (Koen van de Sande) Date: Fri, 31 Aug 2007 19:51:11 -0000 Subject: [issue1074] python3.0-config script does not run on py3k Message-ID: <1188589871.51.0.0440948032602.issue1074@psf.upfronthosting.co.za> New submission from Koen van de Sande: The python3.0-config script, installed into the py3k bin folder, does not run on Python 3.0a1, because of the syntax change in the "print" statement. Possibly there are other compatibility issues. ---------- components: None messages: 55538 nosy: koen severity: normal status: open title: python3.0-config script does not run on py3k versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Aug 31 23:18:21 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 31 Aug 2007 21:18:21 -0000 Subject: [issue1075] py3k: Unicode error in os.stat on Windows Message-ID: <1188595101.9.0.193573207097.issue1075@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: os.stat("nonexistent") raises a UnicodeDecodeError on German, Polish and French Windowses. The reason: Windows returns an error message which contains accented letters encoded as MBCS, but python decodes it with utf-8. This patch uses the Unicode version of FormatMessageW to get the unicode string directly. ---------- files: errors.diff messages: 55539 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: Unicode error in os.stat on Windows __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: errors.diff Type: application/octet-stream Size: 4575 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/58118052/attachment.obj From report at bugs.python.org Fri Aug 31 23:18:22 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 31 Aug 2007 21:18:22 -0000 Subject: [issue1075] py3k: Unicode error in os.stat on Windows Message-ID: <1188595101.9.0.193573207097.issue1075@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: os.stat("nonexistent") raises a UnicodeDecodeError on German, Polish and French Windowses. The reason: Windows returns an error message which contains accented letters encoded as MBCS, but python decodes it with utf-8. This patch uses the Unicode version of FormatMessageW to get the unicode string directly. ---------- files: errors.diff messages: 55539 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: Unicode error in os.stat on Windows __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: errors.diff Type: application/octet-stream Size: 4575 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/58118052/attachment-0001.obj From report at bugs.python.org Fri Aug 31 23:42:59 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 31 Aug 2007 21:42:59 -0000 Subject: [issue1076] py3 patch: full Unicode version for winreg module Message-ID: <1188596579.64.0.260721438431.issue1076@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: With this patch, the winreg module is now completely unicode: it only uses Windows wide-char API functions, and all strings (keys, subkeys, values) are passed untranslated. str8 is banned, and byte objects are only allowed for raw binary data. Note: It seems a good approach to use the wide-char Windows API whenever possible. They fit very well with PyUnicode strings, and simplify the code... ---------- components: Unicode files: winreg.diff messages: 55540 nosy: amaury.forgeotdarc severity: normal status: open title: py3 patch: full Unicode version for winreg module versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: winreg.diff Type: application/octet-stream Size: 21812 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/a4068796/attachment-0001.obj From report at bugs.python.org Fri Aug 31 23:42:59 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 31 Aug 2007 21:42:59 -0000 Subject: [issue1076] py3 patch: full Unicode version for winreg module Message-ID: <1188596579.64.0.260721438431.issue1076@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: With this patch, the winreg module is now completely unicode: it only uses Windows wide-char API functions, and all strings (keys, subkeys, values) are passed untranslated. str8 is banned, and byte objects are only allowed for raw binary data. Note: It seems a good approach to use the wide-char Windows API whenever possible. They fit very well with PyUnicode strings, and simplify the code... ---------- components: Unicode files: winreg.diff messages: 55540 nosy: amaury.forgeotdarc severity: normal status: open title: py3 patch: full Unicode version for winreg module versions: Python 3.0 __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: winreg.diff Type: application/octet-stream Size: 21812 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20070831/a4068796/attachment-0003.obj