Inquiry regarding the name of subprocess.Popen class

[Derek Martin]

On Wed, Sep 03, 2008 at 12:20:18AM -0400, Miles wrote:
> Derek Martin wrote:
> > On Tue, Sep 02, 2008 at 10:55:54PM +0000, Marc 'BlackJack' Rintsch wrote:
> >> but the instances of `Popen` are no actions.  There's no way to
> >> "execute" a `Popen` instance.
> >
> > Yes there is... you execute it when you instantiate the object.  At
> > the time of instantiation, you "open" the "P" (pipes).
> 
> The subprocess module is also supposed to replace os.system and
> os.spawn*, neither of which involve opening pipes. 

Sigh... wasn't finished, sent by accident.  Anyway, to continue...

The subprocess module also can be used to replace these two functions,
though to be honest, it's not clear to me why one would do so.   On
the whole, I choose not to use the subprocess module because I find it
tedious, and less tedious interfaces (like os.system() and os.popen(),
and even the popen2 module) exist.  [But, you can probably guess that
I write code almost exclusively for POSIX-ish systems...]  If all you
want is the equivalent of os.system() or os.spawn(), then it seems to
me the subprocess module is overly heavy-handed, leaving a bunch of
not useful state laying around in your environment...  Not to mention
you probably already need the os module, so you could save yourself
the trouble and overhead of importing subprocess.

> All rationalizations aside, I think Popen is a poor name for the
> class.  

Even within this thread, a number of people clearly disagree with you. 
To say nothing of the maintainers... :)

I really think it's not worse (and actually better) than "process"...
for reasons I already explained.  The argument that the object is a
process is spurious.  The object is, in actuality, an instance of
*COMMUNICATION* between two processes.  It's true that a process is
started as a result, so that the first process has a second to be able
to communicate with; and a (tiny) bit of information (the PID) is
maintained about that process, mostly for no useful reason...  However
the object mainly is a collection of pipes, and some methods for
communicating over them, to another process that, out of necessity
just happens to be a child of the current one. 

If you think about what the methods do, and understand how they
actually work, I think it will become clear that this is the case.
Does communicate() operate on the process?  ABSOLUTELY NOT -- it
operates on the pipes.  poll() and wait() may arguably act upon the
process (they actually request information about the process from the
kernel), but the goal in doing so is to find out the status of the
communication: is it done, and if so was it successful?  If you
abstract the concept from its implementation, this is clearly true.  

I could concede that it may not be clear to someone unfamiliar with C
programming (perhaps especially in a Unix environment, though Windows
does have a similar, but apparently broken function) what "popen"
means or does, but the manual has ample references to explain that, I
think.  It's no less clear than the popen() function itself!

> But I would imagine the odds of it ever being changed are miniscule
> (Python 4?).

The truth is, in the end, I personally don't really care; though if it
were changed, I would hope something genuinely better were chosen.  I
feel strongly that "process" ain't it.  My motivation in posting in
this thread is mostly to point out how silly it is to argue or
complain about the name of some bit of logic in a programming
language, especially once it's already been released (though I doubt
most of the participants got the point).  The time to do this is when
the feature is in the planning stages, if ever...  Some people take
this stuff way, way too seriously, and also can't seem to imagine that
another perspective besides their own exists, and especially that
their own might just not be optimal/correct.  

Posting to Usenet/maling lists and saying "Why is X called X?  It
should be called Y!" is not likely to ever produce any sort of useful
result. ;-)

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20080903/f8967309/attachment-0001.sig>