[Python-Dev] Semantic of isinstance

Phillip J. Eby pje at telecommunity.com
Tue Jun 27 15:59:46 CEST 2006

At 02:49 PM 6/27/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> >>  It seems that the __class__ is only accessed in some cases, but not
> >> always, leading to what I think is a semantic inconsistency.
> >
> > It's not inconsistent - isinstance() checks __class__ in *addition* to
> > type() in order to allow proxying tricks like lying about your
> > __class__.  It therefore returns true if either your real type *or* your
> > __class__ matches, and as you can see, the real type is checked first.
>This is not the original rationale, though: the check for a __class__
>attribute on non-instance objects was introduced in r13520, to support
>ExtensionClasses. I never fully understood ExtensionClasses, but I
>believe they were not based on proxying tricks. Instead, they were
>an early version of new-style classes.

Okay, well I recall discussion on zope-dev regarding making sure that 
isinstance() would support __class__ for security proxies as 
well.  However, I do not recall from the discussion whether isinstance() 
already did this as an effect of the above, so it's possible that the 
discussion was regarding an existing behavior.

In any event, ExtensionClasses are obsolete or becoming so, but security 
proxies are an ongoing need, and lying about __class__ is used by other 
projects besides Zope.

I'm not aware of anything besides ExtensionClass that lies about __bases__, 
however, which might explain why that aspect of the behavior isn't as well 
fleshed out.

More information about the Python-Dev mailing list