> 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 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
