On 4/25/07, Jean-Paul Calderone wrote:

On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" wrote:

...

At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote:

...

On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett 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/)