[Python-Dev] Implementing File Modes

[Eric Pruitt]

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.

Thanks for the input,
Eric

On Mon, Jul 27, 2009 at 10:46, Paul Moore <p.f.moore at gmail.com> wrote:

> 2009/7/27 Eric Pruitt <eric.pruitt at gmail.com>:
> > Hello,
> >
> > Since there was a bit of confusion last time, I'll start by saying I am
> > working on the subprocess.Popen module for Google Summer of Code. One of
> the
> > features I am implementing is a class so that a running process can stand
> in
> > in place of a file. For examples, instead of open( "filelist", mode =
> 'r')
> > one would call ProcessIOWrapper( "ls -l", mode = 'r'). I am trying to
> decide
> > if I should fully implement the mode argument. Right now, it essentially
> > ignores everything but a 'U' indicated universal newlines in the mode
> > argument. Should I leave that as is or make it so that things like "r+",
> > "w", "a" are handled the way they would be for an actual file?
>
> I would expect "r" to produce a pipe that reads from stdout of the
> subprocess, and "w" to produce a pipe that writes to stdin of the
> subprocess. "a" would be the same as "w", and arguably "r+" would be a
> bidirectional pipe - read from the subprocess stdout and write to its
> stdin.
>
> I'd be OK with "r+" not being implemented (if it's too hard to avoid
> deadlocks) but "r" and "w" should be present.
>
> Paul.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090727/3ba61afc/attachment.htm>