[Python-Dev] PEP 544: Protocols (original) (raw)

Ivan Levkivskyi levkivskyi at gmail.com
Mon Mar 20 17:42:54 EDT 2017

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.totalordering), 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>

More information about the Python-Dev mailing list