Author eric.smith
Recipients Alexander.Belopolsky, Christophe Simonis, eric.smith, r.david.murray
Date 2010-02-28.16:12:47
SpamBayes Score 1.8483e-07
Marked as misclassified No
Message-id <1267373570.82.0.480239826191.issue7839@psf.upfronthosting.co.za>
In-reply-to
Content
I think the better design is to have 2 distinct APIs: Popen_shell and Popen_exec. I'm not wild about the name Popen_exec, suggestions welcome. Neither of these would accept a shell parameter.

For starters these could be convenience APIs that just call Popen with the correct shell= value, and check the type of args. We could ultimately deprecate Popen itself.

I don't see a use case where you programmatically compute the value of shell: it's always known as a function of how you're building up args. And even if such a rare case exists, you could select between the two APIs to call.

Whether at this point we can make this change is another issue, of course. I'm just trying to get at the best design. But if it's done over a number of releases I think it's doable.
History
Date User Action Args
2010-02-28 16:12:50eric.smithsetrecipients: + eric.smith, Christophe Simonis, r.david.murray, Alexander.Belopolsky
2010-02-28 16:12:50eric.smithsetmessageid: <1267373570.82.0.480239826191.issue7839@psf.upfronthosting.co.za>
2010-02-28 16:12:48eric.smithlinkissue7839 messages
2010-02-28 16:12:48eric.smithcreate