The subprocess module provides a good foundation of basic functionality.  However, anything moderately complex becomes cumbersome to write.  Additionally, it has pitfalls that people frequently overlook.

People then often either resort to hand-rolling their own abstraction on top of it, use the library incorrectly, or just use shell scripts if the predominant action is to stitch things together.

I have seen great success at avoiding having to write shell-scripts & using the sh package. What once would have been written as shell-scripts now can be written very naturally using sh in a more maintainable & reusable manner.

I think sh being part of the standard library would be a great addition & make python even more compelling as a replacement for shell scripts.  Having sh be part of the python library also ensures that the `with` syntax could be done in a comprehensive thread-safe manner.

https://pypi.python.org/pypi/sh
http://amoffat.github.com/sh

While it's an interesting library, my fear is that people will start shelling out to all sorts of things which Python already has builtin. One of the examples on the github site was showing how to call "ls". Another example invoked "wc". neither of those is particularly difficult to pull off in Python. In addition, you're left with text data you need to parse for further use (assuming you even can reliably do so). Finally, I'm not sure masking the fork/exec overhead is such a great idea.

Indeed.  If you want shell scripting, use a shell script.  The advantage of python scripting is exactly that you are using non-shell, with explicit control of what gets substituted where rather than the shell's implicit rules.

Regardless our our opinions, though, this is the kind of topic that needs to be brought up first on the python-ideas mailing list.