Inquiry regarding the name of subprocess.Popen class
gagsl-py2 at yahoo.com.ar
Wed Sep 3 09:30:45 CEST 2008
En Tue, 02 Sep 2008 19:15:07 -0300, Derek Martin <code at pizzashack.org>
>> > 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.
More information about the Python-list