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

[Guido van Rossum]

On 4/25/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" <pje at telecommunity.com> wrote:
> >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.
> >
>
> Ugh, you're at least half right.  I didn't read the implementation of
> ABC.meets carefully enough to notice that it's actually an adapter
> registry, not just a predicate (meets seems like a funny name for that
> method).
>
> classImplements would have satisfied the adapterless use-case by letting
> Jim declare that someone else's class definition actually implements the
> feature set that some unit of code he wants to use that class with is
> expecting.
>
> With the adapter registry, I don't see why this isn't just PEP 246 adapt()
> (if I am reading one of your later mails correctly though, you think it is
> too).
>
> I'm not particularly familiar with protocolIsSubsetOf, but it wouldn't
> surprise me at all if it could also satisfy this use-case.  There are
> lots of ways to do this, many of them fairly simple.  Using inheritance
> is the part that makes it hard, since inheritance is controlled by the
> wrong party in most cases and comes with unrelated features that are,
> at best, irrelevant to the particular use case and at worst actively
> detrimental.
>
> I'm sure a way around this can be invented, I just don't see why it
> should be.

JP, would you mind dropping this and instead considering how we could
turn isinstance and issubclass into (poor-man's) GFs by allowing
classes to define class methods __isinstance__ and __issubclass__?
(Though the arguments are reversed so to avoid confusion perhaps the
names should be different, similar as with the 'in' operator and the
__contains__ magic method.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)