On 4/25/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> > wrote: > >At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: > >>On Wed, 25 Apr 2007 18:10:23 -0400, 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'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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
