[Types-sig] Why have two hierarchies? (*EUREKA!*)

Just van Rossum just@letterror.com
Mon, 7 Dec 1998 23:51:13 +0100


Niels Ferguson wrote:
>I have some observations:
>
>1) Attribute retrieval can be defined much cleaner. You currently use
>different rules to search the bases then you use to search the object. If a
>base-object is an object, why not use the standard search system.

Ok.

>Proposal:
>
>Getting an attribute is defined recursively. There are many ways to do
>this, and I don't know if the one I've chosen is the best one. (No doubt
>this needs more study.) I have split the functionality of getting an
>attribute of the object itself, and getting an attribute for one of your
>derived objects. This just seems a clean way to do things.

Yes, that's roughly what I did, too.

>I can imagine
>that you might want to change the get_attribute behaviour of one object
>without changing it for all derived objects too. (I've used my own name to
>avoid clashes with existing ideas.)

(I've stolen your "raw" idea and sort of incorporated it in my stuff as
__raw_getattr__. I don't thing I've got it right yet, tho.)

[ many good ideas snipped ]

>2) Why the named/unnamed distinction?
>In your proposal you distinguish named and unnamed objects; one returns
>bound methods and one unbound ones. Why not return bound methods all the
>time? If you really want to, you can always re-bind it, or delete the
>binding. You should certainly not use the named/unnamed distinction for
>this. If you really need it, you should have a bound/unbound flag
>somewhere. To get the full flexibility you would want to specify the
>binding of each attribute separately, not for all the attributes in an
>object in one go.

You've got a great point here. My brain is too slow today to add anything
useful to it right now.

>4) I have not made a distinction between methods and other data elements.
>All attributes that are returned are bound to an object from which they
>came. Is this how Python works at the moment?

How do you bind an integer?

This is not how Python works right now. A class' __dict__ contains raw
objects. When accessed through a class or an instance the value's type is
checked, and wrapped in a method object if we're dealing with a function.
This happens on the fly: it prevents circular references
(class->function->class). If the requested object is an instance, the
method is additionally bound to the instance.

>Compatibility:
>I'm mainly thinking about Python 2, but by choosing different special names
>I think it can be made fully compatible with the existing Python 1.5.

An additional __raw_getattr__ special method to intercept all attribute
access seems a good idea anyway, no matter what direction Python 2.0 will
go.

(Vague ideas of how to do really neat automatic delegation using my scheme
are floating around in my head. Darn! They won't sit still.)

Just