[Edu-sig] Refocusing on Capabilities (was PySqueak)
Paul D. Fernhout
pdfernhout at kurtz-fernhout.com
Tue May 23 06:47:36 CEST 2006
All good points. And we definitely need a better infrastructure given
continual population growth -- especially one doing more with less, and
doing it in a more resilient and sustainable way. I think that is also one
of the pushes towards prototypes in "Self" -- the Self authors describe an
attempt to address the fragile base class problem and make software both
more flexible and more resilient (as well as more consistent).
And, along those lines, more updates on the PataPata (PySqueak) project:
There is now a screenshot of the 25th proof of concept at:
That should give a sense of what the whole thing does so far as the demo
is only one window (although there are also popup menus you can't see).
Note: Under Gnome, you need to change Window manager preferences so that
ALT does not drag windows (choose the Windows key instead). I have not
tested it under other platforms, though wx (2.6) should run on Mac and Win.
You may notice by looking in the browser (yellow part) of the screenshot
that I made a design decision to implement multiple-inheritance (of
traits) but using a list of name strings rather than direct pointers, so
any prototype you want to use as a parent needs to be given a name under
"world.worldGlobals". Personally, I find the most important part of
programming to be documenting *intent*, and so I thought the explicit
naming requirement was OK. I've always been dismayed at the potential of a
Self-like approach to create a real mess otherwise. (Forth us another
language system that fails at documenting intent too, though it does most
everything else right.) These named prototypes take the place of classes,
but without the class-side / instance-side divide of Smalltalk.
The twenty fifth proof of concept now can load and store Python source
files of prototypes (essentially by just writing a "define_prototypes()"
function and exec-ing it back in). There are some limits that embedded
Python objects you want to store must implement a
useful-for-reconstituting __repr__ string (though it does handle nested
dicts and lists out of the box). You can finally add and remove prototype
fields from the inspector, create new methods and edit them, and it now
has an interactive shell plus some other polish. See the code at:
An example of the Python source file it can write and read (demonstrating
the idea discussed a couple weeks back of using Python source instead of
pickle files to save widget state) is here:
You don't need it to run the P.O.C. 25 demo though; that is still
self-contained. [This example file is missing a few world methods I added
The system is still limited to two widgets though (Morph and TextMorph).
Adding more widgets is a bigger undertaking and realistically will likely
entail splitting the prototype into multiple files, which I have been
Also, functions defined in the interactive shell (as opposed to defined in
a file or defined using the inspector) don't have source code available,
which would be a problem when you save them. Not sure how to fix that
easily without changing wx's shell.py. But that's not really what the
shell is for as opposed to interactive testing or importing other Python
files, so it's a minor problem for now. For now, best to stick to defining
new prototype methods using the inspector or source files.
The system may finally be at the point where (in theory) one could use
only the system to improve itself, though in practice messing with the
wx-based GUI scaffolding by changing the main application source file
would still often be easier. Everything is still in one Python file for
ease of prototyping and people trying it, but at ~49K it's straining to
break loose into various files and who knows what else. :-) Anyway, I
definitely feel it has reached the point where it is a useful tool for
learning about prototype-based-programming in a Python context. Not my
eventual goal, but a useful byproduct.
Amazing what is easily possible by building on top of Python and not
getting sidetracked (as I usually do) by writing a new interpreter or
messing with the syntax (at least, not at first. :-) Well, that and
throwing performance and morph-loading-security to the winds. :-)
[It does point out the need for a Python VM with security flags one could
set like Java has (e.g. can't write to most files, can't open most
sockets, etc.), although I guess you could run under Jython to get some of
Still no 3D yet, though. :-(
Say, Kirby, speaking of "data rich content", can you suggest any Bucky
Fuller-ish or synergetics-type graphics or clip art under a
free-as-in-freedom license somewhere on the web I could use to spice this
demo up when I move beyond having everything in one file? Ideal would be
graphics a demo could load from the web as a URL to keep everything in one
file (though I probably should put them on another web server to be
polite, though I don't expect anybody to really use it anytime soon). Even
just graphics like the individual source items for the web page you linked to:
might be snazzy to just drag around as Morphs. Or perhaps I could try to
use them to make a HyperCard-like stack with the proof-of-concept as a
test and to motivate putting in related supporting features (including
perhaps a Bitmap-from-URL-Morph and a Card-Morph and a
Stack-Of-Cards-Morph). Also, if you have any pointers to
free-as-in-freedom Bucky-related content I could throw in such a stack,
that would be nice too. I'm mainly just looking for something that makes a
nice demo with a dozen cards worth of interesting educational content and
graphics. I could go with gardening (I've lots of stuff on that) but I
thought Bucky stuff might be more fun right now.
kirby urner wrote:
> Good thinking Paul, about the balance between optimism and skepticism.
> We do need to revisit old designs, and admit their weaknesses.
> USAers still seem in denial about their infrastructure. A lot of it's
> still good, but was meant to be maintained, not neglected.
> My hope is that infusions of data rich content will help people feel
> more in the driver's seat, in terms of at least tracking what's going
> on. Python-the-language is helping with this (at Google, other
> We want to get work done, and so we need to play, we need to make
> happen, and we need to keep track and recycle.
> Python has those capabilities: it reads like pseudo-code and so is
> suggestive and encouraging of playful exploration; in production
> settings it generally does a reliable job of handling real world
> responsibilities. [snip]
More information about the Edu-sig