[issue11459] Python select.select does not correctly report read readyness

Antoine Pitrou added the comment: Fixed now, thank you! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 ___ Python tracker __

[issue11459] Python select.select does not correctly report read readyness

Roundup Robot added the comment: New changeset 1dc52ecb8949 by Antoine Pitrou in branch '3.1': Issue #11459: A `bufsize` value of 0 in subprocess.Popen() really creates http://hg.python.org/cpython/rev/1dc52ecb8949 New changeset 7451da272111 by Antoine Pitrou in branch '3.2': Issue #11459: A `b

[issue11459] Python select.select does not correctly report read readyness

Antoine Pitrou added the comment: Here is the adapted patch for 3.1, with a test case. -- nosy: +pitrou Added file: http://bugs.python.org/file21291/11459_v3.patch ___ Python tracker __

[issue11459] Python select.select does not correctly report read readyness

Ross Lagerwall added the comment: Attached is a patch which uses -1 for the buffer size of popen(). This gets translated by the io.open() to the default io buffer size. -- Added file: http://bugs.python.org/file21290/11459_v2.patch ___ Python tracke

[issue11459] Python select.select does not correctly report read readyness

Gregory P. Smith added the comment: yeah i figured importing io from os at the top level might be a problem. it is not important for the default to be that exact value, even something safely on the small side like 512 will work. but we could just have the default be set in the code by doing

[issue11459] Python select.select does not correctly report read readyness

Novimir Pablant added the comment: I agree with Gregory that fixing this in 3.1 and 3.2 is the way to go. Otherwise I would suggest changing the documentation to match the behavior. -- ___ Python tracker ___

[issue11459] Python select.select does not correctly report read readyness

Ross Lagerwall added the comment: > to get that behavior, change the =1 default to =io.DEFAULT_BUFFER_SIZE in > ross's patch. The problem is, it doesn't seem like you can import and use io.DEFAULT_BUFFER_SIZE from inside os.py. Python fails to start. You can import _io.DEFAULT_BUFFER_SIZE th

[issue11459] Python select.select does not correctly report read readyness

Gregory P. Smith added the comment: to get that behavior, change the =1 default to =io.DEFAULT_BUFFER_SIZE in ross's patch. -- ___ Python tracker ___ __

[issue11459] Python select.select does not correctly report read readyness

Gregory P. Smith added the comment: ross's patch looks good to me. Isn't the behavior just plain broken in 3.1 and 3.2? The docs say that the default bufsize=0 is unbuffered in Popen but the implementation has that nasty XXX to make it line buffered instead of unbuffered in it. This appears

[issue11459] Python select.select does not correctly report read readyness

Changes by Antoine Pitrou : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue11459] Python select.select does not correctly report read readyness

Ross Lagerwall added the comment: The Charles' patch fixes the problem but breaks [test_os test_poll test_popen test_select test_uuid] when running make test. Those two lines were introduced by Guido in [1f7891d84d93] but that was back in 2007 when subprocess used os.fdopen and the new IO had

[issue11459] Python select.select does not correctly report read readyness

Novimir Pablant added the comment: Applying the patch appears to fix this problem. Thanks! I am definitely confused about why the buffer was changed to line buffered in the first place, especially since the default is bufsize=0 and the comment ("# Nearly unbuffered (XXX for now)") does not a

[issue11459] Python select.select does not correctly report read readyness

Changes by Ross Lagerwall : -- nosy: +rosslagerwall ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue11459] Python select.select does not correctly report read readyness

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue11459] Python select.select does not correctly report read readyness

Charles-Francois Natali added the comment: Could you try with the attached patch ? The problem is that subprocess silently replaces bufsize=0, so child.stdout is actually buffered, and when you read just one byte, everything that's available for reading is read into the python's object buffer.

[issue11459] Python select.select does not correctly report read readyness

Novimir Pablant added the comment: I forgot to mention, I am running on OS X 10.6.6. -- ___ Python tracker ___ ___ Python-bugs-list m

[issue11459] Python select.select does not correctly report read readyness

New submission from Novimir Pablant : I am trying to get the output from an external program into python using `subprocess.Popen` and `select.select`. For some reason though select.select is at times telling me that stdout is not ready to read, even when it is (reading from it works). Th