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

[Just van Rossum]

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