[Python-Dev] PEP 544 and dunder methods

Guido van Rossum guido at python.org
Tue May 21 15:00:10 EDT 2019

(I did see your post in the moderation queue and let it through -- however
the mypy team, which would be most responsible for answering your question,
has been busy fighting some fires.)

I'm trying to understand what the PEP is saying and how you're
interpreting, and I'm not getting very far. I know for a fact that
Protocols work great with dunder methods. In fact the very first example in
the PEP uses `__len__` and `__iter__`, and there are several other examples
using `__iter__`, so I also know that this isn't an accident of mypy's
implementation. And mypy knows about the special rules for dunder method

So what's left to figure out is what the bullet you quote means, and
whether it should be clarified, or whether it is literally correct (about
what the implementation does).

My guess, without delving into the implementation, is that a Protocol is
*always* about the class, and that this is entirely a red herring.

Looking at the implementation (e.g. the Python 3 implementation at
doesn't give me much clarity. The code seems to be highly optimized and not
so readable. But I do see, at line 1159, what looks like the check that the
bullet refers to. The point here is simply to make sure that a protocol
doesn't inherit from a non-protocol class. Besides `object` there are
several other exceptions that appear to me to be related to internals of
the runtime typing implementation.

If you are still not satisfied, I recommend that you try to construct a
counter-example and test it against the typing_extensions modules in Python
3.7 or 3.8.



On Tue, May 21, 2019 at 8:40 AM Eric Snow <ericsnowcurrently at gmail.com>

> [originally I sent this to typing-sig but I guess it got caught up in
> moderation.]
> In PEP 554 [1] it says:
>    - Implement metaclass functionality to detect whether a class is a
>    protocol or not. Add a class attribute _is_protocol = True if that is
>    the case. Verify that a protocol class only has protocol base classes in
>    the MRO (except for object).
> The phrase "except for object" implies that having "type" in the MRO would
> not be allowed.  Was that intentional?
> Perhaps I've misunderstood semantics with typing stuff (I haven't followed
> much of the discussion), but there seems to be a disconnect with how
> special ("dunder") methods are looked up (i.e. on classes).  Effectively,
> an object's *class* has to implement the relevant "protocol".  So
> disallowing "type" in the MRO means not using the PEP's functionality for
> "special method" protocols (as well as metaclasses in general).  Have I
> understood that right?  Is that on purpose?
> Thanks for working on this, BTW.  It's a nice addition. :)
> -eric
> [1] https://www.python.org/dev/peps/pep-0544/#implementation-details
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190521/99f09f7d/attachment.html>

More information about the Python-Dev mailing list