[Python-Dev] PEP 544: Protocols

[Ivan Levkivskyi]

On 20 March 2017 at 22:11, Matthias Kramm <kramm at google.com> wrote:

> I'm a big fan of this. I really want structural subtyping for
> http://github.com/google/pytype.
>
>
I am glad you like it.


>
>
On Mon, Mar 20, 2017 at 5:00 AM, Ivan Levkivskyi <levkivskyi at gmail.com>
> wrote:
>
>> Explicitly declaring implementation
>> -----------------------------------
>>
>> To explicitly declare that a certain class implements the given protocols,
>>
>
> Why is this necessary? The whole point of ducktyping is that you *don't*
> have to declare what you implement.
>
> I get that it looks convenient to have your protocol A also supply some of
> the methods you'd expect classes of type A to have. But completing an
> implementation in that way should be done explicitly (via including a
> utility class or using a decorator like functools.total_ordering), not as
> side-effect of an (unnecessary) protocol declaration.
>

I would put the question backwards: do we need to *prohibit* explicit
subclassing?
I think we shouldn't. Mostly for two reasons:

1. Backward compatibility: People are already using ABCs, including generic
ABCs from typing module.
If we prohibit explicit subclassing of these ABCs, then quite a lot of code
will break.

2. Convenience: There are existing protocol-like ABCs (that will be turned
into protocols) that have many
useful "mix-in" (non-abstract) methods. For example in case of Sequence one
only needs to implement __getitem__ and __len__ in an explicit subclass,
and one gets
__iter__, __contains__, __reversed__, index, and count for free. Another
example is Mapping,
one needs to implement only __getitem__, __len__, and __iter__, and one
gets __contains__, keys,
items, values, get, __eq__, and __ne__ for free.

If you think it makes sense to add a note that implicit subtyping is
preferred (especially for user defined protocols),
then this certainly could be done.

--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170320/9c16c311/attachment.html>