Saturday, August 04, 2007

sa: Pedagogy

My approach to Python is four-stepped: (0) REPL (1) import this or whatever (2) py files (3) GUI.

More memorable: "birth in the shell" like Venus; personal growth and enrichment (putting some flesh on those bones); savings for the future (crunchy py files, snake food in site-packages); then, more optionally, life as an officer in user space, a diplomat, nuanced and event-oriented.

Decoded, what this means is:
  • go for instantaneous feedback first, savoring the joys of a shell, which not every language offers.
  • then enrich your default environment with Standard Library and 3rd party imports, still in shell mode
  • now take your knowledge of the syntax and start cutting and pasting to more permanent .py files, which Python tries to interpret as job orders, work assignments (remember to schedule R&R).
  • finally, in step (3) we explore the event-driven paradigm, which in our stack depends on OO for its metaphors.
For REPL, I've been using IDLE. Yes, there's WingIDE 101, yes there's GNU emacs or any standard text editor. These days, Python is straight ASCII, so standard ASCII-based tools will work well.

In Python 3.x, we're acquiring more "color depth" by giving more nuance to the "color scale" (allowing more characters). I use the color analogy because we've already taken the step from 16 and 256 colors to millions of colors, and know what a positive difference that makes.

IDLE also sports a decent text editor, in addition to shell mode (REPL).

Partly why I use IDLE is it's the IDE most tightly bundled with Python other than the terminal mode shell. Plus it motivates an informative discussion of widgets, as in "widget libraries."

Economists used to use "widget" to mean "gizmo we needn't describe" (just an abstraction), but in software engineering, widgets are those "gooey geegaws" we call popups, drop-downs, radio buttons, check boxes -- all the interface paraphernalia currently associated with standard office business applications.

Python avoids specifying any particular look and feel by leaving it to widget librarians to define their own bindings. By the time we get to step 4, in other words, Python is already completely specified.

IDLE is built on the Tk widgets library. I do some storytelling at this point. Were we using wxPython's IDE, which I'm certainly not averse to doing, we could talk about the C++ widget library under its hood, wxPython playing a similar intermediary role to Tkinter's.

If you find this explanation "clear as mud" (an old Texas expression), consider trying this alternative one, posted recently on edu-sig.