[Python-ideas] shutil.runret and shutil.runout

[Stephen J. Turnbull]

Nick Coghlan writes:

 > For throwaway scripts, though, most of the Linux sysadmins I know just
 > use shell scripts

Sure, but it's really hard to beat *sh plus GNU readline for brevity
in using recent history to create a script.  At some point, we "just
don't want to go there."  As for the Perl arm of your disjunction, do
those sysadmins use Python for anything?  There's a lot of history in
the Linux sysadmin community favoring Perl.  (Although the l33t
Perlmonger I know is a Ruby hacker now....)

 > For the devops (and deployment automation in general) crowd,
 > there's no real Python-based competitor to Chef and Puppet (both
 > Ruby based) (my understanding is that the Python-based Fabric
 > doesn't play in *quite* the same space as the other two).

No, there isn't, but creating one could be rather hard, as Puppet and
Chef both make heavy use of Ruby features conducive to writing DSLs.
Note that although Fabric plays in a distinct space, its
implementation looks like Chef, far more so than Puppet (ie, you write
Fabric configs in Python, and Chef configs in a (domain-specific
extension of) Ruby, while Puppet is a restricted DSL).

One of the Puppet rationales for using Puppet rather than Chef is
telling here:

    3. Choice of configuration languages

    The language which Puppet uses to configure servers is designed
    specifically for the task: it is a domain language optimised for
    the task of describing and linking resources such as users and
    files.

    Chef uses an extension of the Ruby language. Ruby is a good
    general-purpose programming language, but it is not designed for
    configuration management - and learning Ruby is a lot harder than
    learning Puppet’s language.

    Some people think that Chef’s lack of a special-purpose language
    is an advantage. “You get the power of Ruby for free,” they
    argue. Unfortunately, there are many things about Ruby which
    aren’t so intuitive, especially for beginners, and there is a
    large and complex syntax that has to be mastered.

    -- http://bitfieldconsulting.com/puppet-vs-chef

That applies equally well to "DSL"s that are extensions of (function
calls in) Python.

Making it easier to write DSLs in Python has come up many times, and
so far the answer has always been "if you want to write a DSL in
Python, write a DSL in Python; but you can't, and won't soon be able
to, run it directly in the Python interpreter."  DSLs have been done;
there's configparser for one, argparse and ancestors, and things like
gitosis.  But it's hard to see Python beating Ruby at that game.

 > As things currently stand, Python deliberately makes it hard to say
 > "I want my individual commands to be shell commands, but I also
 > want Python's superior flow control constructs to decide which
 > shell commands to run".

I don't think that's ever been my motivation for writing a script in
Python.  Really, is Python's for loop so much better than bash's?  For
me, it's data structures: something where my sed fu isn't enough, or
the content has to persist longer than into the next pipe.

And quoting.  Shell quoting is such a pain, especially if there's an
ssh remote command in there somewhere.

This is not to say I'm opposed to making it easier to use Python as a
command shell in principle, but I have to wonder whether it can be
done as easily as all that, and without sacrificing some of the things
we've insisted on in past discussions.  On the other hand, for things
where avoiding shell makes sense, Python is one of my tools of choice
(the other being Emacs Lisp, where I want integration with my editor
and don't much care about performance).