[Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities) (original) (raw)
Phillip J. Eby pje at telecommunity.com
Thu Apr 26 02:40:14 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 ]
At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote:
On Wed, 25 Apr 2007 18:10:23 -0400, 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'm sure everyone is already aware of the behavior of the classImplements and directlyProvides functions available in zope.interface, which exactly satisfy this use-case in the interface world.
I'm either misunderstanding Jim or you, because I don't see the relationship here. If I understand Jim correctly, he's actually asking for something like PyProtocols' "protocolIsSubsetOf" declaration -- something that would be like dynamically adding a superclass to an existing interface in zope.interface. Whereas the features you're talking about sound like declaring that a class object itself implements an interface -- something apparently unrelated to the question at hand.
- 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 ]