Python advocacy

[Donn Cave]

Quoth Paul Prescod <paul at prescod.net>:
| Donn Cave wrote:
|> Lexically, I guess would be the word.  I have in mind two things.
|> The UNIX shell is what you get with a very domain specific language,
|> the simplest functions in the problem domain (UNIX commands) can be
|> written with no punctuation at all.  More complex operations can be
|> expressed with only a little punctuation, e.g., a pipeline.  
|
| Well I haven't said anything against pipes! I just don't think we need
| "if", "foreach" and friends. That's the point at which you want to wrap
| your commands and pipes in a language with data structures and text
| processing features.

I'd draw the line at some point too, but not there.  It sounds ("foreach"?)
like you have been fighting csh, which is a miserable misbegotten language
that most agree should never be used for programming.  (Interesting that
it's credited to William Joy, who I believe also gets some credit for Java.)

You probably know that the classic approach to shell programming is
very multi-lingual, you pull what you need from an assortment of
``UNIX tools'' like sed, awk, basename, expr, tr, who knows.  It may
be anathema to someone like yourself, if you're attracted to the idea
of a single language to do everything, but it works for some people.
The profit in it is that each tool's very limited set of features can
be expressed pretty simply.  I guess in a way this is like a conceptual
modularity.  I solve sed problems in my mental sed module, which is
really small and simple, and until I encounter a sed program in a script,
that sed module is out of the way.  So when you need text processing
features, you have the choice -- import them into the language (bash,
ksh, P***) - or find an external solution (sh, rc).  I guess this is
getting a bit far afield of the notion of scripting languages in general,
because rarely does a scripting language find itself in an environment
with these kinds of tool laying around, but my point is that the genius
of UNIX was in this kind simplicity, and the efflorescence of kitchen
sink all-purpose tools and other elephantine appliances is a more recent
phenomenon that doesn't add much.  Not everyone shares my opinion on
this, I know.

|> For an example of Tcl's lexical flexibility, see the "expect" command
|> from Don Libes' Expect package.  I think the Lisp & Scheme dialects
|> can probably do the same kind of thing, and in this way they're more
|> flexible than Python.
|
| I guess I don't see a big problem with:
|
| expect( "*number :*" )
| sleep( 1 )
| send( "r\r" )

It has been years since I used Expect, but I think the big problem is
the "expect" verb does a lot more than this.  It's kind of a big switch
statement whose branches' conditions are evaluated iteratively as input
accumulates, until one of them matches and gets executed.  Now there
would be no excuse for adding bloat like this to Python, when you can
just put in the loops and if/elif/else blocks re.matches and whatever
else it takes.  But it would be ridiculous to put a scripting language
into Expect and require its users to do all that.

| If you are going to learn expect without learning the "rest of TCL" then
| I agree. My presumption is that everyone will (or at least should be
| encouraged to) migrate from one-line commands to five-line hacks to 100
| line toys to 1000 line tools (and perhaps beyond). I think that the
| phase changes at those boundaries are actually harmful.
|
| Also, I've pushed Python's lexical flexibility to its extremes and I am
| rather glad that there is a point where it stops me! With too much
| flexibility, it becomes a matter of learning a whole new syntax with
| every module you import. More phase changes.

No argument here, I think Python has the right approach for what it is.

| In the particular case of running system commands, I would prefer Python
| to have some built-in syntax or function considering how often the task
| is performed. Importing os is admittedly somewhat annoying for a really
| tiny program.

Well, other languages that start with P do provide friendlier, more
convenient access to these functions, but there people do seriously
argue that you could almost dispense with the shell.  The Python way
seems to be more verbose and inconvenient, but that's better for large
programs and that's why we're here.  Isn't it better to have all Python
programs, large and small, share this same philosophy?

	Donn Cave, donn at u.washington.edu