[Python-ideas] Suprocess functionality partitioning

Nick Coghlan ncoghlan at gmail.com
Thu Jun 13 13:39:05 CEST 2013


On 13 June 2013 18:26, Andrew Barnert <abarnert at yahoo.com> wrote:
> 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.

Julia's command invocation supports is gorgeous
(http://docs.julialang.org/en/latest/manual/running-external-programs/)
and the primary inspiration for
http://shell-command.readthedocs.org/en/latest/ (suitably adjusted to
handle the lack of syntactic support).

Wrapping around an *actual* shell the way shell-command does is
dangerous, though - better to do something that avoids depending on an
external shell program in the first place.

> 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?

Generally not considered appropriate, except for modules that are
actually backports of stdlib functionality. It's mostly a duty of care
issue (once we link to an external resource, then it carries a certain
promise that it's up to the standards of stdlib inclusion), but also a
"we don't want to play favourites" issue.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list