[Python-ideas] check interfaces, isducktype(X, A)

Andrew Barnert abarnert at yahoo.com
Wed Dec 4 09:19:30 CET 2013


On Dec 3, 2013, at 21:22, Gregory Salvan <apieum at gmail.com> wrote:

> Sorry Andrew, I'm not sure to understand all your point.
> I don't believe it reimplements things of ABC, or I don't see what.

Almost everything you did reimplements features of ABCs. The builtin isinstance and issubclass functions can check whether you implement the methods of a type, and you can override that by explicitly declaring that you implement the type. That's the core feature set of your proposal, and of ABCs; you've just implemented the same thing with a different API, plus and minus a few minor details.

If you haven't read PEP 3119, you really should. (It's also worth reading rejected predecessors like 245/246 and successors like 3124, and of course the pre-existing third party stuff like PyProtocols and the Interface types in Twisted and Zope.)

> I agree ABC solution is the cleanest, whereas I would be able to check functions, stay on a runtime checking and being free to define or not a kind of protocol.

I don't understand what you mean here. ABCs can check methods. They do so at runtime. You're free to define or not define any protocol you want.

What you have to add is checking the argspecs of the methods rather than just their names. That's a great idea, but it's a much better idea as an addition to what's already there than as a complete parallel API to very similar functionality. And if this were added to the stdlib, I'm pretty sure it would be a modification/extension of the abc module, not a competing and similar but not identical module.

> Before reading your comments on ABC, I've released the python version of "isducktype": https://github.com/apieum/ducktype
> I've modified some behaviours within your comments and made it more stable.
> 
> It would be interesting to have the version wich use ABCMeta, so I'm going to implement it. 
> I've thought to name it SignedMeta, or ProtocolMeta, any opinion ?

First, it sounds like you're focusing on the wrong part of the name--ABCMeta is a metaclass for implementing ABCs; leaving out the ABC part sounds like you're designing a metaclass for something completely unrelated.

Less seriously, ProtocolMeta sounds like it's going to add more PyProtocols-style functionality (in particular, adapters from one protocol to another), but there's only so many synonyms available and they're all taken, so I don't think that's a major problem. As for SignedMeta, I don't even know what that's meant to imply. Is it to do with method signatures? If so, I think "signature" is a better word; you don't really think about anything being "signed" in a method signature; that's dragging in associations from a different meaning of the word.

But I don't have any better suggestions. Protocol, interface, prototype, type, abstract type, abstract base... As I said, all of the names have already been used up, repeatedly, and none of them have any particular connotations that would explain how your module, metaclass, function, etc. differ from abc. 

In fact, I'd probably just come up with a stupid package name like abc2 and stick in modules named abc, collections.abc, and numbers and expose names identical to the stdlib ones, so I could play around with it by just using abc2.isinstance, abc2.abc.ABCMeta, abc2.collections.abc.Mapping, etc. Or I could just toss some "from abc2 import"s around. But for any serious use beyond playing around, that would be quite confusing.

> 2013/12/3 Nick Coghlan <ncoghlan at gmail.com>
>> On 3 December 2013 04:42, Andrew Barnert <abarnert at yahoo.com> wrote:
>> > Shouldn't this be tied to ABCs rather than redesigning and reimplementing
>> > most of ABC to add a little bit on top?
>> 
>> This seems like an apropos place for this link:
>> http://docs.python.org/3/library/abc#abc.ABCMeta.__subclasshook__
>> 
>> That's the existing "formalised ducktyping" hook, that already allows
>> things like the following:
>> 
>> >>> class MyClass:
>> ...     def __len__(self):
>> ...         return 0
>> ...
>> >>> from collections.abc import Sized
>> >>> isinstance(MyClass(), Sized)
>> True
>> >>> issubclass(MyClass, Sized)
>> True
>> 
>> The advantage ABCs have over ducktyping alone is that subclassing and
>> explicit registration allow ambiguities like the one between the
>> Sequence and Mapping interfaces to be resolved (you can't always just
>> ducktype those, as they have the same methods - they differ only in
>> how the __*item__ methods handle slice objects).
>> 
>> Cheers,
>> Nick.
>> 
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131204/693f8e95/attachment-0001.html>


More information about the Python-ideas mailing list