[Edu-sig] interactive vs compiled from file

kirby urner kirby.urner at gmail.com
Sat Aug 4 02:25:32 CEST 2007


> I don't see it as "either or", but as "why not allow both?".    I agree
> entirely with the strength of the REPL.  However, when going from that to
> having code saved in a file and executed, a huge step occurs (which is what
> Michael was referring to I believe) in that to see something output, the
> user *must* put in an explicit print statement.

OK, but there's a middle ground between REPL and running a .py file,
which is importing library and 3rd party modules *in shell mode*.

My preferred pedagogy (others prefer others) is to

(a) start with REPL (e.g. "using Python as a calculator")

then

(b) move on to such as 'import math' but treating the
module as a 'grab bag of tools' that we use *interactively*
e.g. math.cos(someangle).  At this point, we're ready
for graphical forms of output (e.g. VPython cylinders
and balls), possible robot control ala Logo.

then finally:

(c) standalone .py programs, perhaps taking command line
inputs ala sys.args, perhaps prompting the user with an
old fashioned menu.

(d) if we get to it:  (c) with the added benefit of a GUI.

The transition from (a) to (b) is where we handle the steps
of changing code in the module, doing a reload.

Plus we have the fun of talking about sys.path, dir() and
help(), talking about namespaces more generally,
'import foo' versus 'from foo import x as y'.

The transition to (c) involves looking at python the command
line executable, going python --h for the first time (looking
a switches).

The transition to (d) is where many a Visual Basic programmer
thinks we should *start* e.g. with some simple standalone GUI
program.

Kirby


More information about the Edu-sig mailing list