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

[Gregory Salvan]

Thank you for taking time to answer.
I trust you, but I've sometimes the feeling we're talking about different
things.

I didn't know PEP 3124 and PEP 0362, they are great ressources. Signature
is particularly usefull, it's a pity it's not documented, I'll suggest
something further.

I'm ok with what you said (I talked effectively about signatures).
The matter I see, is that attributes and methods can be set dynamically
(that's why I talked about runtime), either I don't manage these cases, or
I have to extend ABCMeta and override __instancecheck__ and
__subclasscheck__.
The second solution would make duplicate code unless I extract ABCMeta
cache and registry operations in a dedicated object.
This would be a lot of change and despite _abc_* attributes are protected,
I'm afraid some library use them.

I've made an example of failure to illustrate dynamic setting matter:
https://gist.github.com/apieum/7800992
Maybe it's more effective for attributes which are often defined in
__init__ uniquely.

Whereas all of this is really interesting we are quite far from the initial
target which was simply to avoid these cases:
>>> class MyClass:
...     def __len__(self, enum):
...         return 0
...
>>> from collections.abc import Sized
>>> isinstance(MyClass(), Sized)
True
>>> issubclass(MyClass, Sized)
True
>>> len(MyClass())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __len__() missing 1 required positional argument: 'enum'


I'll dig if I can find a better proposal considering all you suggestion.




2013/12/4 Andrew Barnert <abarnert at yahoo.com>

> 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/20131205/14472989/attachment-0001.html>