On Sun, 8 Jan 2012 02:06:33 +0000 (UTC)
Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> 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.
No, it isn't. In the PIPE case, the value of the attributes isn't
otherwise available to the caller.
I think you're not following because you're thinking about what you
want to do with the attributes:
> storing it [the fd] in proc.stdout or proc.stderr?
As opposed to what they're used for, which is communicating the fd's
created in the PIPE case to the caller. Would you feel the same way
if they were given the more accurate names "pipe_input" and
"pipe_output"?
> > 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.
I disagree. Having the proc object keep track of these things for you
is making it more complicated (by the admittedly trivial change of
assigning those two attributes when they aren't used) so you can make
your process creation code less complicated (by the equally trivial
change of assigning the values in those two attributes when they are
used). Since only the caller knows when this complication is needed,
that's the logical place to put it.
> That way, the closing code can be de-coupled from the code that sets
> up the subprocess.
There are other ways to do that. It's still the same tradeoff - you're
making the proc code more complicated to make the calling code
simpler, even though only the calling code knows if that's needed.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
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
