[Edu-sig] Common Graphical Framework for Python Tutorials?

[Paul Fernhout]

John Glossner wrote:
> So this is still totally unsatisfying because now
> he still does not know what he is typing. However,
> he can at least use the Python interpreter, emacs,
> and Linux. We will struggle through the programming
> part together and eventually he will be able to
> fly on his own but the learning curve is tremendously
> steep. However, just wait until he graduates to
> Zope (which after 3 months I'm still restling with!!!).

One of the difficulties in using Python for education is that it depends
on the host environment for many things -- editor (emacs, TK/IDLE,
notepad), window system (COM, Delphi, TK, wxWindows, etc.), running
issues (command line, IDE) and so on.  So, even the simplest tutorial
has to make a commitment to one system. If for example, a tutorial
explains Emacs and Linux shells for running Python, it won't be
immediately useful for a student trying to use IDLE/TK.

For Kirby's excellent lesson plan involving numbers and shapes, one
might expect it to come with step by step screen shots of what the
Python environment screen should look like at each stage. This is
problematical if people are using various editors, debugging approaches,
and widget sets. 

Squeak Smalltalk http://www.squeak.org is another system designed in
part of education and use by children that solves some of these problems
by creating an entire virtual environment.  In short, the VM is written
with a common set of primitives. Some of these define a simple surface
which bitmaps can be drawn on. Others define simple sound and network
interfaces. From there, the entire system (graphics, windows, debugger,
compiler, version control, code browsers, update system, 3D graphics,
TTS) is written in Smalltalk. This machine dependent part is only around
2000 lines of code or so, and has already been ported to over a dozen
platforms (Mac, Win32, WinCE, Acorn, Solaris, Linux, etc.) All of the
rest of the VM code is written in a subset of Smalltalk, and then is
translated to C for performance. 

There are some difficulties for beginners with using the Smalltalk
system because so much of the source is immediately available. It is not
clear which parts are more important and which are rarely needed.
Another system like LearningWorks            
http://learningworks.neometron.com/ 
(created using VisualWorks Smalltalk) addresses this by creating custom
browsers that hide much of the source unrelated to the current learning
task.

Now I'm not suggesting people here who like Python move to Squeak or
LearningWorks. Python's modularity, commercial usage (including Zope web
application server), indentational syntax, integration with C, and
familiar functional notation (similar to C or BASIC) make it a good
choice for education. Python does strike a nice balance. Python is a
very approachable language with an extensive set of libraries that can
be learned in bits and pieces as needed.

But, I might suggest that for a common curriculum to evolve around
Python, it would be very advantageous to have the same sort of virtual
environment like Squeak has. Then tutorials would look completely
consistent for any learner. 

How could Squeak and LearningWorks be useful to the Python learning
effort? It might be possible to create a platform independent graphics
environment for Python by leveraging the part of Squeak that was machine
dependent (so as to not reinvent that wheel). It might instead be
possible to somehow integrate the Python compiler into the Squeak
environment, with some sort of inter-object translator, so that one
worked in Python on top of Squeak but had access to all the Smalltalk
tools and yet was cross platform. Squeak is completely open source, so
integrating the Python VM bytecode interpreter alongside the Smalltalk
bytecodes would be doable. If one got going on this, one might also be
able to add support for other languages as well on top of this common
cross platform (object) layer. It might also be possible to adapt some
of the LearningWorks ideas of customized learning browsers to
interacting with tutorial tasks. 

The alternative is to focus on making IDLE the learning environment to
use. That might be a good choice. But, I've always believed TK/TCL has
added an extra burden to learning to use Python for GUI work -- there is
just something a little awkward about it (probably mostly due to the TCL
layer). That is improving with better documentation, but it still IMO
lacks the elegant seamless integration on might otherwise desire.
However, perhaps that is all resolveable.

When one starts building more sophisticated tutorial environments, some
of these integration issues might become more problematic. For example,
for a very long time I have had difficulties debugging TK apps under
IDLE, as there are (were?) some issues related to who thought they were
the top level application. If even such a simple issue was problematical
-- then what will happen when one has very fancy complex systems that
entail single stepping graphics and other program threads and so on? For
example, consider implementing something like:
  Http://Apsymac33.uni-trier.de:8080/Lisp-Course
This is an adaptive Lisp tutor on the web. But, imagine it running under
TK and trying to teach you TK programming. What would be the
implementation issues?

Underlying another aspect of this difficulty when creating tutorial
systems is that the common (and preferred) method of defining a Python
program is as a text file (where often order of definition matters,
given side effects of executing Python code as files are loaded).
Something about this way of working makes me less likely to use the IDLE
class browser for example. This is a very different mind set than
imagining a program as something that lives as a collection of functions
in a development environment (like most Smalltalk programs) -- where
files are just used for backup and transport.

Obviously in John's case, he went with Emacs for editing Python text
files (although perhaps is using IDLE too?) Why did you not just go with
IDLE for everything?

Also, it is quite likely that for complete programming novices, there
will need to be many levels of tutorial which have nothing to do with
Python programming syntax, but involve perhaps a more graphical type of
programming. These early levels would introduce very basic concepts
anyone on this list would take for granted. For example, an early
exercise might be putting notes on a musical staff to make a musical
"program" showing the relation between sequence and effect. Making those
earlier tutorial levels widely available requires a common graphics (and
probably sound, etc.) platform.

There is obviously a tension here -- Python is so useful in part because
it interoperates so well with a wide variety of systems, giving the user
a lot of choice. And obviously, the issue of TK as the common graphical
framework comes up every year.
I'm just wondering how that flexibility will interact with using Python
for education. 

-Paul Fernhout
Kurtz-Fernhout Software
Chappaqua, NY
=========================================================
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com