[ python-Bugs-1456609 ] PEP Links broken on new website
Bugs item #1456609, was opened at 2006-03-23 01:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: PEP Links broken on new website Initial Comment: The links genereated are in the form: http://www.python.org/dev/peps/pep-0340/pep-0288.html when they should be: http://www.python.org/dev/peps/pep-0288/ -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-23 08:02 Message: Logged In: YES user_id=849994 The pydotorg website has its own tracker. Please look at http://psf.pollenation.net/cgi-bin/trac.cgi/report/1 whether this problem is already reported and if not, please open a ticket there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 07:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Taale Skogan (tskogan) >Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-998246 ] Popen3.poll race condition
Bugs item #998246, was opened at 2004-07-26 12:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) >Assigned to: Neal Norwitz (nnorwitz) Summary: Popen3.poll race condition Initial Comment: poll() swallows all IOErrors, including ENOCHILD; if the child process exits before poll is called, then an applications which loops on poll() will never exit. I am working around this (against Python 2.3.3) via the following: try: pid, status = os.waitpid(proc.pid, os.WNOHANG) except os.error, e: if e.errno == 10: # ENOCHILD result = 0 else: raise else: if pid == proc.pid: result = status where 'proc' is an instance of Popen3. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:45 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-892939 ] Race condition in popen2
Bugs item #892939, was opened at 2004-02-08 09:31 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Ken McNeil (kenmcneil) >Assigned to: Neal Norwitz (nnorwitz) Summary: Race condition in popen2 Initial Comment: The "fix" for bug #761888 created a race condition in Popen3 . The interaction between wait and _cleanup is the root of the problem. def wait(self): """Wait for and return the exit status of the child process.""" if self.sts < 0: pid, sts = os.waitpid(self.pid, 0) if pid == self.pid: self.sts = sts return self.sts def _cleanup(): for inst in _active[:]: inst.poll() In wait, between the check of self.sts and the call to os.waitpid a new Popen3 object can be created in another thread which will trigger a call to _cleanup. Since the call to _cleanup polls the process, when the thread running wait starts back up again it will try to poll the process using os.waitpid, which will throw an OSError because os.waitpid has already been called for the PID indirectly in _cleanup. A work around is for the caller of wait to catch the OSError and check the sts field, and if sts is non-negative then the OSError is most likely because of this problem and can be ignored. However, sts is undocumented and should probably stay that way. My suggestion is that the patch that added _active, _cleanup, and all be removed and a more suitable mechanism for fixing bug #761888 be found. As it has been said in the discussion of bug #761888, magically closing FDs is not a "good thing". It seems to me that surrounding the call to os.fork with a try/except, and closing the pipes in the except, would be suitable but I don't know how this would interact with a failed call to fork, therefore I wont provide a patch. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:47 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-886492 ] Python 2.2.3 crashes using popen2 to spawn lots of children
Bugs item #886492, was opened at 2004-01-28 12:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470 Please note that this 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.2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Frank Terhaar-Yonkers (frankty) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.2.3 crashes using popen2 to spawn lots of children Initial Comment: WinPython 2.3.3 crashes when using popen2 to spawn *lots* of children > 100. Running the test case on either W2k or Wxp causes Python 2.3.3 to crash. Looking at the drwatson file, it appears to be a race condition where the child is in the process of crashing, while the popen2 code in posixmodule.c is attempting to PyFile_SetBufSize() on one of the pipes. Evil juju in ntdll.dll .. I've no idea what system resource is being exhausted (heap memory?) causing the crash. If you look at the hacks in posixmodule.c, the Python crash can be eliminated by simply commenting out the calls to PyFile_SetBufSize. There is still the problem of resource exhaustion. To gain more child processes I included a hack such that with the setting of an env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run a child, but simply run the child command as passed (yeah, I know that is has to be an absolute path or in the CWD then ..). I'm sure there is a better way to eliminate the cmd.exe /c - like maybe a new method: popen2.popenXabspath .. In any case, it appears we have an NT kernel bug combined with an inefficient way of doing popen2 that is making a mess. I started doing some exploration of heap_chunk_size to attack to resource issue but haven't gotten very far. As for *why* I'm doing this, it's because we're using Pyton as a system simulator tool to emulate a large pile of PCs. The actual work *must* be done by external .exe code that cannot be changed. The attached zip contains a test case, the posixmodule hack, drwatson file and a sample program written in VisC++ which does basically the same as the Python test case. cheers, - Frank -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:50 Message: Logged In: YES user_id=33168 Dupe of 886488 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456775 ] round not rounding correctly
Bugs item #1456775, was opened at 2006-03-23 09:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Norbert Sebok (seboknorbi) Assigned to: Nobody/Anonymous (nobody) Summary: round not rounding correctly Initial Comment: For example: print 72.805, round(72.805,2) print 72.815, round(72.815,2) print 72.825, round(72.825,2) print 72.835, round(72.835,2) print 72.845, round(72.845,2) print 72.855, round(72.855,2) print 72.865, round(72.865,2) print 72.875, round(72.875,2) print 72.885, round(72.885,2) print 72.895, round(72.895,2) The results: 72.805 72.81 72.815 72.82 72.825 72.83 72.835 72.83 !!! not 72.84 72.845 72.85 72.855 72.86 72.865 72.86 !!! not 72.87 72.875 72.88 72.885 72.89 72.895 72.9 The problem seems to exists with numbers ending with 5. Another examples: round(0.015,2) == 0.01 != 0.02 round(0.045,2) == 0.04 != 0.05 round(0.075,2) == 0.07 != 0.08 round(0.105,2) == 0.1 != 0.11 round(0.145,2) == 0.14 != 0.15 round(0.155,2) == 0.15 != 0.16 round(0.175,2) == 0.17 != 0.18 round(0.185,2) == 0.18 != 0.19 round(0.205,2) == 0.2 != 0.21 round(0.215,2) == 0.21 != 0.22 round(0.235,2) == 0.23 != 0.24 round(0.245,2) == 0.24 != 0.25 round(0.285,2) == 0.28 != 0.29 round(0.295,2) == 0.29 != 0.3 round(0.305,2) == 0.3 != 0.31 round(0.345,2) == 0.34 != 0.35 It's the same on Linux and Win32. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456775 ] round not rounding correctly
Bugs item #1456775, was opened at 2006-03-23 08:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Norbert Sebok (seboknorbi) Assigned to: Nobody/Anonymous (nobody) Summary: round not rounding correctly Initial Comment: For example: print 72.805, round(72.805,2) print 72.815, round(72.815,2) print 72.825, round(72.825,2) print 72.835, round(72.835,2) print 72.845, round(72.845,2) print 72.855, round(72.855,2) print 72.865, round(72.865,2) print 72.875, round(72.875,2) print 72.885, round(72.885,2) print 72.895, round(72.895,2) The results: 72.805 72.81 72.815 72.82 72.825 72.83 72.835 72.83 !!! not 72.84 72.845 72.85 72.855 72.86 72.865 72.86 !!! not 72.87 72.875 72.88 72.885 72.89 72.895 72.9 The problem seems to exists with numbers ending with 5. Another examples: round(0.015,2) == 0.01 != 0.02 round(0.045,2) == 0.04 != 0.05 round(0.075,2) == 0.07 != 0.08 round(0.105,2) == 0.1 != 0.11 round(0.145,2) == 0.14 != 0.15 round(0.155,2) == 0.15 != 0.16 round(0.175,2) == 0.17 != 0.18 round(0.185,2) == 0.18 != 0.19 round(0.205,2) == 0.2 != 0.21 round(0.215,2) == 0.21 != 0.22 round(0.235,2) == 0.23 != 0.24 round(0.245,2) == 0.24 != 0.25 round(0.285,2) == 0.28 != 0.29 round(0.295,2) == 0.29 != 0.3 round(0.305,2) == 0.3 != 0.31 round(0.345,2) == 0.34 != 0.35 It's the same on Linux and Win32. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-23 09:33 Message: Logged In: YES user_id=849994 Actually: >>> 72.835 72.8349994 >>> This is due to the computer's internal floating point representation, which is not decimal, but binary. So round() behaves correctly. See http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate for more information. If you need these calculations to be exact, use Decimals, available in the decimal module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456775&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Bugs item #1456470, was opened at 2006-03-22 22:06 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 Please note that this 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: 6 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Martin v. Löwis (loewis) Summary: sliceobject ssize_t (and index) not completed Initial Comment: sliceobject and ceval changed the parameter types of slice objects to ssize_t, but the code still requires an int (sometimes not even a long); it should use the new __index__ slot; at the very least, it should be consistent about what it does accept. In http://svn.python.org/view/python/trunk/Objects/ sliceobject.c?rev=42382&view=markup [issue 1] function PySlice_GetIndices takes Py_ssize_t parameters for (length, start, stop, step) but then does a PyInt_Check on each of start, stop, step. (An XXX to allow longs was also removed.) It * should* use the new __index__ slot. [issue 2] Later in the same file, function slice_ indices takes a PyObject len parameter, but then uses PyInt_AsLong rather than __index__ (or even PyInt_ AsSsize_t) to create Py_ssize_t ilen. [issue 3] http://svn.python.org/view/python/trunk/Python/ceval.c? rev=42382&view=markup function _PyEval_SliceIndex accepts only ints and longs, and longs will be converted to ints with clipping. It should allow anything with __index__, and clip only to ssize_t rather than int. [issue 4] ISINT still insists on int or long -- I thought I saw a fix for this already in the index patches. [issue 5] apply_slice and assign_slice changed the types of ilow and ihigh, but still initializes them to INT_MAX rather than ssize_t max. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-998246 ] Popen3.poll race condition
Bugs item #998246, was opened at 2004-07-26 15:14 Message generated for change (Comment added) made by tseaver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen3.poll race condition Initial Comment: poll() swallows all IOErrors, including ENOCHILD; if the child process exits before poll is called, then an applications which loops on poll() will never exit. I am working around this (against Python 2.3.3) via the following: try: pid, status = os.waitpid(proc.pid, os.WNOHANG) except os.error, e: if e.errno == 10: # ENOCHILD result = 0 else: raise else: if pid == proc.pid: result = status where 'proc' is an instance of Popen3. -- >Comment By: Tres Seaver (tseaver) Date: 2006-03-23 07:21 Message: Logged In: YES user_id=127625 1183780 is indeed a similar bug, although he reports it against Popen4 rather than Popen3. His patch needs to be modified to re-raise errors which are not ENOCHILD, however. I no longer have accees to either the application or the machine where I found this issue, and hence can't verify that the patch fixes the code which triggered the problem. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 03:45 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457119 ] Unifying pickle and cPickle exception class hierarchies
Bugs item #1457119, was opened at 2006-03-23 19:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unifying pickle and cPickle exception class hierarchies
Initial Comment:
Should the pickle and cPickle exception class
hierarchies be unified? Perhaps just subclass one
grandparent PickleError class? That way module copy_reg
can throw exceptions from this hierarchy.
Here's the experience that led to the thought:
(1) confusing exception types when a class can't be pickled
When an object can't be pickled, sometimes a TypeError
is raised, and sometimes an exception derived from
pickle.PickleError or cPickle.PickleError, a screenshot
is pasted below.
(2) copy_reg raises TypeError
When a pickle-related exception occurs in copy_reg, a
TypeError is raised, e.g. in line 69:
raise TypeError, "can't pickle %s objects" % base.__name__
but if copy_reg wants to raise an exception from the
pickle module's hierarchy...
(3) copy_reg doesn't know if pickle or cPickle are used
It can't choose between the two, therefore it chooses
TypeError.
=== screenshot ===
>>> import sys, pickle, cPickle
>>> try: raise RuntimeError
... except: tb = sys.exc_info()[-1]
...
>>> frame = tb.tb_frame
>>> pickle.dumps(frame)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/pickle.py", line 1386, in dumps
Pickler(file, protocol, bin).dump(obj)
File "/usr/lib/python2.4/pickle.py", line 231, in dump
self.save(obj)
File "/usr/lib/python2.4/pickle.py", line 313, in save
rv = reduce(self.proto)
File "/usr/lib/python2.4/copy_reg.py", line 69, in
_reduce_ex
raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle frame objects
>>> cPickle.dumps(frame)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/copy_reg.py", line 69, in
_reduce_ex
raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle frame objects
>>> pickle.dumps(tb)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/pickle.py", line 1386, in dumps
Pickler(file, protocol, bin).dump(obj)
File "/usr/lib/python2.4/pickle.py", line 231, in dump
self.save(obj)
File "/usr/lib/python2.4/pickle.py", line 319, in save
raise PicklingError("Can't pickle %r object: %r" %
pickle.PicklingError: Can't pickle 'traceback' object:
>>> cPickle.dumps(tb)
Traceback (most recent call last):
File "", line 1, in ?
cPickle.UnpickleableError: Cannot pickle objects
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457264 ] urllib.splithost parses incorrectly
Bugs item #1457264, was opened at 2006-03-23 20: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=1457264&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve (onlynone)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.splithost parses incorrectly
Initial Comment:
urllib.splithost(url) requires that the url passed in
be of the form '//host[:port]/path'. Yet I've run
across some urls that are of the form
'//host[:port]?querystring'. This causes splithost to
return everything as the host and nothing as the path.
Section 3.2 of rfc2396 (Uniform Resource Identifiers:
Generic Syntax) states that 'The authority component is
preceded by a double slash "//" and is terminated by
the next slash "/", question-mark "?", or by the end of
the URI.'
Also, this is how it defines a URI:
absoluteURI = scheme ":" ( hier_part | opaque_part )
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
Based on the above, you could certainly have:
'http://authority?query' as a valid url.
In python2.3 you would just need to change line 939 in
urllib.py from:
_hostprog = re.compile('^//([^/]*)(.*)$')
to:
_hostprog = re.compile('^//([^/?]*)(.*)$')
This appears to affect all python versions, I just
happened to be using 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457264&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457312 ] AttributeError in upload_file on interrupted connection
Bugs item #1457312, was opened at 2006-03-23 22:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError in upload_file on interrupted connection Initial Comment: I got the following error when my network interface went down while I was uploading a file to PyPI: - Traceback (most recent call last): File "setup.py", line 109, in ? classifiers = [ File "/usr/lib64/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib64/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib64/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib64/python2.4/site-packages/setuptools-0.6a10-py2.4.egg/setuptools/command/upload.py", line 65, in run self.upload_file(command, pyversion, filename) File "/usr/lib64/python2.4/site-packages/setuptools-0.6a10-py2.4.egg/setuptools/command/upload.py", line 158, in upload_file self.announce(e.msg, log.ERROR) AttributeError: error instance has no attribute 'msg' - I was told that these setuptools files were copied from Py2.5 distutils, that's why I'm reporting the error here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457312&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457358 ] floor division not documented
Bugs item #1457358, was opened at 2006-03-23 23: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=1457358&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: floor division not documented Initial Comment: In chapter 2.3.4 of the Lib Reference (2.3.4 Numeric Types -- int, float, long, complex), the floor division operator (//) is missing. It is only referred to in the explanation of the divmod operator, but without explaining the meaning of // itself. I think it would be good to make the // operator more popular, so people can start to make their code future proof. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457358 ] floor division not documented
Bugs item #1457358, was opened at 2006-03-23 23:36 Message generated for change (Settings changed) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None >Priority: 3 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: floor division not documented Initial Comment: In chapter 2.3.4 of the Lib Reference (2.3.4 Numeric Types -- int, float, long, complex), the floor division operator (//) is missing. It is only referred to in the explanation of the divmod operator, but without explaining the meaning of // itself. I think it would be good to make the // operator more popular, so people can start to make their code future proof. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457358&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457411 ] byext.py errors
Bugs item #1457411, was opened at 2006-03-23 23:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Lowery (jlowery2006)
Assigned to: Nobody/Anonymous (nobody)
Summary: byext.py errors
Initial Comment:
statdir() method make reference to undefined 'ext'
variable:
def statdir(self, dir):
self.addstats("", "dirs", 1)
try:
names = os.listdir(dir)
except os.error, err:
sys.stderr.write("Can't list %s: %s\n" %
(file, err))
self.addstats(ext, "unlistable", 1)
return
names.sort()
...
also, a number of the error strings throughout the
program refer to 'file', which I believe is the built-
in (shouldn't it be the name of a parameter?).
This file is in the Tools/Scripts directory of the
Python install folder.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1455676 ] Simplify using Queues with consumer threads
Bugs item #1455676, was opened at 2006-03-21 16:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455676&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Simplify using Queues with consumer threads Initial Comment: When Queues are used to communicate between producer and consumer threads, there is often a need to determine when all of the enqueued tasks have been completed. With this small patch, determining when all work is done is as simple as adding q.task_done() to each consumer thread and q.join() to the main thread. Without the patch, the next best approach is to count the number of puts, create a second queue filled by the consumer when a task is done, and for the main thread to call successive blocking gets on the result queue until all of the puts have been accounted for: def worker(): while 1: task = tasks_in.get() do_work(task) tasks_out.put(None) tasks_in = Queue() tasks_out = Queue() for i in range(num_worker_threads): Thread(target=worker).start() n = 0 for elem in source(): n += 1 tasks_in.put(elem) # block until tasks are done for i in range(n): tasks_out.get() That approach is not complicated but it does entail more lines of code and tracking some auxiliary data. This becomes cumersome and error-prone when an app has multiple occurences of q.put() and q.get(). The patch essentially encapsulates this approach into two methods, making it effortless to use and easy to graft on to existing uses of Queue. So, the above code simplies to: def worker(): while 1: task = q.get() do_work(task) q.task_done() q = Queue() for i in range(num_worker_threads): Thread(target=worker).start() for elem in source(): q.put(elem) # block until tasks are done q.join() The put counting is automatic, there is no need for a separate queue object, the code readably expresses its intent with clarity. Also, it is easy to inpect for accuracy, each get() followed by a task_done(). The ease of inspection remains even when there are multiple gets and puts scattered through the code (a situtation which would become complicated for the two Queue approach). If accepted, will add docs with an example. Besides being a fast, lean, elegant solution, the other reason to accept the patch is that the underlying problem appears again and again, requiring some measure to invention to solve it each time. There are a number of approaches but none as simple, fast, or as broadly applicable as having the queue itself track items loaded and items completed. -- >Comment By: Tim Peters (tim_one) Date: 2006-03-23 19:17 Message: Logged In: YES user_id=31435 I marked this as Accepted, but there are some things I'd like to see changed: - A Condition is best named after the predicate it represents. So, e.g., instead of the generic "waiter", a better name would be "all_tasks_done". When you eventually .notify() the Condition, you're notifing its wait()er that "all tasks (may be) done", and "all tasks (may be) done" is what the wait()er is waiting _for_. "all_tasks_done.wait()" makes that much clearer than "waiter.wait()". - A Condition.wait() can be interrupted by (at least) KeyboardInterrupt, so the acquire/release around a Condition.wait() call should always be in a try/finally (so that the Condition is release()d no matter what). All other Condition.wait()s in Queue do protect themselves this way. I don't see a need for try/finally around other uses, except possibly that: - Given the intended semantics, it would be good to raise an exception if .unfinished_tasks becomes negative; i.e., make it a detected programmer error if task_done() is called "too often" (although again the Condition needs to be release()d no matter what, and a try/finally may be expedient toward that end). - Since any number of threads _may_ be waiting in Queue.join(), yes, .notifyAll() is better. The other conditions in Queue don't do that because there's a key difference: at most one thread waiting on not_full or not_empty can make progress when one of those is "signaled", so it would be wasteful to wake up more than one thread waiting on those. In contrast, all threads waiting on .waiter can make progress when all tasks are in fact done. You can do that with a notifyAll() in task_done(), or by adding a notify() near the
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 09:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457470 ] regs attribute on regex objects not documented
Bugs item #1457470, was opened at 2006-03-24 01:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Lowery (jlowery2006) Assigned to: Nobody/Anonymous (nobody) Summary: regs attribute on regex objects not documented Initial Comment: Came across the use of .regs attribute in the tools/scripts/classfix.py program (line 162), but it's not an attribute that's documented in the Python Library Reference. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 07:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 21:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-23 16:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 00:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457411 ] byext.py errors
Bugs item #1457411, was opened at 2006-03-23 15:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeff Lowery (jlowery2006)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: byext.py errors
Initial Comment:
statdir() method make reference to undefined 'ext'
variable:
def statdir(self, dir):
self.addstats("", "dirs", 1)
try:
names = os.listdir(dir)
except os.error, err:
sys.stderr.write("Can't list %s: %s\n" %
(file, err))
self.addstats(ext, "unlistable", 1)
return
names.sort()
...
also, a number of the error strings throughout the
program refer to 'file', which I believe is the built-
in (shouldn't it be the name of a parameter?).
This file is in the Tools/Scripts directory of the
Python install folder.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-23 21:42
Message:
Logged In: YES
user_id=33168
Thanks!
Committed revision 43269.
Committed revision 43270. (2.4)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 06:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 01:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 09:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 07:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this message 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: Accepted Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 23:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-23 23:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 21:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-23 16:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), a
