Mike Meyer <mwm <at> mired.org> writes: > Since the only reason they exist is so you can access your end of a > pipe, setting them to anything would seem to be a bug. I'd argue that > their existence is more a pola violation than them having the value > None. But None is easier than a call to hasattr.
I don't follow your reasoning, re. why setting them to a handle used for subprocess output would be a bug - it's logically the same as the PIPE case. For example, I might have a pipe (say, constructed using os.pipe()) whose write end is intended for the subprocess to output to, and whose read end I want to hand off to some other code to read the output from the subprocess. However, if that other code does a read() on that pipe, it will hang until the write handle for the pipe is closed. So, once the subprocess has terminated, I need to close the write handle. The actual reading might be done not in my code but in some client code of my code. While I could use some other place to store it, where's the problem in storing it in proc.stdout or proc.stderr? > You can close the object you passed in if it wasn't PIPE. If you > passed in PIPE, the object has to be exposed some way, otherwise you > *can't* close it. Yes, I'm not disputing that I need to keep track of it - just that proc.stdout seems a good place to keep it. That way, the closing code can be de-coupled from the code that sets up the subprocess. A use case for this is when you want the subprocess and the parent to run concurrently/asynchronously, so the proc.wait() and subsequent processing happens at a different time and place to the kick-off. Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com