[docs] [issue19622] Default buffering for input and output pipes in subprocess module

Martin Panter report at bugs.python.org
Thu Oct 2 04:07:56 CEST 2014

Martin Panter added the comment:

I agree that it is misleading to say it matches Python 2 behaviour, as I said in my original post. Do you think I should reopen this and get that bit removed from the documentation?

I don’t see an easy way to make the behaviour consistent in all cases. My understanding is Python 2 always defaulted to unbuffered pipe readers and writers, but they were always “greedy”, meaning the read() and write() methods only succeed after transferring all the data. This is basically the API for BufferedIOBase.read() and BufferedIOBase.write(). In Python 3, unbuffered pipe readers and writers implement the RawIOBase API and may succeed before all the data is transfered.

If you really wanted to change the behaviour to be consistent with Python 2, you could make Popen always return BufferedIOBase pipes (unless universal_newlines=True). But BufferedReader and BufferedWriter don’t seem to accept buffer_size=0. For a pipe reader, maybe BufferedReader(buffer_size=1) would work, but you would either have to hack the BufferedWriter class, or implement a new GreedyWriter class. However I suspect this would introduce deadlocks in programs that access more than one pipe at once (probably also a problem in Python 2).

Perhaps the best thing is to document the problems and then explicitly pass in whatever “bufsize” value is appropriate for your usage.


Python tracker <report at bugs.python.org>

More information about the docs mailing list