Fergus Henderson <fergus.hender...@gmail.com> added the comment:
The spawn change (the last hunk of the original patch) is a bug fix, not
an RFE.
It has two parts that fix two bugs:
(1) a coding bug: spawn() would not wait for the invoked process to
finish. This is fixed by the line that adds the call to os.waitpid().
(2) a design bug: because previously spawn() didn't return a value,
there is no way to tell if the invoked process failed. This is fixed by
the "return status" line.
Now I guess you can argue that (2) is an RFE.
But (1) is just a bug fix, not an RFE, IMHO.
Those are both separate from the other bug fixed in the patch:
(3) Another coding bug: the bug in the _copy() loop that caused
it to spin using 100% CPU rather than blocking
It's a little tricky to write a test of the _copy() loop bug, for
several reasons.
(a) There currently isn't any test for pty.spawn, apparently since
"Cannot do extensive 'do or fail' testing because pty code is not too
portable."
(b) Also, for this bug the symptom is just that the code spins (using
100% CPU, if available) rather than blocking. It's difficult to detect
that situation using portable code.
I can maybe figure out how deal with (a), but I'm not sure how to
address (b), especially since I don't know the intended portability goals.
I will split the patch up into two patches, one of which addresses
(1)+(2), and the other of which addresses (3).
I have addressed Guilherme Polo's suggestion about using "if not data".
----------
Added file: http://bugs.python.org/file14148/pty.py.patch3
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2489>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
