Inquiry regarding the name of subprocess.Popen class

[Jeremy Banks]

Hi. I wondered if anyone knew the rationale behind the naming of the
Popen class in the subprocess module. Popen sounds like the a suitable
name for a function that created a subprocess, but the object itself is
a subprocess, not a "popen". It seems that it would be more accurate to
just name the class Subprocess, can anyone explain why this is not the
case?

Thank you.

[Gabriel Genellina]

En Mon, 01 Sep 2008 04:23:38 -0300, Jeremy Banks <je****@jeremybanks.caescribió:

Hi. I wondered if anyone knew the rationale behind the naming of the
Popen class in the subprocess module. Popen sounds like the a suitable
name for a function that created a subprocess, but the object itself is
a subprocess, not a "popen". It seems that it would be more accurate to
just name the class Subprocess, can anyone explain why this is not the
case?

I have no idea - but I agree, Subprocess would have been a better name.

--
Gabriel Genellina

[Gabriel Genellina]

En Mon, 01 Sep 2008 04:23:38 -0300, Jeremy Banks <je****@jeremybanks.caescribió:

Hi. I wondered if anyone knew the rationale behind the naming of the
Popen class in the subprocess module. Popen sounds like the a suitable
name for a function that created a subprocess, but the object itself is
a subprocess, not a "popen". It seems that it would be more accurate to
just name the class Subprocess, can anyone explain why this is not the
case?

I have no idea - but I agree, Subprocess would have been a better name.

--
Gabriel Genellina

[Nicola Musatti]

On Sep 1, 9:23 am, Jeremy Banks <[e-mail]:

Hi. I wondered if anyone knew the rationale behind the naming of the
Popen class in the subprocess module. Popen sounds like the a suitable
name for a function that created a subprocess, but the object itself is
a subprocess, not a "popen". It seems that it would be more accurate to
just name the class Subprocess, can anyone explain why this is not the
case?

The Python class is a generalization of the standard Posix function of
(almost) the same name: http://opengroup.org/onlinepubs/0079...xsh/popen.html

Cheers,
Nicola Musatti

[Marc 'BlackJack' Rintsch]

On Tue, 02 Sep 2008 05:02:07 -0700, Nicola Musatti wrote:

On Sep 1, 9:23 am, Jeremy Banks <[e-mail]:

>Hi. I wondered if anyone knew the rationale behind the naming of the
Popen class in the subprocess module. Popen sounds like the a suitable
name for a function that created a subprocess, but the object itself is
a subprocess, not a "popen". It seems that it would be more accurate to
just name the class Subprocess, can anyone explain why this is not the
case?

The Python class is a generalization of the standard Posix function of
(almost) the same name:
http://opengroup.org/onlinepubs/0079...xsh/popen.html

So it's a name of a *function* and it's a little bit unsuitable for a
*class*. As Jeremy wrote: the instances represent *processes* not
"popen"s, whatever that may be.

Ciao,
Marc 'BlackJack' Rintsch

[Derek Martin]

On Tue, Sep 02, 2008 at 12:27:49PM +0000, Marc 'BlackJack' Rintsch wrote:

The Python class is a generalization of the standard Posix function of
(almost) the same name:
http://opengroup.org/onlinepubs/0079...xsh/popen.html

So it's a name of a *function* and it's a little bit unsuitable for a
*class*. As Jeremy wrote: the instances represent *processes* not
"popen"s, whatever that may be.

I would argue that they don't represent processes at all; the object
is a set of files which connect the standard I/O streams of a
subprocess to its parent, and methods to operate on those files. The
C library's popen() function, on which this class is based, provides a
means to open a file and connect it to the standard steams of a
subprocess, making it more closely analogous to what the Popen class
does/provides. As such, "Popen" is a better name to describe this
object than "subprocess" would be.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvT+KdjdlQoHP510RAky4AJ9gD/gQ3+ZBp9wHkEnOuFC05WG8SgCgnRTv
e8ePs4FGi/CPq6lggmc9VFU=
=X/Tb
-----END PGP SIGNATURE-----

[Marc 'BlackJack' Rintsch]

On Tue, 02 Sep 2008 09:28:42 -0400, Derek Martin wrote:

On Tue, Sep 02, 2008 at 12:27:49PM +0000, Marc 'BlackJack' Rintsch
wrote:

The Python class is a generalization of the standard Posix function
of (almost) the same name:
http://opengroup.org/onlinepubs/0079...xsh/popen.html

So it's a name of a *function* and it's a little bit unsuitable for a
*class*. As Jeremy wrote: the instances represent *processes* not
"popen"s, whatever that may be.

I would argue that they don't represent processes at all; the object is
a set of files which connect the standard I/O streams of a subprocess to
its parent, and methods to operate on those files.

And the process' ID, an attribute with the process' return code, a method
to wait until the process is finished and file objects to communicate
with the process.

The C library's popen() function, on which this class is based,
provides a means to open a file and connect it to the standard steams
of a subprocess, making it more closely analogous to what the Popen
class does/provides. As such, "Popen" is a better name to describe
this object than "subprocess" would be.

Is strongly disagree. The class provides an interface to start and
communicate with a `Subprocess`. Instances stand for processes.

With your reasoning the `file` type should be called `open`.

Ciao,
Marc 'BlackJack' Rintsch

[Derek Martin]

On Tue, Sep 02, 2008 at 01:57:26PM +0000, Marc 'BlackJack' Rintsch wrote:

I would argue that they don't represent processes at all; the object is
a set of files which connect the standard I/O streams of a subprocess to
its parent, and methods to operate on those files.

And the process' ID, an attribute with the process' return code, a method
to wait until the process is finished and file objects to communicate
with the process.

The name popen is an abbreviation of "pipe open" -- the function, and
the class, open pipes to communicate with another process. What you
said is correct; however there are numerous other ways to open
subprocesses. The focus of popen is the communication aspect -- the
opening and control of the pipes -- not the subprocess. That's the
key difference between popen() and all the other methods of starting a
subprocess.

The C library's popen() function, on which this class is based,
provides a means to open a file and connect it to the standard steams
of a subprocess, making it more closely analogous to what the Popen
class does/provides. As such, "Popen" is a better name to describe
this object than "subprocess" would be.

Is strongly disagree. The class provides an interface to start and
communicate with a `Subprocess`. Instances stand for processes.

There's more than one way to look at it. You can disagree all you
like, but your interpretation disagrees with the historical intent of
popen.

With your reasoning the `file` type should be called `open`.

In this case, the file is a pipe, and the 'p' in popen represents the
pipe. Unix, by and large, doesn't care that it's a pipe -- file I/O
is intended to work the same way regardless of whether it's a pipe, a
socket, a file on disk, a special device file, or any other file-like
object you can imagine. That's why I said "file" instead of "pipe" in
my explanation.

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

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.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvV4ddjdlQoHP510RAnvGAKC7cgu7O0gdLnrjqRdxYJ Npe73xiACfZx6K
1GHoO7XRo2sBRBLpAxST3BI=
=5yd3
-----END PGP SIGNATURE-----

[Marc 'BlackJack' Rintsch]

On Tue, 02 Sep 2008 11:39:09 -0400, Derek Martin wrote:

On Tue, Sep 02, 2008 at 01:57:26PM +0000, Marc 'BlackJack' Rintsch
wrote:

I would argue that they don't represent processes at all; the object
is a set of files which connect the standard I/O streams of a
subprocess to its parent, and methods to operate on those files.

And the process' ID, an attribute with the process' return code, a
method to wait until the process is finished and file objects to
communicate with the process.

The name popen is an abbreviation of "pipe open" -- the function, and
the class, open pipes to communicate with another process. What you
said is correct; however there are numerous other ways to open
subprocesses. The focus of popen is the communication aspect -- the
opening and control of the pipes -- not the subprocess. That's the key
difference between popen() and all the other methods of starting a
subprocess.

But I'm not talking about the `popen()` function but the
`subprocess.Popen` class.

The C library's popen() function, on which this class is based,
provides a means to open a file and connect it to the standard steams
of a subprocess, making it more closely analogous to what the Popen
class does/provides. As such, "Popen" is a better name to describe
this object than "subprocess" would be.

Is strongly disagree. The class provides an interface to start and
communicate with a `Subprocess`. Instances stand for processes.

There's more than one way to look at it. You can disagree all you like,
but your interpretation disagrees with the historical intent of popen.

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. If it is at all, because
`popen()` on C level can just open a pipe in *one* direction.

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

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

Ciao,
Marc 'BlackJack' Rintsch

[Gabriel Genellina]

En Tue, 02 Sep 2008 12:39:09 -0300, Derek Martin <co**@pizzashack.orgescribió:

On Tue, Sep 02, 2008 at 01:57:26PM +0000, Marc 'BlackJack' Rintsch wrote:

I would argue that they don't represent processes at all; the object is
a set of files which connect the standard I/O streams of a subprocess to
its parent, and methods to operate on those files.

And the process' ID, an attribute with the process' return code, a method
to wait until the process is finished and file objects to communicate
with the process.

The name popen is an abbreviation of "pipe open" -- the function, and
the class, open pipes to communicate with another process. What you
said is correct; however there are numerous other ways to open
subprocesses. The focus of popen is the communication aspect -- the
opening and control of the pipes -- not the subprocess. That's the
key difference between popen() and all the other methods of starting a
subprocess.

Totally irrelevant here - we are talking about the subprocess module, not the popen C function.

The C library's popen() function, on which this class is based,

No, subprocess.Popen does not use -directly or indirectly- the C popen function. It uses fork or CreateProcess in Windows.

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

Again, irrelevant.

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.

(Ok, if it doesn't agree with you, it must be wrong)

Classes represent "things", and class names should be nouns. Functions represent "actions", and their names should be verbs. popen is a good name for a function; Popen is a bad name for a class.

--
Gabriel Genellina

[Terry Reedy]

Gabriel Genellina wrote:

Classes represent "things", and class names should be nouns.
Functions represent "actions", and their names should be verbs. popen
is a good name for a function; Popen is a bad name for a class.

People who don't like Popen should have made this argument when
subprocess was being designed (for 2.4) ;-). Or at least a year ago or
even 6 month ago when API changes for 3.0 were considered.

Part of the reason for the name is that .Popen completely replaces the
popen2, popen3, and popen4 functions, and others (yes, functions, not
classes), now gone (3.0) and either replaces or supplement os.popen
itself. I would not have liked subprocess.Subprocess. Perhaps Proc
would have been okay. PipedProcess is too long. ....

[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/...ons/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?q...on&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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvbLvdjdlQoHP510RAvj2AJ4tKAxFoofxVDu08EvG5E sVsawppACgrAvU
zp2XSmFgkvAeWk5NMgXbfOY=
=Pgy1
-----END PGP SIGNATURE-----

[Derek Martin]

On Tue, Sep 02, 2008 at 05:22:51PM -0300, Gabriel Genellina wrote:

The name popen is an abbreviation of "pipe open" -- the function, and
the class, open pipes to communicate with another process. What you
said is correct; however there are numerous other ways to open
subprocesses. The focus of popen is the communication aspect -- the
opening and control of the pipes -- not the subprocess. That's the
key difference between popen() and all the other methods of starting a
subprocess.

Totally irrelevant here - we are talking about the subprocess
module, not the popen C function.

I was talking about both actually. I can't agree that it's not
relevant... The Popen class clearly takes its name from the function
of the same name, and does exactly the same thing (plus what pclose()
does, plus saving the pid of the forked process). Seems pretty
relevant to me.

The C library's popen() function, on which this class is based,

No, subprocess.Popen does not use -directly or indirectly- the C
popen function. It uses fork or CreateProcess in Windows.

I didn't say it used it. I said it was based on it. It is
(conceptually).

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.

(Ok, if it doesn't agree with you, it must be wrong)

See my last post for accreditation of my comment. A common
argumentation tactic of the closed-minded and the small-minded is to
resort to insinuation to attack the validity of other's comments
without providing any basis for doing so. Nice job.

Classes represent "things", and class names should be nouns.

Is that a law?

Classes are instantiated by invoking their class names as a function
call -- the computing equivalent of a verb. Why then, must they be
named as nouns? Can you not, in fact, have classes which describe
(or model) actions? Wouldn't you name them using verbs if you did?

That said, this is the most valid point anyone has made... You should
have made it when the module was being designed. :-D

My point is, if you don't think Popen is a good name for the class,
that's your opinion, but it is only that: an opinion. Yet some of you
state your case as if it is incontrovertable fact. I've given a good
case as to why it IS a good name (one which I genuinely support), and
disagree as you may, none of the points any of you have made
invalidate or even weaken my argument. Lastly, the maintainers
obviously thought it was a good name when they included it...

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvbrrdjdlQoHP510RAn70AJ0bgTdNAeISNT3F85IsY0 GNxTpJRACfcx6f
eZ4i/IWUx6VuaYRk8VkKyE0=
=d3TR
-----END PGP SIGNATURE-----

[Marc 'BlackJack' Rintsch]

On Tue, 02 Sep 2008 18:15:07 -0400, Derek Martin wrote:

>Classes represent "things", and class names should be nouns.

Is that a law?

It's a common guideline.

Classes are instantiated by invoking their class names as a function
call -- the computing equivalent of a verb. Why then, must they be
named as nouns? Can you not, in fact, have classes which describe (or
model) actions? Wouldn't you name them using verbs if you did?

Me personally no. I would use `FooAction` instead of `Foo` or something
similar. And if they model an action there must be some way to activate
the action but the instances of `Popen` are no actions. There's no way
to "execute" a `Popen` instance.

That said, this is the most valid point anyone has made... You should
have made it when the module was being designed. :-D

My point is, if you don't think Popen is a good name for the class,
that's your opinion, but it is only that: an opinion.

Like your opinion that it *is* a good name.

Yet some of you state your case as if it is incontrovertable fact.
I've given a good case as to why it IS a good name (one which I
genuinely support), and disagree as you may, none of the points any of
you have made invalidate or even weaken my argument.

Maybe from your POV. Facts: It doesn't use the `popen()` function, it
gives something more complex than a simple pipe (no obligatory shell, up
to three file objects, more attributes and methods), the function used on
Windows under the hood is called `CreateProcess()` not `CreatePipe()`.

`Popen` creates a process and represents a proxy object to communicate
with it, so `Process` is a good name for that concept/"thing". It's a
way more self explaining name, even for people who know the `popen()`
function because there's a concept called "process" but none called
"popen".

Ciao,
Marc 'BlackJack' Rintsch

[Derek Martin]

On Tue, Sep 02, 2008 at 10:55:54PM +0000, Marc 'BlackJack' Rintsch wrote:

On Tue, 02 Sep 2008 18:15:07 -0400, Derek Martin wrote:

Classes represent "things", and class names should be nouns.

Is that a law?

It's a common guideline.

Right. It's a guideline.

Classes are instantiated by invoking their class names as a function
call -- the computing equivalent of a verb. Why then, must they be
named as nouns? Can you not, in fact, have classes which describe (or
model) actions? Wouldn't you name them using verbs if you did?

Me personally no. I would use `FooAction` instead of `Foo` or something
similar.

Maybe you would, but I think a lot of folks would just use the action
name (i.e. the verb).

And if they model an action there must be some way to activate
the action

That's a reasonable assumption, but as I also said, the object might
just describe the action -- essentially the equivalent of a struct in
C.

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). For an object
which describes an action, I think it's perfectly sensible that
instantiation is when the action occurs, though there could be other
times (e.g. if the object had an "execute" method) which make as much
sense.

My point is, if you don't think Popen is a good name for the class,
that's your opinion, but it is only that: an opinion.

Like your opinion that it *is* a good name.

Yes, exactly.

Yet some of you state your case as if it is incontrovertable fact.
I've given a good case as to why it IS a good name (one which I
genuinely support), and disagree as you may, none of the points any of
you have made invalidate or even weaken my argument.

Maybe from your POV. Facts: It doesn't use the `popen()` function

So? Neither does the C version of popen(), but that function is still
called popen()! :-D As I've already said a few times now, it is
conceptually based on popen(). The fact that it doesn't use popen()
is not interesting; it (or the portion of it that corresponds to what
popen() does) is implemented almost exactly the same way as the
C popen() function (except in Python, rather than C). That, to me, is
much more interesting. pclose() does what Popen.wait() does,
essentially. Sure, the class has a few extre bells and whistles that
the C implementation doesn't have, but:

it gives something more complex than a simple pipe

Gosh, one would hope that it would be universally true that an
object-oriented implementation of something that was originally
designed using conventional programming techniques would provide more
than one piece of the conventional implementation... We might even
hope that it would improve upon 40-year-old implementations, wherever
possible...

to three file objects, more attributes and methods), the function used on
Windows under the hood is called `CreateProcess()` not `CreatePipe()`.

How does Windows implement popen()? [I think they call it _popen()
though...]

`Popen` creates a process and represents a proxy object to communicate
with it, so `Process` is a good name for that concept/"thing".

I disagree; the point of that process creation is the communication
between the two processes. Calling it a process does not reflect this
very important aspect of the object. The Popen object is not a
process; it is a collection of pipes and methods used to communicate
with one.

It's a way more self explaining name, even for people who know the
`popen()` function

I, and apparently the maintainers (at least at the time they added
this thing) don't agree. In fact I think it's quite the opposite. If
I came across such a "process" object without knowing what it was, I
would expect that a process object described a running process, i.e.
gave information about things like executable path name, cpu and
memory utilization, perhaps a list of all open file descriptors (but
not just three specific ones), etc; or something similar. This object
provides none of that. It does not, in fact, describe a process at
all. It is quite distinct and different from the concept of a
process, indeed.

because there's a concept called "process" but none called "popen".

Anything that exists can be conceptualized and therefore is a concept.
The popen concept exists, and is more than just a concept; it has a
concrete implementation in C AND Python and numerous other languages.
Verbs can be concepts too.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvdIkdjdlQoHP510RAiQLAKCuaq3YlM+yVUuk+wVCXR +2XYzvagCbB5Fs
ews+11N2VnK7T73qDQ3cFu4=
=fn0N
-----END PGP SIGNATURE-----

[Terry Reedy]

Derek Martin wrote:

On Tue, Sep 02, 2008 at 10:55:54PM +0000, Marc 'BlackJack' Rintsch wrote:

>

>It's a way more self explaining name, even for people who know the
`popen()` function

I, and apparently the maintainers (at least at the time they added
this thing) don't agree. In fact I think it's quite the opposite. If
I came across such a "process" object without knowing what it was, I
would expect that a process object described a running process, i.e.
gave information about things like executable path name, cpu and
memory utilization, perhaps a list of all open file descriptors (but
not just three specific ones), etc; or something similar. This object
provides none of that. It does not, in fact, describe a process at
all. It is quite distinct and different from the concept of a
process, indeed.

>because there's a concept called "process" but none called "popen".

Anything that exists can be conceptualized and therefore is a concept.
The popen concept exists, and is more than just a concept; it has a
concrete implementation in C AND Python and numerous other languages.
Verbs can be concepts too.

In this case, at least, I think of the module name as part of the total
class name. subprocess.Popen == open pipes to a subprocess -- and
return a structure that lets me use the pipes and monitor the process.
So as a practical matter, I am okay with the name even if I
theoretically agree with the guideline as a guideline.

tjr

[Miles]

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. (I use it for that
functionality just as often, if not more so, as for piped subprocess
communication). All rationalizations aside, I think Popen is a poor
name for the class. But I would imagine the odds of it ever being
changed are miniscule (Python 4?).

-Miles

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

Uh... it's a replacement for os.popen(), which -- guess what -- opens
pipes.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvh9jdjdlQoHP510RArEOAJwJ7I6ioQsxkCvOOdQVdr ZpYRcIAwCeN9bi
3h1JA/RKQh2FxfE/98CreyI=
=WOf0
-----END PGP SIGNATURE-----

[Marc 'BlackJack' Rintsch]

On Wed, 03 Sep 2008 01:23:47 -0400, Derek Martin wrote:

On Wed, Sep 03, 2008 at 12:20:18AM -0400, Miles wrote:

>The subprocess module is also supposed to replace os.system and
os.spawn*, neither of which involve opening pipes.

Uh... it's a replacement for os.popen(), which -- guess what -- opens
pipes.

From the documentation:

subprocess - Subprocesses with accessible I/O streams

This module allows you to spawn processes, connect to their
input/output/error pipes, and obtain their return codes. This module
intends to replace several other, older modules and functions, like:

os.system
os.spawn*
os.popen*
popen2.*
commands.*

If it weren't called `Popen` but `Spawn` instead I guess you would argue
that it *must* be `Spawn` because it spawns processes and even it is not
using `spawn*()` under the hood it uses the concept of "spawn" with some
extras. ;-)

Ciao,
Marc 'BlackJack' Rintsch

[Marc 'BlackJack' Rintsch]

On Tue, 02 Sep 2008 19:54:12 -0400, Derek Martin wrote:

>And if they model an action there must be some way to activate the
action

That's a reasonable assumption, but as I also said, the object might
just describe the action -- essentially the equivalent of a struct in C.

``struct``\s in C describe *actions*!? Functions do this. And a class
that describes an action that is executed in the `__init__()` method is
conceptually a function and shouldn't be a class. There must be a better
name for the "thing" it returns. Again guideline, not law, but a very
strong guideline IMHO.

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

But then the instance itself isn't an action but the result of one.

At the time of instantiation, you "open" the "P" (pipes). For an
object which describes an action, I think it's perfectly sensible that
instantiation is when the action occurs, […]

Here I disagree again. Because the type/class name of an instance should
be a name of the "thing"/concept of the instance, not the action used to
create it.

Yet some of you state your case as if it is incontrovertable fact.
I've given a good case as to why it IS a good name (one which I
genuinely support), and disagree as you may, none of the points any
of you have made invalidate or even weaken my argument.

Maybe from your POV. Facts: It doesn't use the `popen()` function

So? Neither does the C version of popen(), but that function is still
called popen()!

Now you lost me. The C version of `popen()` isn't recursive, why on
earth should it be, so what's that statement supposed to mean!?

>to three file objects, more attributes and methods), the function used
on Windows under the hood is called `CreateProcess()` not
`CreatePipe()`.

How does Windows implement popen()? [I think they call it _popen()
though...]

Doesn't matter because the `Popen()` implementation doesn't use `popen()`.

Ciao,
Marc 'BlackJack' Rintsch

[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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvjGcdjdlQoHP510RAso3AJ4lf8T5YzKyG+0xrwQs2D oT+ZV6fwCeJilD
tWiGiNGeJRmOzNA4xshA6Ls=
=Ux4A
-----END PGP SIGNATURE-----

[Derek Martin]

On Wed, Sep 03, 2008 at 06:40:10AM +0000, Marc 'BlackJack' Rintsch wrote:

On Tue, 02 Sep 2008 19:54:12 -0400, Derek Martin wrote:

And if they model an action there must be some way to activate the
action

That's a reasonable assumption, but as I also said, the object might
just describe the action -- essentially the equivalent of a struct in C.

``struct``\s in C describe *actions*!? Functions do this.

struct run {
int speed;
direction_type direction;
};

Not a function. Describes an action. Sure, you'll probably never see
this example in a real program. But that doesn't mean you can't do
it, and it doesn't make it inherently wrong. Someone somewhere might
very well find a legitimate use case.

Besides which, I was not talking about programmatic actions; I was
talking about verbs -- actions that people do.

You are putting narrow-minded constraints on your ideas about how to
program. Sometimes thinking outside the box is useful...

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.

But then the instance itself isn't an action but the result of one.

So? A class doesn't represent an action, remember? It represents a
thing. Isn't that what you said?

At the time of instantiation, you "open" the "P" (pipes). For an
object which describes an action, I think it's perfectly sensible that
instantiation is when the action occurs, [¡¦]

Here I disagree again. Because the type/class name of an instance should
be a name of the "thing"/concept of the instance, not the action used to
create it.

You're making an assertion based on your personal opinion. That's a
fine guideline, but there's no requirement to do so. I can name my
classes anything I want. There's no reason I can't write:

Class Think:
def __init__:
self.thoughts = happy
print "Thinking %s thoughts!" %s self.thoughts
This is a silly example that does nothing useful, but that doesn't
exclude the possibility that someone might conceive of a similar
example that is actually useful. Maybe you're just not creative
enough, and I'm too lazy.

Maybe from your POV. Facts: It doesn't use the `popen()` function

So? Neither does the C version of popen(), but that function is still
called popen()!

Now you lost me. The C version of `popen()` isn't recursive, why on
earth should it be, so what's that statement supposed to mean!?

Sorry, did I go too fast for you? Your "facts" seem to be suggesting
that for Python's Popen class to be named Popen, it should use the C
popen() function. I can't imagine any other reason why you mentioned
it doesn't... It need not use popen() to do what popen() does... In
fact, it need not do what popen() does to be called Popen! It's just
a name... the author can call it whatever he wants. As it happens, it
was called Popen because it does essentially what popen() does. The
fact that it doesn't USE popen() to do it is... not interesting?

to three file objects, more attributes and methods), the function used
on Windows under the hood is called `CreateProcess()` not
`CreatePipe()`.

How does Windows implement popen()? [I think they call it _popen()
though...]

Doesn't matter because the `Popen()` implementation doesn't use `popen()`.

No, that's exactly why it *does* matter. Because neither is popen()
implemented using popen()! See! There you go again!

Does it matter, or doesn't it?!? What are you trying to say?!?

Sorry, but you are contradicting yourself (repeatedly), and your
arguments don't make any sense.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvjgedjdlQoHP510RAlnbAKC8P/NUFS9hfRWNK+JxL0F1EaCccQCfd643
0lqwfVBlYtw/8Ya+qI6nopo=
=MNh3
-----END PGP SIGNATURE-----

[Gabriel Genellina]

En Tue, 02 Sep 2008 19:15:07 -0300, Derek Martin <co**@pizzashack.org>
escribió:

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.

(Ok, if it doesn't agree with you, it must be wrong)

See my last post for accreditation of my comment. A common
argumentation tactic of the closed-minded and the small-minded is to
resort to insinuation to attack the validity of other's comments
without providing any basis for doing so. Nice job.

Well, you didn't provide (in that post) any reason for the Linux man page
to be wrong, other than you disagreed with its terminology... But I don't
want to argument on this - it was just a "side note".

>Classes represent "things", and class names should be nouns.

Is that a law?

Classes are instantiated by invoking their class names as a function
call -- the computing equivalent of a verb. Why then, must they be
named as nouns? Can you not, in fact, have classes which describe
(or model) actions? Wouldn't you name them using verbs if you did?

Not exactly. I usually use the -dor suffix (Spanish) or -er (English); in
both languages their meaning is to make a noun from a verb. A class whose
main purpose is to write things becomes a Writer, by example. The stdlib
is full of Writers, Openers, Parsers, Wrappers, Handlers, etc. If the main
purpose of subprocess.Popen were to open pipes, I'd say some form of
"opener" would be OK. But I think its main purpose is to model the child
process itself - pipes are just attributes, so a noun like Child,
Subprocess, Process or similar would have been more adequate.
Of course it's too late to change things now, at least for the near
future. Anyway, It's not the first misnamed class, nor the last one
-unfortunately-, nor it's sooooo badly named anyway...

That said, this is the most valid point anyone has made... You should
have made it when the module was being designed. :-D

(Yes, sure. Unfortunately, by the time 2.4 was released, I was still stuck
with Python 2.1 due to Zope incompatibilities... Properties and generators
were unreachable things to me... Oh, just remembering those times makes me
sick :( )

My point is, if you don't think Popen is a good name for the class,
that's your opinion, but it is only that: an opinion. Yet some of you
state your case as if it is incontrovertable fact. I've given a good
case as to why it IS a good name (one which I genuinely support), and
disagree as you may, none of the points any of you have made
invalidate or even weaken my argument. Lastly, the maintainers
obviously thought it was a good name when they included it...

No, please. I know it's just my opinion, and I can see there is a case for
the current name - just I don't like it, and liked to share my feelings
with the OP when he said the same.

--
Gabriel Genellina

[Marc 'BlackJack' Rintsch]

On Wed, 03 Sep 2008 03:09:18 -0400, Derek Martin wrote:

On Wed, Sep 03, 2008 at 06:40:10AM +0000, Marc 'BlackJack' Rintsch
wrote:

>On Tue, 02 Sep 2008 19:54:12 -0400, Derek Martin wrote:

>And if they model an action there must be some way to activate the
action

That's a reasonable assumption, but as I also said, the object might
just describe the action -- essentially the equivalent of a struct in
C.

``struct``\s in C describe *actions*!? Functions do this.

struct run {
int speed;
direction_type direction;
};

Guess what, I don't like the name because it doesn't describe an action
but a state of, e.g. a `Runner`. :-)

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

But then the instance itself isn't an action but the result of one.

So? A class doesn't represent an action, remember? It represents a
thing. Isn't that what you said?

Yes and that's why the type name should not describe the action but the
the thing that results from it. IMHO. But I said that already.

>Maybe from your POV. Facts: It doesn't use the `popen()` function

So? Neither does the C version of popen(), but that function is
still called popen()!

Now you lost me. The C version of `popen()` isn't recursive, why on
earth should it be, so what's that statement supposed to mean!?

Sorry, did I go too fast for you? Your "facts" seem to be suggesting
that for Python's Popen class to be named Popen, it should use the C
popen() function.

So you imply that I think any function should only have a name of a
function it uses under the hood!? I still don't get that sentence.

Sorry, but you are contradicting yourself (repeatedly), and your
arguments don't make any sense.

I don't contradict myself. Either you are playing silly naming games
with `popen()` on different levels ("concept", Popen, popen() (Python),
popen() (C)) or you just don't *want* to understand my arguments.

I understand your arguments why you think `Popen` is a proper name, but
don't share them. It's okay for me if you don't like my arguments
against it and for something like `Process`, but telling me they don't
make any sense and patronizing me doesn't make your arguments more
convincing.

Ciao,
Marc 'BlackJack' Rintsch

[Derek Martin]

On Wed, Sep 03, 2008 at 03:16:00PM -0700, Dennis Lee Bieber wrote:

On Wed, 3 Sep 2008 03:09:18 -0400, Derek Martin <co**@pizzashack.org>
declaimed the following in comp.lang.python:

struct run {
int speed;
direction_type direction;
};

Not a function. Describes an action. Sure, you'll probably never see
this example in a real program. But that doesn't mean you can't do
it, and it doesn't make it inherently wrong. Someone somewhere might
very well find a legitimate use case.

Does neither for me... It defines a (physics) VELOCITY (a direction
and a speed, but lacking in starting position and in duration).

OK... so, let me ask you then: I have a computer program that graphs
the state of a particular act of running over time t. The only
information the program cares about is the speed and direction of that
particular instance of running. What would your data structure look
like?

An action, "run", would, in my mind require taking this vector and
multiplying it by some duration, and adding the result to some starting
position.

I can not be held responsible for your mind... ;-)

You're talking about a computational action... which I already said is
NOT what I'm talking about. At any given point in time, if someone is
running, they have a direction and a speed. The structure I described
is sufficient to describe that state. In this extremely silly example,
the starting point, end point, and any intermediary positions are not
interesting to the problem, which has intentionally been left
undefined, because it is an EXAMPLE. Examples are not required to be
especially useful or meaningful, and I would guess that the vast majority of
examples in, say, introduction to comp sci texts are not (think "hello
world"). They need only illustrate something. This particular point
was that an object in a computer program can describe some physical
action -- in whole or only in part -- without actually needing to have
any executable code associated with that state (i.e. it can be a
data only, rather than an object with executable methods). The
"thing" being described being an action may lend itself to using the
name of that action, i.e. a verb, as the name of the object.

Though, actually, the example I described above is (minimally) useful.
Assuming you had an array of such structs, with say, the index
representing the time t in seconds, then it provides you with a graph
of the path taken during the act of running. You could superimpose
this graph on a map and, given a particular starting point, determine
where the person running ended up.

You might be inclined to say that the object should be a runner, and
you're free to think of it that way if you like... but the fact is the
object DOES NOT describe a runner. It describes an instance of
running at a moment in time. You might also be inclined to say that
the name "run" is a bad choice, because it should be something
retarded like state_of_run_at_time_t; but unless you're unbelievably
obtuse, then looking at the code, it gets the point across.
It may not be the most ideal name, but given the number of times I've
seen "foo" used as an identifier in real programs... well, is it
really so bad?

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIvy0bdjdlQoHP510RApNAAJ9cvbouPPKcwtOnxaWuw4 lptaWlIwCeM1VN
WrWDgM2UcFS/K6GdlIy7AwA=
=eEcB
-----END PGP SIGNATURE-----

[Gabriel Genellina]

En Wed, 03 Sep 2008 21:34:35 -0300, Derek Martin <co**@pizzashack.org>
escribi�:

On Wed, Sep 03, 2008 at 03:16:00PM -0700, Dennis Lee Bieber wrote:

>On Wed, 3 Sep 2008 03:09:18 -0400, Derek Martin <co**@pizzashack.org>
declaimed the following in comp.lang.python:

struct run {
int speed;
direction_type direction;
};

Not a function. Describes an action. Sure, you'll probably never see
this example in a real program. But that doesn't mean you can't do
it, and it doesn't make it inherently wrong. Someone somewhere might
very well find a legitimate use case.

Does neither for me... It defines a (physics) VELOCITY (a direction
and a speed, but lacking in starting position and in duration).

OK... so, let me ask you then: I have a computer program that graphs
the state of a particular act of running over time t. The only
information the program cares about is the speed and direction of that
particular instance of running. What would your data structure look
like?

I'd use the name "velocity", a noun, as Dennis Lee Bieber already said. In
pedantic mode, "average velocity".
If you still want to push further such ridiculous example I'll have to
think that you're just trolling.

--
Gabriel Genellina