[Python-Dev] Making types behave like classes

[Paul Prescod]

Gordon McMillan wrote:
> 
>...
> 
> 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? 

You can store away a reference to it and then call it later.

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".

Looking more like is the same as being more like. In other words, there
are a finite list of differences in behavior between types and classes
and I think we should chip away at them one by one with each release of
Python.

Do you think that there is a particular difference (perhaps relating to
subclassing) that is the "real" difference and the rest are just
cosmetic?

> >  * 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. 

Type objects also have names. They are not (yet) callable but I cannot
think of a circumstance in which that would matter. It would require
code like this:

cls = getattr(foo, "__class__", None)
if cls:
    cls(...)

I don't know where the arglist for cls would come from. In general, I
can't imagine what the goal of this code would be. I can see code like
this in a "closed world" situation where I know all of the classes
involved, but I can't imagine a case where this kind of code will work
with any old class.

Anyhow, I think that type objects should be callable just like
classes...but I'm trying to pick off low-hanging fruit first. I think
that the less "superficial" differences there are between types and
classes, the easier it becomes to tackle the deep differences because
more code out there will be naturally polymorphic instead of using: 

if type(obj) is InstanceType: 
	do_onething() 
else: 
	do_anotherthing()

That is an evil pattern if we are going to merge types and classes.

> Until
> Python's object model is redone, there are certain objects for
> which type(o) and o.__class__ return quite different things.

I am very nervous about waiting for a big-bang re-model of the object
model.

>...
> 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).

I'm trying to find an incremental way forward because nobody seems to
have time or energy for a big bang.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.activestate.com/pythoncookbook