[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
Mon Apr 30 01:01:47 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/29/07, Jim Jewett <jimjjewett at gmail.com> wrote:
Guido wrote: > 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.
As Barry pointed out, this means a class can't easily say "my parent may well implement ABC, but I don't." That special case could be added to the default overriding behavior, but ... it starts to get fragile.
That use case is very questionable, and I see it more as an anti-pattern; I suspect that it's a case of inheriting implementation where you really ought to be using containment instead of subclassing. It's why I'm uncomfortable with string.Template inheriting from a string type, and and ditto for the OO os.path proposals that have the path object inherit from a string type (I know not all of them do).
-- --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 ]