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
pgphiAy6Q03Hs.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list