[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-11-26 Thread Martin Panter
Martin Panter added the comment: For the record, this issue seemed to forget about the effect of buffering the pipe to the subprocess’s input stream. Buffering an input pipe means that data is hidden away until it is flushed, and the close() method can raise a broken pipe error. I have

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Georg Brandl
Georg Brandl added the comment: Considering that this behavior has been present in all of Python 3, it does not seem useful to make a backwards incompatible change in bugfix releases. You could change it in 3.4 as a minor API change, but you've indicated that that wouldn't make sense to you.

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Gregory P. Smith
Gregory P. Smith added the comment: The number of things we'll break by changing this errant behavior to be _correct_ is way less than the number of things that are already broken due to it. If the bufsize=0 default is left in place the behavior differs between Windows and POSIX platforms

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Gregory P. Smith
Gregory P. Smith added the comment: (actually I'm not sure about the windows vs posix behavior difference, that may not be true; I don't have a windows system handy to test that on) -- ___ Python tracker rep...@bugs.python.org

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Georg Brandl
Georg Brandl added the comment: OK. That was a more passionate statement :) It would actually be nice to know about Windows, but the way you describe it is that the default behavior now is quite useless. Does bufsize=0 have any sensible use on Python 3? Anyway, you've convinced me -- can

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Gregory P. Smith
Gregory P. Smith added the comment: great! fixing now. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17488 ___ ___ Python-bugs-list mailing

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Roundup Robot
Roundup Robot added the comment: New changeset 3ecf709dfe69 by Gregory P. Smith in branch '3.2': Fixes issue #17488: Change the subprocess.Popen bufsize parameter default value http://hg.python.org/cpython/rev/3ecf709dfe69 New changeset 4c2fc172afcc by Gregory P. Smith in branch '3.3': Fixes

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-23 Thread Gregory P. Smith
Changes by Gregory P. Smith g...@krypto.org: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17488 ___

[issue17488] subprocess.Popen bufsize=0 parameter behaves differently in Python 3 than in 2

2013-03-19 Thread Gregory P. Smith
New submission from Gregory P. Smith: The subprocess module in Python 3 uses io.open(file_descriptor, mode, bufsize) to create its Popen stdout, stderr and stdin file objects. In Python 2, it used the old os.fdopen which created an old-style python 2 file object that simply wraps libc's FILE*