Inquiry regarding the name of subprocess.Popen class

[Derek Martin]

On Tue, Sep 02, 2008 at 06:47:39PM +0000, Marc 'BlackJack' Rintsch wrote:
> That's why I think the name `Popen` is not so good for it.  Because it 
> does more than `popen()` and if it is called `Subprocess` or just 
> `Process` then it would be merely an implementation detail, that the 
> `popen()` function is called at some point.  

The module is subprocess, and the class is Popen.  The underlying
implementation doesn't really matter; the class still does essentally
the same as the combination of popen() and pclose(): it opens pipes to
a subprocess, and allows the parent to wait until that process has
terminated, and closes the pipe(s).  The rationale for naming the
class Popen is exactly the same as the rationale for naming the
analogous functions.  Do you think that subprocess.pipe() is not as
good a name as subprocess.subprocess()?

> If it is at all, because `popen()` on C level can just open a pipe
> in *one* direction.

That also is not (necessarily) true.  Some Unix implementations
provide bidirectional implementations of popen().  See, for example,
the OS X popen() man page.  It's existed in BSD Unix for years...

> > Note that in all of these links that talk about popen, the focus is on
> > opening pipes or file objects, not on subprocesses:
> > 
> > http://www.opengroup.org/onlinepubs/009695399/functions/popen.html
> > http://docs.python.org/lib/os-newstreams.html http://us3.php.net/popen
> > http://docs.hp.com/en/B9106-90010/popen.3S.html
> > http://www.faqs.org/docs/artu/ch07s02.html
> 
> And all of the links talk about the `popen()` function, 
> not about the functionality the `Popen` class provides.  Which is
> much more than that simple pipe `popen()` returns.

Well, you're comparing a class to a function, so no surprise there.
But it's not really that much more, if you include pclose().  With the
exception that it allows you to connect multiple streams instead of
only one, and it saves the PID of the child (which for the most part
is not especially useful), the functionality is identical.  If you
actually look at  the Python implementation of the subprocess.Popen
class, the implementation is essentially identical to the C
implementation of the popen() and pclose() functions except that the
latter saves the PID returned by the call to fork() in a class
attribute, and opens 3 pipes instead of 1.  If C's popen() and
pclose() functions were written as a C++ class instead of two separate
functions, it would look rather a lot like python's subprocess.Popen
class.

> > The Linux man page unfortunately copies (verbatim) the FreeBSD man
> > page, which gets it wrong.  You can not open a process, but you
> > can definitely open a pipe.
> 
> Ah, when their terminology doesn't match yours, they must get it
> wrong.  ;-)

Nice try...  Their terminology doesn't match the original author's.
Here's the original AT&T System 7 man page:

  http://www.freebsd.org/cgi/man.cgi?query=popen&apropos=0&sektion=0&manpath=Unix+Seventh+Edition&format=html

When describing what this function does, it states, "It creates a
pipe..." 

Besides which, the BSD folks felt the need to quote "open", indicating
that clearly they knew that no process is being "opened" by the
function call.  You start processes, you don't open them.  This should
have been a clue to the BSD manual page writer that they had the sense
wrong; it's very obviously the pipe that gets opened, not the process.

-- 
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/20080902/3110b0fa/attachment-0001.sig>