Inquiry regarding the name of subprocess.Popen class

[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

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