Py2K wishes

[Neel Krishnaswami]

Paul Prescod <paul at prescod.net> wrote:
> 
> I'm saying that we could expose the fallback mechanism so that an object
> could be instructed to fallback to another object.

Do you mean that you want to make Python's object system prototype
based, a la Self & Cecil? (In those languages, instead of having base
classes, an object has /parents/, which are other objects which are
searched when a lookup in the object fails and so on recursively. 
There are no distinguished classes -- everything is an object. I 
am told Javascript is also prototype-based, but I don't know it.)

I believe you can get what you want with metaclasses right now, but
they are unpleasantly difficult to write. (The concept isn't that hard
imo, it's just that Python makes you jump through hoops to play with
it. Compare to Smalltalk, where subclassing Class is dead easy.)

In the short run, the two things that you need to make this easy are
to allow the __bases__ lookup to use any object that satisfies the
sequence protocol, rather than necessarily a tuple. Add to that
__dict__ attributes that are arbitrary mappings rather than actual
dictionaries, and you're cooking with gas. (If you read Guido's
metaclass essay, you'll see that all the work he goes through are to
enable these two little changes.)

There's precedent for this -- in 1.5.2 Python changed so that you can
assign a new __bases__ tuple to a class at runtime, whereas in 1.5.1
it was fixed for a class.

In the slightly longer run, there's a need to figure out what the
instance and class protocols are, exactly, and then expose the
mechanism to the user. In Smalltalk, the difference between class and
instance is substantially a matter of convention (if one the compiler
knows about too). It would be nice if Python could move in the same
direction, IMO.


Neel