Paul D. Fernhout wrote:

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.

That's very hard to implement... 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. This is all not to say that modifying Python source in a manner different than ASCII is infeasible. Only that "source" and "runtime" have to be kept separate to keep this process sane. Images -- which mingle the two -- have never felt sane to me; clever, but not manageable. Unfortunately we do not have very good abstractions in Python related to source, so they have to be invented from scratch. The AST might help, but higher-level abstractions are also called for. For instance, you might define a color interactively in some fashion, and the color gets serialized to: import color color.Color(r, b, c) That color object might be immutable (probably should be), but the *source* isn't immutable, and the source means something. How can we tell what it means? I can imagine a bit of interaction between the source and the runtime to do this. For instance, we might see that "color" is bound to a specific module, and "color.Color" to a specific object. We'll disallow certain tricks, like binding "color" dynamically, monkeypatching something into "color.Color", etc. Ultimately figuring out exactly what color.Color is isn't *easy*, but at least it is feasible. Using existing introspection we can figure out some parts, some of the sorts of things that IDEs with auto-completion figure out. They can figure out what the arguments to Color() are and the docstring. But, you can also imagine adding an editor or other things to that object; a richer form of __repr__, or a richer editable form than the ASCII source. Maybe there would be a flag on Color that says it can be called without side effect (meaning we can speculatively call it when inspecting source); and then the resulting object might have something that says it can be displayed in a certain way (with its real color), and has certain slots you can edit and then turn into a new Color invocation. This is where the 'make' syntax starts to come into play again, or more generally where declarative source comes into play. Take a typical non-declarative module, like optparse: parser = OptionParser() parser.add_option('-v', '--verbose', action='store_true', dest='verbose', help='Be verbose') There's nothing there that looks like a literal; the first call to OptionParser isn't very interesting, all the structure is in later parts. This on the other hand: make OptionParser parser: make Option verbose: """Be verbose""" aliases = ['-v'] action = 'store_true' dest='verbose' that is really a much more fully-formed piece of source that can be understood as a complete piece; you could add methods to OptionParser and Option to make this usefully editable. (Or use generic functions to avoid having to modify those objects to give them rich source representations) Sometimes declarative structures are in conflict with runtime dynamicism, but I don't think they have to be. The declarative form doesn't make the .add_option() method obsolete; it just offers a static form for the most common case where you statically construct the options. There also might be a hint of static typing here -- an OptionParser source editor might suggest an option to add another Option, and so it will be bound to the Option class specifically; but it's just important to leave in the same generality in the source editor as the original source has. That is, OptionParser should defer to Option for the 'verbose' key that's already set. This is all harder than what HTConsole is doing currently, mostly because Python source introspection is much poorer than Python object introspection.

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).

Loading a Python program can already do anything, if you put the commands at the top-level (not in a function). So Python source really is focused on constructing objects -- even functions and classes are *built* by the source, not declared by it, and so circular imports and circular class references can be challenging as a result. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

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 / ianb@colorstudy.com / http://blog.ianbicking.org

Ian Bicking wrote:

This is all not to say that modifying Python source in a manner different than ASCII is infeasible. Only that "source" and "runtime" have to be kept separate to keep this process sane. Images -- which mingle the two -- have never felt sane to me; clever, but not manageable.

Well, perhaps sanity is overrated. :-) And Smalltalk has been managing this for thirty years. :-) But it is true, it requires a bunch of special purpose tools. Changeset browsers. A change log. External source code control. Image cloners. and so on. Probably a Python that stored a running image as Python program files might need some specialized tools too. And I will go further and agree that I find mixing running application state (like what windows are opened or what the stack looks like) with application data (your email, your accounts receivable) is pretty scary too. But again, one needs some sort of tools to help you with that, and there is no reason some things can't be in the image and other things not in it. In a Smalltalk system, generally there is at least a file with library source code and a file with user additions to that as a current change log. Although in the case of Squeak, it can decompile methods (if it saves comments) even if you don't have the source code. One of the people on the project (Alan Kay or Dan Ingalls?) quipped something to the effect that a Squeak image was really a source code compression algorithm with a development environment thrown in for free. But, a Smalltalk image is generally saved as binary objects. But now that disk is cheap and cpu cycles plentiful, storing an image as python program files seems OK to me resource-wise.

Unfortunately we do not have very good abstractions in Python related to source, so they have to be invented from scratch. The AST might help, but higher-level abstractions are also called for. For instance, you might define a color interactively in some fashion, and the color gets serialized to:

import color color.Color(r, b, c)

That color object might be immutable (probably should be), but the *source* isn't immutable, and the source means something. How can we tell what it means?

I'm not sure anyone needs to ever tell what that means, except the Python parser when it reads in the code and runs it (in the context of other code it also loaded). Obviously when code is being written out which can reconstruct a current object tree, then the writing process needs to understand what it means by each piece of code, especially as it might refer to previously defined bits to shorten or make more readable the output code file. But since it is writing the code, there should not be any ambiguities of intent. The hardest issue perhaps becomes making the results look as close to human written Python as possible (say, using "class" to define a class instead of making a plain object and turning it into a class by setting fields).

I can imagine a bit of interaction between the source and the runtime to do this. For instance, we might see that "color" is bound to a specific module, and "color.Color" to a specific object. We'll disallow certain tricks, like binding "color" dynamically, monkeypatching something into "color.Color", etc. Ultimately figuring out exactly what color.Color is isn't *easy*, but at least it is feasible.

Using existing introspection we can figure out some parts, some of the sorts of things that IDEs with auto-completion figure out. They can figure out what the arguments to Color() are and the docstring.

Perhaps you are thinking about this from the point of view of something like PyDev parser, which reads Python code to syntax highlight it and perhaps provide code assistance. But, since the code has already been read, and we are manipulating the object tree directly, we know what everything means, because we just look at what the objects are directly by inspecting them. Granted, some of those objects represent code, and the code may be wrong or ambiguous or confusing from the users point of view, but that is ignorable by the code writer, which just writes out the snippet of code the way a user put it in.

But, you can also imagine adding an editor or other things to that object; a richer form of __repr__, or a richer editable form than the ASCII source. Maybe there would be a flag on Color that says it can be called without side effect (meaning we can speculatively call it when inspecting source); and then the resulting object might have something that says it can be displayed in a certain way (with its real color), and has certain slots you can edit and then turn into a new Color invocation.

I can see the value of all this from the GUI side, with various desired display options defined in the class or prototype. But again, Python object are (or should be :-) constructible from scratch without calling a class' init function. So, given that a writer can inspect an instance and just write out all the fields in its dictionary and their values it seems like we can write out any object (though perhaps it may need to recursively write out parts of embedded objects first, and then perhaps patch up circular references at the end).

This is where the 'make' syntax starts to come into play again, or more generally where declarative source comes into play. Take a typical non-declarative module, like optparse:

I like what you outline and I see how something like it could make the code the output writer creates be more legible.

This is all harder than what HTConsole is doing currently, mostly because Python source introspection is much poorer than Python object introspection.

Good point. And perhaps an area of Python that this project could work on? Can you elaborate on what parts of source introspection might need the most work and in what ways so that either programs or people can better inspect running Python programs?

Loading a Python program can already do anything, if you put the commands at the top-level (not in a function). So Python source really is focused on constructing objects -- even functions and classes are *built* by the source, not declared by it, and so circular imports and circular class references can be challenging as a result.

True. But, the writer should be able to figure out how to handle this, perhaps using some sort of recursive process with a patch list and a cleanup routine? --Paul Fernhout

Ian Bicking wrote:

Zope went down that path with through-the-web development with the ZODB as the image. I think everyone agrees that didn't work. Smalltalk has pursued that with more vigor, but I was never comfortable with the image. In some ways you can read my comments as me figuring out just why I dislike the image model.

Well, everyone? :-) Check out http://www.1010wins.com/ for what was, last I heard, a major Zope site. Still, a lot of peopel agree with you, so there are clearly issues here. For all I know, that group is unhappy? I myself like images you can build from text when you want to, but that has never been the focus of most Smalltalks (and isn't for Squeak so far). But, I think a truly Pythonic approach might insist on building objects from text, although it is true that we have pickle, which uses text, but not as a Python program.

I think it's important to figure out, because the image model seems very compelling for an education environment.

And John also made some of those points indirectly. I think from a "classroom" standpoint, teachers generally want to be in control of what the student sees, at least at first, and they also have short classes ("45 minutes) where they do not want to waste time on configuration. So, preparing an image for kids and seeing it pop up exactly like you made it, whatever the hardware (like Squeak can do) is a big win in a classroom setting. Of course, I'm not big on conventional classrooms :-), but I think images are desirable for independent or informal learning as well, which can happen in fits and starts, where you might do something intensely for days and then not revisit something until months later. And it would be nice if everything was just the way you left it. Also, as a developer of (hopefully open) educational simulations, I see the value in being able to deploy the simulation as an image which people could then modify to their own needs. So this is an area of overlap regardless of educational paradigm. Granted though, if you want to learn about the details of the machine you are on, or the notion of a software stack, like Kirby pointed to a week or two ago, in terms of getting into the specifics of GNU/Linux, then images are hiding stuff you might want to make visible. (Of course, you could open a terminal window from your running image. :-) I think a big issue with "images" is that they presume that you will put in the time to learn the tools assembled in the image (assuming the image is mainly about learning programming) rather than use some older ones you are comfortable with already. It is much easier to type text on the command line or use your favorite text editor than to learn an IDE (especially when you are learning a new language at the same time). But the value of learning an IDE can be immense in terms of letting you manage complexity far beyond what you can do with a text editor. It is funny how we can all accept that learning to play a musical instrument like the flute might take years of concentrated study to even get a good "tone" out of it, but we expect computers to be engaging on a minute by minute basis. Or, we just accept that learning to touch type takes days of practice. But computer IDEs? Do they really need to be like video games, engaging and addictive from the first quarter? John Holt wrote on this when he talked about "hard fun" (also mentioned here recently in another context I think) and how playing music, considering the suffering involved to get good at it, could hardly be described as "fun", but there certainly is something there for many people that keeps it engaging as a transcendental experience (as a sense of "flow"). Still, I think people here are right when they suggest typing at the command line an doing text processing produces feedback that keeps people engaged. The question is, can a graphical IDE do that, and I think the answer with Self might usually be "yes". I think the answer with "Squeak" is sometimes "no" though, but I have real experience with that, and have still never used Self. :-) Still, the "E" in CP4E is about "Everyone", so I can see the value in trying to make things accessible to broader audiences. My hope is that both the expert and the novice can be satisfied by a better system, and I think "Self" (or to a lesser extent "Squeak") helps show that way, prudcing a system I can love as an expert, but (taking their word for it, at least for Self :-) I think novices can warm to quickly as well. That gets back to the point I made on innovation -- satisfying both needs at once (e.g. expert and novice both love it) rather than compromising somewhere between them (e.g. not so hard for novices, but not so interesting for experts).

...

I can see the value of all this from the GUI side, with various desired display options defined in the class or prototype. But again, Python object are (or should be :-) constructible from scratch without calling a class' init function.

I don't understand what you mean here? Most objects aren't constructible from scratch. Many objects are immutable, and can only be recreated, not modified.

OK, good distinction. But the immutable ones are (always?) recreateable from code? And the rest can be made by creating a bare object "object()" and filling in its dictionary? I get errors when I try that though:

...

...

x = object() x <object object at 0xb7e503b8> class Foo: ... pass ... x.__class__ = Foo Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __class__ must be set to new-style class, not 'classobj' object

I do not yet understand that error.

I guess, there might also be objects that wrap external resources like sometimes handles to bitmaps where those resources could not be accessed? In Smalltalk, this is handled in part by the distinction between "new" and "basicNew", e.g.: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/057790.html where "new" may call initialization methods with various side effects (often just "self basicNew initialize"), but "basicNew" just gives you the object of that class without much data in it (so you can call initialize yourself or do something else). The message "basicNew" is what is used typically by Binary Object Streaming systems when objects are recreated, then they fill in the fields from what is in the file.

...

So, given that a writer can inspect an instance and just write out all the fields in its dictionary and their values it seems like we can write out any object (though perhaps it may need to recursively write out parts of embedded objects first, and then perhaps patch up circular references at the end).

You mean pickle?

Well, a pickle-like system that writes out (hopefully readable) Python program code, yes.

There's a bunch of pieces.

Thanks for the elaboration on this. I need to think more on these points you raise. Still, it seems your focus here in what you outline as outstanding issues is more on reading and preserving and otherwise handling human written source code or the complexity of a large multi-module textually defined program (which is understandable for you are writing an IDE in a sense, where you want to give the user/developer help *before* the program is running) then reading and preserving objects (where source code may be just part of what is stored, and the user/developer is given help *while* the program is running). Perhaps the difference is that with an IDE you care more about how the objects are going to be created (given you are helping the user to write programs to do just that), whereas with saving and reloading an image I just care about anything that works and is marginally understandable for debugging the save/load process, expecting the coding to be done within the IDE on a fine grained basis (i.e. you are just look at one function at a time in a browser, like in Smalltalk, rather than scrolling through a file). Not to say producing clean readable Python programs as images isn't a good goal down the road for me, but clearly with an IDE it is your upfront goal. I think an innovative convergance comes if a new system with an image works well enough that people would choose using it to program over just editing long text files. --Paul Fernhout

Paul D. Fernhout wrote:

Ian Bicking wrote:

...

Zope went down that path with through-the-web development with the ZODB as the image. I think everyone agrees that didn't work. Smalltalk has pursued that with more vigor, but I was never comfortable with the image. In some ways you can read my comments as me figuring out just why I dislike the image model.

Well, everyone? :-) Check out http://www.1010wins.com/ for what was, last I heard, a major Zope site.

Still, a lot of peopel agree with you, so there are clearly issues here. For all I know, that group is unhappy?

There's a general consensus in the Zope community that through-the-web editing and putting application code in the ZODB wasn't a good idea. So they've moved on to other means of development, mostly with files on the disk. At the same time, they've also moved away from the ideal of a web development environment accessible to beginning programmers, which was at least an early Zope goal. Though Plone is probably the exception to both of these. My impressions -- direct and indirect -- of what happens with typical projects stored in the ZODB, is that they just had all of the normal software engineering problems. But they weren't able to take advantage of all the work people were doing in other environments -- version control, Python's code layout (modules, packages, etc), and all the other tools developers use. And maybe that's the only problem (though I think there are others). On the measure of tools alone Smalltalk should be fine, as they've written their own full stack of tools, even though at the same time they pretty much isolate themselves from the mainstream of tools. I also hate the idea of extending Object, which is common in Smalltalk (and Ruby, with no image), and my distaste for that might tinge my feelings on images. Zope didn't add that, but it has its own ways of introducing that same kind of complexity that I dislike.

...

I think it's important to figure out, because the image model seems very compelling for an education environment.

And John also made some of those points indirectly. I think from a "classroom" standpoint, teachers generally want to be in control of what the student sees, at least at first, and they also have short classes ("45 minutes) where they do not want to waste time on configuration. So, preparing an image for kids and seeing it pop up exactly like you made it, whatever the hardware (like Squeak can do) is a big win in a classroom setting. Of course, I'm not big on conventional classrooms :-), but I think images are desirable for independent or informal learning as well, which can happen in fits and starts, where you might do something intensely for days and then not revisit something until months later. And it would be nice if everything was just the way you left it. Also, as a developer of (hopefully open) educational simulations, I see the value in being able to deploy the simulation as an image which people could then modify to their own needs. So this is an area of overlap regardless of educational paradigm.

I think there's a lot of practical problems with that. What happens when you find a bug in the image? How do you figure out where code came from? Is it system code, teacher code, peer code, your own code? If you edit system code, you've made your image incompatible with anyone else's image, and anyone who imports your change will probably be corrupting their image. And when you have this big ball of an image, the student has to choose which line of continuity they want -- do they keep their code, or throw it all away for the next class? I'm all for making tight bundles of code with controlled environments; that's important for everyone, not just classrooms. But there's another line of control, which is how you integrate new packages into that environment, and how you extract packages, and how you update packages. A classroom should be as ready to do all of these things as professional programmers, because they actually share all the same basic needs -- fixing bugs, applying workarounds, sharing code, making code reasonably portable (if only, for instance, to allow the teacher to run it in their own environment). Software engineering tools and methodology can be hard to adopt (even for professional programmers), but there's also a lot of good ideas in there that apply much more widely than just software. So I think it's worth keeping all those processes in mind.

John Holt wrote on this when he talked about "hard fun" (also mentioned here recently in another context I think) and how playing music, considering the suffering involved to get good at it, could hardly be described as "fun", but there certainly is something there for many people that keeps it engaging as a transcendental experience (as a sense of "flow"). Still, I think people here are right when they suggest typing at the command line an doing text processing produces feedback that keeps people engaged. The question is, can a graphical IDE do that, and I think the answer with Self might usually be "yes". I think the answer with "Squeak" is sometimes "no" though, but I have real experience with that, and have still never used Self. :-)

Programming is definitely hard fun, and like music some people are very much drawn to it and overcome all the hardness without being that bothered. That probably describes the majority of the open source community. But most people don't pursue music that seriously, even given the opportunity -- hard fun isn't very fun for most people and for any particular domain. I don't know if everyone has a hard fun that's right for them, or not. I wish everyone had something, but unfortunately I suspect that enjoying hard fun is itself something that not everyone is prepared to do.

OK, good distinction. But the immutable ones are (always?) recreateable from code? And the rest can be made by creating a bare object "object()" and filling in its dictionary?

I get errors when I try that though:

...

...

...

x = object() x <object object at 0xb7e503b8> class Foo: ... pass ... x.__class__ = Foo Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __class__ must be set to new-style class, not 'classobj' object

I do not yet understand that error.

you can't turn a new-style class into an old-style class by reassigning __class__, but otherwise you can mess with that attribute pretty freely (or mess with __class__.__bases__). object() also happens to not accept attributes, though any subclass of object will. I'm not sure what the justification is for that.

I guess, there might also be objects that wrap external resources like sometimes handles to bitmaps where those resources could not be accessed?

Yes, that's very common. In general pickle-able objects can be recreated; you can do the same basic thing with the new module, like new.instance(Foo), and then update its __dict__ -- remembering that assigning to attributes might not work, since those attributes might be properties that expect the __init__ to have been called. The object may register itself or do other things in __init__ as well, so it's really hard to be sure you are doing the right thing. Really, it's all the same issues pickle has, and pickle also has some special methods so that most objects can be made pickleable. Some things like open file objects just can't be pickled at all, ever -- though often you can make a pickleable wrapper that fulfills some more abstract purpose, and use pickle's hooks to keep from trying to pickle that objects entire __dict__ (which probably contains the unpickleable file object).

...

There's a bunch of pieces.

Thanks for the elaboration on this. I need to think more on these points you raise.

Still, it seems your focus here in what you outline as outstanding issues is more on reading and preserving and otherwise handling human written source code or the complexity of a large multi-module textually defined program (which is understandable for you are writing an IDE in a sense, where you want to give the user/developer help *before* the program is running) then reading and preserving objects (where source code may be just part of what is stored, and the user/developer is given help *while* the program is running). Perhaps the difference is that with an IDE you care more about how the objects are going to be created (given you are helping the user to write programs to do just that), whereas with saving and reloading an image I just care about anything that works and is marginally understandable for debugging the save/load process, expecting the coding to be done within the IDE on a fine grained basis (i.e. you are just look at one function at a time in a browser, like in Smalltalk, rather than scrolling through a file). Not to say producing clean readable Python programs as images isn't a good goal down the road for me, but clearly with an IDE it is your upfront goal. I think an innovative convergance comes if a new system with an image works well enough that people would choose using it to program over just editing long text files.

In part I want to avoid a disconnect between the two styles of development. This was another problem with Zope -- people would start with the image/ZODB development, and then it was a really big leap to get to the file-based development. So there was two classes of Zope users, and they didn't always understand each other. Also, I don't want to have to recreate version control tools, or Python's module system, or the ability to share code freely, or any of that stuff. I think a good way to avoid any problems with these tools and processes is to just stick to conventional program representations. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org

Paul D. Fernhout wrote:

...

...

I think that Ian's suggestion is the most sensible strategy for proceeding in that direction and continuing to maintain community interest in a PySqueak inclined towards Self-like prototypes and a related GUI for constructivist educational use (and other general use as well). And if metaclasses turn out to not be the best approach, still anything simple which preserves the Python syntax while giving the new features (say, having all prototypes inherit from a common class which overrides __getattr__ and __setattr__ to simply look into the instance to find data and behavior?) I think it could be easier than that. I think a lot of the more declarative programming I do really has prototypes underneath it. (Ironically in Javascript I never find a need for prototypes, except to simulate classes.)

Of course, you probably don't have a Self-like environment for Javascript. :-) Or is there one? I've never done much with JavaScript.

There are some more sophisticated development environments for Javascript, but I've never used any of them, only source editing.

Anyway, I tried to follow your example, but I am still left confused as to how it is easier than creating GUI tools that manipulate all instances of just one Prototype class? Your example still seems focused on making classes. With one class, a few lines of code to search for values through parent slots and you're done? Essentially, for any prototype-ish work, one would just work with instances of this one class. Am I missing somethgin vital here? Are you thinking about one class per one prorotype object? Is that for performance reasons?

I think my example confused you, since "class" was a misnomer. That is, you *can* subclass non-classes using the class statement. I was using that to mean "clone and update". I.e.: class foo(bar): def spam(self): print 'hi' That means "clone bar, and set foo.spam to this function". The use of the class statement is a little confusing, which is why I would like a make statement. To get to mechanics, basically this class statement means: foo = bar.__metaclass__('foo', (bar,), {'spam': spam_func}) So with the right fiddling you can "subclass" an instance. Anyway, I like the syntax, and find it more comfortable than direct assignment (especially for methods). For direct assignment, you might find the "magic_set" decorator I wrote useful: http://svn.colorstudy.com/home/ianb/ruby_blocks.py (toward the bottom) It lets you do: @magic_set(foo) def spam(self): print 'hi' which handles the closure to add instance methods directly to instances (which doesn't work if done just through assignment), among other assignments. It uses the name of the first argument (self, cls, or anything else) to determine what kind of function you are trying to create. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org

Ian- Thanks again for this pointer. I've added two more proof of concept files to PataPata. The second one demonstrates inheritance with a parent and two children, as well as graphically displaying the morphs. See: http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_00... I started trying to do it in OpenGL (which I have had working before) and got some errors so punted and chose wx and 2D for that. I don't like making initial proof of concepts that rely on too many dependencies. OpenGL remains a real possibility down the road, but this one problem just shows how installation issues can bite you (in this case, I had commented out the driver for it in my xorg.conf file when I was having other problems related to one of my two ATI cards having problems driving its secondary display head, and didn't care to restart X in the middle of my development to try fixing that.) The third P.O.C. demonstrates the problem your solution addresses. http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_00... I found two other variants of solutions on the web (differences include are who does the wrapping etc.), and I need to decide how best to proceed on that. Links to these three options including yours: http://svn.colorstudy.com/home/ianb/ruby_blocks.py http://zephyrfalcon.org/weblog/arch_d7_2002_11_16.html http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html [The latter two are more specific to Prototype inheritance in Python.] Going to be traveling much of next week, so probably not much more activity on this for a while. Frustrating to me as I think this is just picking up some speed. A little OpenGL, a few Self-like GUI widgets for inspecting values like in the movie of just rectangles and lines and text, using a wrapper approach for inserting methods into prototypes, adding a remote debugging process perhaps derived from Idle, making some program writing code derived from pickle perhaps, dropping in some bitmap and icon content from our garden simulator, and the result might be a nice proof of concept constructivist educationally-oriented system in a week's work or so. Obviously not everything, and with very rough edges, but something that could show the basic ideas. Sigh. With distractions, and part-time, be nice to get all that together by the end of June, if that, realistically. No promises though. Thanks again for your feedback. --Paul Fernhout Ian Bicking wrote:

For direct assignment, you might find the "magic_set" decorator I wrote useful: http://svn.colorstudy.com/home/ianb/ruby_blocks.py (toward the bottom)

It lets you do:

@magic_set(foo) def spam(self): print 'hi'

which handles the closure to add instance methods directly to instances (which doesn't work if done just through assignment), among other assignments. It uses the name of the first argument (self, cls, or anything else) to determine what kind of function you are trying to create.