Long Live Python!

[Bruce Sass]

On Thu, 12 Jul 2001, Alex Martelli wrote:
> "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.

Python, Perl, Bash, etc., have moved the nototion of scripting away
from the earlier connotations (which came first sh, or Python, Perl,
Bash, etc.)

> > $ 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:

...and if I wanted a robust, cross-platform implementation I would
write a program... but all I [just for the sake of argument] want is
to save a little bit of typing...

> 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()

Q.E.D.  ?


> 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.

... of course it depends on what the objective is.  It is silly to
claim that `Python is just as good at ... as ...' when examples like
the above are so easy to come up with.

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

Is Ok when you are in the Python Interpreter, but would you do...

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

...from the command line that comes up when you login?

Keep in mind that I never claimed Python to be inferior to anything,
just that it is a "horrible scripting language" (and am now getting
shot at for not qualifying the statement :).

> > 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.

Yes, that is sorta what I wanted to say...

> 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.

...and I deserve the virtual slap-upside-the-head for mentioning
"commandline" in that context without qualifying it...

> 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.

...then would want to argue about the difference between a "script"
and a "program".  I see it this way, if a script is only,
"Automating a sequence of operations" -- C programs are scripts --
there must be more to it, eh.


Just for fun (dictionaries are fun, but unless the majority of the
definitions agree... it is still, really, just connotation) I did:
---
$ dict "scripting language"
<...>
>From The Free On-line Dictionary of Computing (06 Jun 01) [foldoc]:

  scripting language

     <language> (Or "glue language") A loose term for any language
     that is {weakly typed} or {untyped} and has little or no
     provision for complex {data structures}.  A program in a
     scripting language (a "{script}") is often {interpreted} (but
     see {Ousterhout's dichotomy}).

     Scripts typically interact either with other programs (often
     as {glue}) or with a set of functions provided by the
     interpreter, as with the {file system} functions provided in a
     {UNIX shell} and with {Tcl}'s {GUI} functions.  Prototypical
     scripting languages are {AppleScript}, {C Shell}, MSDOS {batch
     files}, and {Tcl}.

     (2001-03-06)
---

[Ousterhout's dichotomy... mainly refers to the arbitrary
 catagorization of languages into "interpreted" vs. "compiled".]

<shrug>
At least I know I'm not alone with my OF restricted view of
what `scripting' is.


- Bruce