Long Live Python!

[Alex Martelli]

"Bruce Sass" <bsass at freenet.edmonton.ab.ca> writes:
    ...
> The point was that python and sh operate on different levels.

So they do.  Python operates, much like Perl and most other
scripting languages, mostly by operations in the languages
itself and its libraries; sh (although bash and ksh move it a
bit away from that) basically relies on external programs.

> $ cat file*1 file*2 file*3 | tee file4 | wc -cwl >> file5
> 
> (i.e., concatenate some unknown number of files whose names match one
> of three patterns, write the result to a file and count the
> characters, lines and words, appending that result to a different
> file)
> 
> is what in Python....
> ...2 lines, 3, 4, an explicit loop, a function or two, or maybe a
> program (i.e., some imports, assignments, blocks of code, ...)?

If you do not need cross-platform operation, you can do it the
same way (except that you most always need to import...):

import os
os.system('cat file*1 file*2 file*3 | tee file4 | wc -cwl >> file5')

This, of course, is anything BUT idiomatic, because you have no
control at all -- you're delegating everything to external programs,
just like in sh.  What will happen on OS/2, Macintosh, Windows,
VMS, or a Sony Playstation?  What happens if there are too many
files called 'file'+something+'2' and you overflow the number of
arguments allowed on some older Unix-ish box?  Etc, etc.  Most
likely, one would program it differently, solidly, and portably:

import fileinput
from glob import glob

file4 = open('file4','w')
lines = words = chars = 0
for line in fileinput.input(glob('file*1')+glob('file*2')+glob('file*3')):
    file4.write(line)
    lines += 1
    words += len(line.split())
    chars += len(line)
file4.close()
file5 = open('file5','a')
file5.write("%s lines, %s words, %s chars\n"%(lines,words,chars))
file5.close()


But the fact that one CAN do it differently doesn't mean the "different"
way is inferior.  os.system and friends are there, for those times where
you want to operate this way.  So are excellent facilities for operating
differently.  It's silly to claim that giving you a choice makes Python
inferior to sh for such operations.


> Ya, I know, for some... "script" == "interpreted", for the rest of
> us... "script" == "automating a sequence of command line operations".
> I guess it was a mistake to play off that bit of ambiguousness as an
> introduction to the point.

"script"=="interpreted" seems just silly.  But where do the *command
line* operations get into the "scripting" concept?!   "Automating a
sequence of operations" seems just right.  That sh is basically able
to do it for (some) "command line" operations, but not really for ones
based on other paradigms, is sh's problem -- it doesn't define the
concept of 'scripting'.  For example, with VIM (Vi IMproved), I can use
Python for scripts, which automate sequences of editing operations
that are anything *but* "command-line" -- one doesn't *HAVE* to
resort to command-line-oriented editors (ed, ex, sed, ...) to script them,
as long as the available scripting language and infrastructure are
good enough.  sh and its descendants just _aren't_ good enough for
the kind of rich, complicated scripting tasks that Python (and, though
I loathe to admit it, Perl, Tcl, VBScript, &c) handle with ease today.


Alex



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com