[Python-Dev] PEP 324: popen5 - New POSIX process module

[Jess Austin]

Martin, you seem to be quite fond of popen2.

"Martin v. Loewis" <martin at v.loewis.de> wrote in message news:<mailman.60.1073175311.12720.python-list at python.org>...
> So enhance them, instead of replacing them.

and...
> I find that an acceptable incompatibility, and it will likely break
> no existing application. Applications usually expect that the program

and...
> Why is that? Just add a single function, with arguments
> stdin/stdout/stderr. No need for 12 functions. Then explain the existing
> functions in terms of your new function (if possible).

and... 
> You really should work with the existing code base. Ignoring it is a
> guarantee that your PEP will be rejected. (Studying it, and then
> providing educated comments about it, might get you through)

But you're not quite so fond of the people who are using popen2. 
Dumping a bunch of interface changes on them at this late date will
not make users happy.  They worked to get their code functioning with
what you admit is not a perfect module.  Now you suggest breaking all
that installed code the next time a new version comes out?

As someone who has used popen2 and who looks forward to using this new
"process" module, I value user happiness.  This seems to be one of the
many situations in which happiness is highly correlated with choice. 
If I have some old code that works as well as I need it to work with
popen2, I choose to leave it the hell alone, and I appreciate it not
getting broken behind my back.  If I'm writing something new, and I
find the interface offered by "process" more logical, I will choose to
use that.  Further, I will appreciate not having to reacquaint myself
with the numerological arcana of popen2, if only to know what to
ignore while using the new function.  If I have code I could never get
to work properly with popen2 and suddenly "process" becomes available,
I will be only too happy to modify it for use with the new module.  If
I'm an utter newbie who is thinking about processes for the first time
in my life, it doesn't matter where the gurus point me so long as they
point me to something that makes sense.

I admit that I haven't looked at this proposed package at all yet;
I've only read the PEP.  It's quite possible that it doesn't fulfill
all my hopes and dreams, that it won't contribute to my choice and my
happiness.  I note with some trepidation that plans for the Windows
platform aren't fully fleshed out.  But you haven't offered criticism
of the implementation, your objection is that "it's not called
popen2".  I suspect that few people will give that objection much
weight, whether they have used popen2 or not.

"Martin v. Loewis" <martin at v.loewis.de> continues...
> I never said it would be easy. However, introducing a new popen module
> is a major change, and there must be strong indications that the current
> API cannot be enhanced before throwing it away.
> 
> There should be one-- and preferably only one --obvious way to do it.
> 
> As for breaking compatibility: This is what the PEP should study in
> detail. It is sometimes acceptable to break compatibility, if

I think that the PEP contains the "strong indications" you require. 
While it's nice to have "one way" that we can tell newbies, it isn't
mandatory that there be only one way we've ever done it.  That would
inhibit progress.  I support functioning code, and progress in the
directions that users choose.  +1.

later,
Jess