Andrew Moffat
The main criticism has been the cleverness of the dynamic lookups.
I would add: * The plethora of special keyword arguments like _bg, _iter, _in, _piped etc. doesn't look good. * Using callbacks for processing stream output makes it harder to do certain kinds of processing on that output.
Windows support would be a little more difficult. It existed in an old version of sh, when it was merely a wrapper around the subprocess module. Now that sh.py no longer relies on the subprocess module and does fork-exec itself
This isn't good. You may have resorted to bypassing subprocess because it didn't do what you needed, but it certainly wouldn't look good if a proposed stdlib module wasn't eating its own dog food (by which I mean, using subprocess). Though there have been precedents (optparse / argparse), a determined effort was made there to work with the existing stdlib module before giving up on it. From my own experience, subprocess has not been that intractable, so I'm curious - what flexibility of access did you need that subprocess couldn't offer? I would guess things that are essentially non-portable, like tty access to provide pexpect-like behaviour. (I had to eschew this for sarge, in the interests of cross-platform compatibility.)
(in order to get more flexible access to the processes), Windows is currently unsupported. My current understanding is that most of the value comes from the linux/OSX folks, but Windows support is scheduled for the future.
It seems to me premature to propose sh.py for inclusion in the stdlib before offering Windows support. After all, those who need it can readily get hold of it from PyPI, as the impressive download numbers show. Just as its design has changed a fair bit going from pbs to sh.py, it may change yet more when Windows support is added, and it can be looked at again then. Regards, Vinay Sajip