[Python-ideas] Suprocess functionality partitioning

[Andrew Barnert]

On Jun 12, 2013, at 23:13, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> The best way forward with your proposal is IMHO to start a project on PyPI
> to make it possible to iterate fast with community feedback. Possible stdlib
> inclusing can then be discussed when that project is stable and has a 
> signifant userbase.

IMHO, even before that, it's worth surveying the other PyPI libraries in the same space. http://bugs.python.org/issue13238 links to many of them, but there are definitely more than those. Some of them are pretty similar to this proposal; others are radically different.

It's also worth looking at the interfaces in node.js, ruby, etc. Most languages' stdlibs don't have the fancy exec wrappers that python has, and only have semi-fancy os.system replacements. But that might mean they've put more thought into those os.system replacements, or taken advantage of the freedom that comes from not having to design an interface that makes sense for both shell=True and shell=False.

A proposal that took the best from all of those, and had a rationale that included a survey and explained what was wrong with all of the existing alternatives, instead of just how subprocess is too complicated would be a lot more compelling, at least to me.

In fact, I wonder if having links to those libraries in the subprocess docs (together with the upcoming packaging improvements) would remove much of the recurring demand for adding new subprocess wrappers to the stdlib. I don't know if there's a policy on that, but it does seem to be pretty rare (and mainly used for links to implementations either as code examples or for backporting). So maybe it's not considered appropriate?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130613/61ed4aae/attachment.html>