(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 lookup. 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 https://github.com/python/typing/blob/master/typing_extensions/src_py3/typin...) 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. Thanks! --Guido On Tue, May 21, 2019 at 8:40 AM Eric Snow <ericsnowcurrently@gmail.com> wrote:

[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@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?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>