Re: [Python-Dev] Implementing File Modes

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@xxxxxxxxx> wrote:

2009/7/27 Eric Pruitt <eric.pruitt@xxxxxxxxx>:

> 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.

_______________________________________________
Python-Dev mailing list
Python-Dev@xxxxxxxxxx
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/maillists%40codeha.us