[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
Thu Apr 26 22:25:28 CEST 2007
- Previous message: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
- Next message: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/)
- Previous message: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
- Next message: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]