Ian- Maybe we are still thinking about different things here.
I'm going on the presumption that Python, like Smalltalk, have various "roots" which are things like (in Python) the loaded modules, the active threads and their stacks, and perhaps some other state. A Python world of objects is defined by these, since if any Python objects exist but are not reachable somehow, they can't effect the system. As I reflect on that, I can see how in theory outside forces that get a handle into object memory might make changes and such things might exist in other processes or threads, but that would just be a broken VM (or VM abstraction) to me more than a problem to solve. :-) So, going on this assumption that all Python objects of interest are reachable from these roots (even if some of the roots themselves might be only known to the VM, like the current thread?) then a recursive procedure can flow down through from these roots and write one big text file consisting of mainly: # big module import lots_of_stuff temp1 = object() temp1.__class__ = Point temp1.x = 10 temp1.y = 20 temp2 = object() temp2.__class__ = Point temp2.x = 40 temp2.y = 50 temp3 = object() temp3.__class__ = Rectangle temp3.origin = temp1 temp3.extent = temp2 modules.mymodule = object() modules.mymodule.__class__ = Module # or whatever? modules.mymodule.myrect = temp3 And so on. Now obviously this gets tedious, so an optimizing writer would instead produce: # module mymodule myrect = Rectangle(Point(10, 20), Point(40, 50)) But that's a matter of a smart writer, which I think is doable. Just think of it as like optimizing code (although maybe in reverse. :-) Now the problem you point out, that there may be several ways to reference an object is obviously a real one. But a smart writer should handle that (with a little handwaving by me. :-) But essentially, like with pickle, the writer would know it has to write the definition for a function out somewhere, and so it would pick a good spot, and then other references to that function could refer back to the first place it was defined. (Or it could be put in a temp variable which was later deleted after it was done being used.) Even if the writer picked a bad spot, the problem would only be that the code looked harder to read and understand, not that it would not recreate the same objects in memory that were written out (though perhaps at different locations; I'm presuming that would not matter -- if it did, then that might be a problem requiring VM changes or some fancy object creation order footwork, which would almost certainly mess up the code's readability). As I've just casually glanced at the CPython VM source code, and only just a bit more at the Jython code, I don't know enough off hand to see whether there might be other bigger problems. Anyway, I still don't see a show stopper (unless it is specific object ids or exact memory locations being important -- perhaps affecting dictionary hashes or some such thing?). Difficulties yes, maybe painful ones, but no showstopper so far as I can see to writing out running code as Python files (again, unless the above object ID issue). I can see that nicer source will likely result from tracking commands as the user defines them, as you suggest. But still, my focus isn't on readable source. That's more a nice to have feature from my set of priorities for GUI oriented construction and programming. What I am more interested in is, can the running program be changed, and can the changes be saved so they can be reloaded? So, our priorities may diverge there, but that's OK -- makes life interesting. :-) --Paul Fernhout Ian Bicking wrote: > Interactive sessions are source. The OB1 I referred to is the actual > object in memory, which has no real name, though it can be referenced > directly in memory. > > Maybe a better example is something in HTConsole right now. Any > function you can get your hands on in HTConsole is editable, in-place. > So you can do: > > >>> import random > >>> random.choice > > And you'll get a form that shows the source to that function, and lets > you edit it. That works fine in-memory. But saving that is hard. > > There's actually lots of ways to get access to a function. When you get > random.choice, you are actually getting access to a method of a > singleton stored in the random module. When you edit that, you are > editing the method. How do you represent that edit as source? Do you > see that the function is available as random.choice.im_func, or > random.Random.choice? Or a property, which might be available as > SomeClass.some_property.fget. There's lots of paths to functions, and > the function alone doesn't necessary know how to get to it. And > functions are relatively easy; other objects can be much harder... > > >>> items = range(5) > > The contents of items cannot be edited in place, because they are > recreated dynamically. They can only be modified by later commands. > > Keeping a log of commands is possible. But you aren't editing live > objects anymore, except perhaps an illusion of that. Instead you are > generating saveable commands from a specific location, which are > immediately executed to give you feedback but also saved so they can be > replayed in the future. > > As I've been thinking about this, I think command generation is pretty > much like direct source modification, but direct source modification > also leads to nice source. So that's why I'm thinking that live objects > isn't a good metaphor, after going down that path some. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
