[Python-Dev] Semantic of isinstance (original) (raw)

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