> On Tue, 28 Jul 2009 04:06:45 am Eric Pruitt wrote:
> > I am implementing the file wrapper using changes to subprocess.Popen
> > that also make it asynchronous and non-blocking so implementing "r+"
> > should be trivial to do. How about handling stderr? I have the
> > following ideas: leave out support for reading from stderr, make it
> > so that there is an optional additional argument like "outputstderr =
> > False", create another function that toggles / sets whether stderr or
> > stdout is returned or mix the two outputs.
>
> Leaving it out is always an option.
>
> As I see it, fundamentally you can either read from stdout and sterr as
> two different streams, or you can interleave (mix) them. To me, that
> suggests three functions:
>
> ProcessIOWrapper() # read from stdout (or write to stdin etc.)
> ProcessIOWrapperStdErr() # read/write from stderr
> ProcessIOWrapper2() # read from mixed stdout and stderr
>
> I don't like a function to toggle between one and the other: that smacks
> of relying on a global setting in a bad way. I suppose you could add an
> optional argument to ProcessIOWrapper() to select between stdout,
> stderr, or both together.
>
>
>
> --
> Steven D'Aprano
How would having a toggle function rely on a global setting? Each class would
simply have its own member variable like "self.readsstderr." It's a moot point
though as I've decided to use separate functions as you suggested. With
separate functions, the user doesn't have to worry about modifying the mode
keyword if stderr is needed and as an added bonus, it also makes the code
a lot more readable.
Eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
