Definitely not for a shell here either, Guido. In the last week I used
an interactive Python (running in an Emacs py-mode buffer, of course
<grin>) for two new things:
1) Investigating the effect of various cache-design choices on the speed
of some memory-access patterns common in scientific programs.
This is a kind of mathematical modeling through simulation.
Interactivity is a major attraction when doing this kind of stuff
("hmm, sure didn't expect that! let's change this parameter & see
what happens then ..."). My 2nd choice for this would be ABC (which
also would have done a fine job on it), but my fingers will never
"know" the ABC editor as well as they know Emacs -- and running in an
Emacs buffer is the ultimate "history" mode.
2) Finding those integers N such that N*pi is closest to being exactly
representable in the IEEE-754 64-bit format.
Don't ask <grin -- it has to do with finding the worst cases for the
argument-reduction phase of trig functions>. This makes heavy
demands on (very) large-integer arithmetic, and interactivity was
useful mostly to run the program over a certain range, then
progressively fiddle the routine to print less and less output as the
numbers got larger & larger. Interactivity was a convenience here,
but not a necessity.
In both cases I'll echo something Steve M said: these kinds of
exploratory applications tend to grow by leaps and bounds even while I'm
running them, and Python's design makes it amazingly easy to add new
code "on the fly" in a well-structured way (i.e., in a way that's not an
inherently incomprehensible mess the next day -- Python's clean module
structure, class gimmicks, and vrbls-are-local default all seem to play
a helpful part in this -- I'm not *exactly* sure how, though <0.6 grin>).
Unlike Steve, I never use Python for something that Perl can do in under
10 lines -- I may be unique in never using Python for "system" stuff.
with-it-ly y'rs - tim
Tim Peters Kendall Square Research Corp