Re: Inquiry regarding the name of subprocess.Popen class
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Wed, Sep 03, 2008 at 12:20:18AM -0400, Miles wrote: Derek Martin wrote: On Tue, Sep 02, 2008 at 10:55:54PM +, 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 pgphiAy6Q03Hs.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Wed, Sep 03, 2008 at 06:40:10AM +, 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
pgpvhafSwjqFj.pgp
Description: PGP signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
En Tue, 02 Sep 2008 19:15:07 -0300, Derek Martin [EMAIL PROTECTED] 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 so 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Wed, 03 Sep 2008 03:09:18 -0400, Derek Martin wrote:
On Wed, Sep 03, 2008 at 06:40:10AM +, 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
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 [EMAIL PROTECTED]
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
pgp0vGu5I07IT.pgp
Description: PGP signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
En Wed, 03 Sep 2008 21:34:35 -0300, Derek Martin [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
En Mon, 01 Sep 2008 04:23:38 -0300, Jeremy Banks [EMAIL PROTECTED] escribió: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
En Mon, 01 Sep 2008 04:23:38 -0300, Jeremy Banks [EMAIL PROTECTED] escribió: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Sep 1, 9:23 am, Jeremy Banks [EMAIL PROTECTED] wrote: 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/007908775/xsh/popen.html Cheers, Nicola Musatti -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, 02 Sep 2008 05:02:07 -0700, Nicola Musatti wrote: On Sep 1, 9:23 am, Jeremy Banks [EMAIL PROTECTED] wrote: 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/007908775/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 popens, whatever that may be. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, Sep 02, 2008 at 12:27:49PM +, Marc 'BlackJack' Rintsch wrote: The Python class is a generalization of the standard Posix function of (almost) the same name: http://opengroup.org/onlinepubs/007908775/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 popens, 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 pgpR91MGDIrTx.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, 02 Sep 2008 09:28:42 -0400, Derek Martin wrote: On Tue, Sep 02, 2008 at 12:27:49PM +, Marc 'BlackJack' Rintsch wrote: The Python class is a generalization of the standard Posix function of (almost) the same name: http://opengroup.org/onlinepubs/007908775/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 popens, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, Sep 02, 2008 at 01:57:26PM +, 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/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 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 pgpmN360qDTwf.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, 02 Sep 2008 11:39:09 -0400, Derek Martin wrote: On Tue, Sep 02, 2008 at 01:57:26PM +, 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/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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
En Tue, 02 Sep 2008 12:39:09 -0300, Derek Martin [EMAIL PROTECTED] escribió: On Tue, Sep 02, 2008 at 01:57:26PM +, 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/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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, Sep 02, 2008 at 06:47:39PM +, 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 ATT System 7 man page: http://www.freebsd.org/cgi/man.cgi?query=popenapropos=0sektion=0manpath=Unix+Seventh+Editionformat=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 pgpHERUiFlmDu.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
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 pgpjs8JNQejpd.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Tue, Sep 02, 2008 at 10:55:54PM +, 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 pgpeShX0WeeW7.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
Derek Martin wrote: On Tue, Sep 02, 2008 at 10:55:54PM +, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
Derek Martin wrote: On Tue, Sep 02, 2008 at 10:55:54PM +, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inquiry regarding the name of subprocess.Popen class
On Wed, Sep 03, 2008 at 12:20:18AM -0400, Miles wrote: Derek Martin wrote: On Tue, Sep 02, 2008 at 10:55:54PM +, 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 pgpFzhcvw9B48.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Inquiry regarding the name of subprocess.Popen class
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. -- http://mail.python.org/mailman/listinfo/python-list
