[Types-sig] Why have two hierarchies? (*EUREKA!*)
Just van Rossum
just@letterror.com
Sun, 6 Dec 1998 00:52:13 +0100
I wondered:
>>What is a DAG?
Evan replied:
>Directed Acyclic Graph,
Yeah right, like that would help a poor graphic designer <wink>.
>>Not sure about this one myself. The easy way is to keep doing what we've
>>always done:
>> MyClass.foo(MyClass, ...)
>
>Since when have we been able to do this?
Oops, sorry. Freudian slip of the keyboard. I meant something like "The
easy way would be to do it like we call an unbound method, but with the
class instead of self." (insert above example)
>we could write:
>
>object a(A): #or a = class (A):
> foo = 1
> def bar(): pass
Ok, I see. Time for a tough one: if we fetch a function from an unnamed
object out of its own namespace, should we bind it so self? Might me
probematic if you want to store raw functions in self.__namespace__.
>>Right, this is exactly what I meant with __instantiate__ above.
>
>Wait, I read you as saying that __instantiate__ *or* __init__ would be
>called, but not both. If you meant that they get called in sequence, I
>agree.
Hm, I just realize I misread you. I meant:
- If you call a named object (ie. a class), that object will be searched
for an __instantiate__ method. If found, call that. It should handle the
whole instantiation and return an object. Maybe even something else... If
not found, default instantiation occurs.
- If you call an anonymous object (ie. an instance), ask it for a __call__
method. If not found: raise an exception.
Whereas you meant something entirely different:
>a subclass, or an instance of a subclass would get "birthed". Only the
>instances get __init__'ed, just as now. Under your scheme, after all, the
>only difference between subclassing and instantiation is whether the result
>is a class (has a name). The birth hook lets you handle new objects before
>anyone else gets to see them.
Right. Good point. Will think about it.
Just