Showing content from http://mail.python.org/pipermail/python-dev/attachments/20090727/34b5c7ff/attachment.htm below:
<div class="gmail_quote">On Mon, Jul 27, 2009 at 3:04 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I like MRAB's idea of using a (non-standard) "e" flag to include<br>
stderr. So "r" reads from stdout, "re" reads from stdout+stderr.<br>
<br>
Anything more complicated probably should just use "raw" Popen<br>
objects. Don't overcomplicate the interface.<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>In my opinion, mangling stderr and stdout together is already an overcomplication. It shouldn't be implemented.<br><br>It <i>seems</i> like a good idea, until you realize that subtle changes to your OS, environment, or buffering behavior may result in arbitrary, unparseable output.<br>
<br>For example, let's say you've got a program whose output is a list of lines, each one containing a number. Sometimes it tries to import gtk, and fails to open its display.<br><br>That's fine, and you can still deal with it, as long as the interleaved output looks like this:<br>
<br><div style="margin-left: 40px;">100<br>200<br>Gtk-WARNING **: cannot open display:<br>300<br>400<br></div><br>but of course the output <i>might</i> (although unlikely with such small chunks of output) end up looking like this, instead:<br>
<br><div style="margin-left: 40px;">100<br>2Gtk-WAR0NING0 **:<br>can30not 0open display:<br><br>400<br></div><br>this is the sort of thing which is much more likely to happen once you start dealing with large volumes of data, where there are more page-boundaries for your buffers to get confused around, and you are playing with buffering options to improve performance. In other words, it's something that fails only at scale or under load, and is therefore extremely difficult to debug.<br>
<br>This option <i>might</i> be okay if it were allowed only on subprocesses opened in a <i>text</i> mode, and if the buffering logic involved forced stderr and stdout to be line-delimited, and interleave only lines, rather than arbitrary chunks of bytes. Of course then if you use this flag with a program that outputs binary data with no newlines it will buffer forever and crash your program with a MemoryError, but at least that's easy to debug when it happens.<br>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4