[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