Paul D. Fernhout wrote:
> Ian Bicking wrote:
>
>>That's very hard to implement...
>
>
> Probably true, at leas to do it in a human readable way.
>
>
>>For instance, imagine the user does this:
>>
>> x = [1, 2]
>>
>>Then they get a handle on that [1, 2] list (we'll call it OB1) and do
>>"OB1[0] = 5". How do we represent that as source? Because they are
>>acting on actual objects, not bindings, and OB1 doesn't have any name,
>>nor will it exist at the same address in a second run of the program.
>>
>>In order to turn this into source, you'd have to keep track of how you
>>can repeatably get to OB1 (I guess you'd see that it was named "x"
>>through source introspection?), and then translate operations on that
>>object into source that does operations on the path to that object.
>>
>>I think doing this generally becomes infeasible, though you can get
>>close through successively more bizarre source code generation, until
>>you end up with something that looks like a Python-source version of
>>pickle, and even that won't work very well.
>
>
> Just as reference to Squeak Smalltalk, it has a "changes" file that
> records each top level Transcript type interaction (equivalent to a Python
> shell in many ways) so that these can be replayed if you need to rebuilt
> an image from the last version you saved if there was a crash. That's not
> what I am proposing here.
>
> But to address your specif example, maybe it does point to a paradigm
> shift. Is this what you would do in an interactive session for your example?
> >>> x = [1, 2]
> >>> OB1 = x
> >>> OB1[0] = 5
> >>> del OB1
> >>> x
> [5, 2]
> >>> OB1
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> NameError: name 'OB1' is not defined
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.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
_______________________________________________
Edu-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/edu-sig
