[Python-Dev] Making types behave like classes

[Gordon McMillan]

[Paul Prescod]
> These are some half-baked ideas about getting classes and types
> to look more similar. I would like to know whether they are
> workable or not and so I present them to the people best equipped
> to tell me.

[expand Py_FindMethod's actions]

>  * __class__ would return for the type object
>  * __add__,__len__, __call__, ... would return a method wrapper
>  around
> the appropriate slot, 	
>  * __init__ might map to a no-op
> 
> I think that Py_FindMethod could even implement inheritance
> between types if we wanted.
> 
> We already do this magic for __methods__ and __doc__. Why not for
> all of the magic methods?

Those are introspective; typically read in the interactive 
interpreter. I can't do anything with them except read them.

If you wrap, eg, __len__, what can I do with it except call it? I 
can already do that with len().

> Benefits:
> 
>  * objects based on extension types would "look more like"
>  classes to
> Python programmers so there is less confusion about how they are
> different

I think it would probably enhance confusion to have the "look 
more like" without "being more like".
 
>  * users could stop using the type() function to get concrete
>  types and
> instead use __class__. After a version or two, type() could be
> formally deprecated in favor of isinstance and __class__.

__class__ is a callable object. It has a __name__. From the 
Python side, a type isn't much more than an address. Until 
Python's object model is redone, there are certain objects for 
which type(o) and o.__class__ return quite different things.
 
>  * we will have started some momentum towards type/class
>  unification
> which we could continue on into __setattr__ and subclassing.

The major lesson I draw from ExtensionClass and friends is 
that achieving this behavior in today's Python is horrendously 
complex and fragile. Until we can do it right, I'd rather keep it 
simple (and keep the warts on the surface).

- Gordon