[Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak

[Paul D. Fernhout]

Ian Bicking wrote:
> Paul D. Fernhout wrote:
> This is a little of what I intend with HTConsole; the objects are 
> (vaguely) live, and potentially shared.  Though I've only implemented 
> useful liveness for functions so far.  It's at conflict with the idea of 
> source code, and live objects really require an image, and I've never 
> liked images.  So I'm not sure if it's a useful path.

Ian-

Thank you for your detailed reply and I promise more thought on it, but on 
this one issue, to respond immediately, consider my earlier comments on 
images and the muse as to a potential "Pythonic" resolution. Basically, it 
is to think of the Python *image* as being defined by a Python *program* 
that builds an object world and is stored in a textual *.py file, and just 
looks and acts like regular Python source code -- ideally with comments 
preserved too. So, no pickled objects, not binary image files, just Python 
source code as readable text that rebuilds hierarchies and meshworks of 
objects.

Or, as I realized shortly afterwards, perhaps an "python image" would be 
nto jsut one *.py file, but a whole bunch of *.py files in a directory, 
some of which might be more about defining classes (when you program that 
way) and some of which are about defining specific in-use instances. So, 
the Python image saving system might use the existing tagging of Python 
objects back to file names, for example (perhaps with some extensions 
needed). This way, a "save image" essentially would rewrite your directory 
of source. A bit scary perhaps, but with subversion or such not too risky 
perhaps. And not that different in some ways from what a tool like 
BoaConstructor does (or attempts to do). And other round trip GUI 
development systems (like Delphi) do this as well to varying degrees.

The key difference of this approach might be that you were not usually 
editing the textual Python files in that directory by hand, but rather 
were using constructivist HyperCard and self-like tools to modifying a 
running Python program. Only then would you save the whole thing, to be 
able to reload next time you wanted to be in that specific environment 
defined by that directory. So, very similar to how things are done now in 
most respects, except the changes are made to the running Python object 
system, not the frozen textual representation of a pointing time of it. 
Naturally, you could still make changes by hand to the *.py files when the 
system was stopped, but if the GUI system was good enough, eventually few 
people might want to work that way for most things.

It is also risky in another way, because loading a Python program could do 
anything to you system (unless we have Python VMs with Java like security 
limits on writing to files or sockets, where the VM enforces the 
restrictions internally from security flags). But then again, a Squeak 
image could do anything to your system when you load it in too. That 
security issue just needs to be dealt with at the VM level, or at the OS 
level, or through a system of trusted sites and so on (the "we're all 
consenting adults Python philosophy", etc.). So I think it could be 
managed in practice with risk equivalent to what we have now.

--Paul Fernhout