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

[Guido van Rossum]

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