[Python-ideas] Interest in seeing sh.py in the stdlib

[Vinay Sajip]

Andrew Moffat <andrew.robert.moffat at ...> writes:

> 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