[Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities) (original) (raw)

Guido van Rossum guido at python.org
Sat Apr 28 16:54:58 CEST 2007

On 4/28/07, Calvin Spealman <ironfroggy at gmail.com> wrote:

On 4/26/07, Guido van Rossum <guido at python.org> wrote: > On 4/25/07, Jim Jewett <jimjjewett at gmail.com> wrote: > > The current ABC proposal is to use isinstance as the test; Jeffrey > > Yaskin's numbers PEP highlighted the weakness there with a concrete > > example. > > > > If you need to an abstraction less powerful than an existing ABC, > > you're out of luck; you can't just assert that the existing class is > > already sufficient, nor can you expect everyone else to use multiple > > annotations. > > I now have a proposal to allow overloading isinstance() and > issubclass(), by defining special (class) methods on the second > argument. See http://python.org/sf/1708353. Does this need a PEP? The > unit test shows that it can be used to support the use case described > above: > > > class ABC(type): > > def instancecheck(cls, inst): > """Implement isinstance(inst, cls).""" > return any(cls.subclasscheck(c) > for c in {type(inst), inst.class}) > > def subclasscheck(cls, sub): > """Implement issubclass(sub, cls).""" > candidates = cls.dict.get("subclass", set()) > return any(c in candidates for c in sub.mro()) > > > class Integer(metaclass=ABC): > > subclass = {int} > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) _> ________________________ > Python-3000 mailing list > Python-3000 at python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: http://mail.python.org/mailman/options/python-3000/ironfroggy%40gmail.com

I'm just going to jump into this and voice a concern that allowing overriding of isinstance and issubclass seems like a Bad Idea. They should be trustworthy and predictable, and allowing classes to change how objects are considered instances of them seems like the wrong thing to do. I'm not saying that I don't think it should be done, but that it feels quite wrong. When I do, rarely, use isinstance or such, and I need to check isinstance(f, Foo), I know exactly what I am saying. But if Foo can change the meaning of that, can I trust it anymore? Not everything should be dynamic. I am not sure which side of the fence this falls on, but right now, in my mind, it teeters right on the fence itself.

Note though that only the second argument to either function can overload the rules. IOW if you write isinstance(x, C), there is no way that x could attempt to lie; but C could. Similar for issubclass(D, C) -- only D can change the outcome. Whether or not a particular class overload these functions ought to be part of its documentation. The builtins won't be overloading them; you will be able to trust e.g. isinstance(x, int). But it might be true that isinstance(42, Ring) if Ring overloads isinstance -- however you will have been duly warned of this possibility.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list