On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: > On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 4/25/07, Jim Jewett <[EMAIL PROTECTED]> 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 > > [email protected] > > 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
