[Tutor] creating variables at runtime

[Kirby Urner]

>
>To be able to work at this level, if that's what you're saying, is mind 
>boggling.
>
>
>Erik

Well, I didn't really mean that, although I think it's quite
possible to do, if you're already a shell guru in the OS.

What I mean is, say I have this goal to generate polyhedra as
text files suitable for ray tracing by Povray (a real life
example).

I don't start by thinking about single scripts that will take
a whole lot of arguments.  Rather, I imagine myself in the
Python shell, needing a toolbox of goodies, where toolbox =
module(s).  I might write a superclass for polyhedra with a
built in .display() method, and another class for writing Povray
files that gets passed to .display() as an argument -- but then
I'll do the importing, instancing and argument passing myself,
as the "driver" or "pilot", with my Python "controls" and
"instruments".

Like, I'll just boot IDLE and go:

    >>> from polys import *
    >>> from povray import Povray
    >>> ico = Icosa()       # hmmmmm, I'd like an Icosahedron today
    >>> ico.showfaces = 0   # but just show me edges and corners
    >>> outfile = Povray("myfile.pov")  # this'll be the output file
    >>> ico.display(outfile)   # ico, write yourself to the file
    >>> outfile.close()        # I'll close the file myself (might
                                 have dumped more shapes into it).

Then I'll boot Povray and render the icosahedron.

According to the script mentality, I'd go to an X Window or
DOS box and do something like:

  % > python makepoly.py Icosa, nofaces, myfile.pov

or something like that.  I'd be imagining gcc (a C++
compiler) which has pages and pages of command line
switches -- the idea being that "launch time" is your
one chance to tell the program everything it needs to
know -- or maybe it'll prompt you through a bunch of
steps.  Or else you think you have to wrap the whole
thing in a Tk GUI or something -- not supposing that
the interactive shell provides a middle ground.

Using Mathematica might be a good analogy.  You do a
lot of the work at the command line, asking for stuff.
Want the 10th bernoulli number?  Just ask for it, put
it in a variable.  Want to get this definite integral?
Just type it in and hit enter.

It's like the difference between APL and FORTRAN in
my college years (long ago).  FORTRAN was batch programming.
I'd punch a stack of cards (icky) and they'd go through
a card reader with a bunch of other programs (JCL cards
in between to tell the jobs apart), and 20 minutes later,
the line printer would come back with my results (and/or
bug reports).  APL was on a CRT, and I'd sit at the
keyboard, enter a weird-looking expression that might
do quite a lot in one line (like Python can), and zingo
zango, I get a result immediately.

If I want to batch a bunch of statements in an APL program,
I do so as part of my session (can save a workspace too).
They're probably short programs that build on each other.
The feeling is of crafting an environment, a workspace,
and importing stuff you don't have the time or ability
or patience to write yourself (modules, Standard Library).

That's how I best like to use Python.  It's also how I
like to learn/play with Python.  Enter stuff and get an
immediate reply.  I think from a learning standpoint,
having an interactive shell makes a *huge* difference.

APL, Logo, Scheme, LISP, Python, FoxPro all have this
feature -- Visual Basic to some extent in its lame
'immediate' or 'debug' window.  Java and C++ natively do
not, although some have written dynamic C interpreters.
And as for Java, one reason people like Jython is the
ability to work with Java class interactively, in a
shell.  It helps 'em learn regular Java.

Kirby