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