GeezerVison

I know we have a lot of similar definitions already, but I'd prefer to keep the stub closer to reality, maybe with just class Protocol: pass

This form is actually necessary (in some sense) since mypy will prohibit any other operations with Protocol in runtime context, like:

Protocol()  # instantiating is a runtime error
Protocol[int]  # type application is a runtime error
def make_one(cls: type) -> Any: ...
make_one(Protocol)  # passing to a function is not a good idea
def fun(x: Protocol) -> int: # Using it in type context is not a good idea either
    ...

This could be fixed by additional special-casing, but a simpler way is just make it an object().

It's special either way: if I do Protocol = object() elsewhere, mypy probably won't let me do class SupportsFloat(Protocol): pass. Using a class is at least a little closer to what Protocol actually does at runtime, even if Protocol obviously isn't a normal class.

Yes, but if I write class Protocol: ... then mypy will allow most things I mentioned above. This is why object() is used also for Generic and friends. Otherwise prohibiting all possible invalid scenarios will require a lot of effort.

Oh I see, I thought it would just ignore the implementation in the stub. Ignore this then.

Should the argument be a TypeVar bound to Type[object] or even Type[Protocol], so that type checkers will give an error when this decorator is applied to something that's not a class?

Type[Protocol] will not work, since it does not appear explicitly in MRO, but Type[object] looks like a good idea.

Why do you need the # type: ignore here?

Actually, it looks like is is not necessary anymore. The point is that Mapping is not really covariant in value (see signature of get) and mypy is deliberately very strict about such situations with protocols, however it looks like treatment of unions has changed since this was added. I will remove it just in case.

Weird, somehow this works in Python 3 but fails in Python 2, will investigate later, have to run now.

Ah, found it, the return types for values() etc. are list[_VT_co], so on Python 2 it is indeed clearly invariant in value and we need #type: ignore.

Since this is a stub, why does it need @runtime?

Otherwise mypy will complain about e.g. issubclass(it, collections.abc.Iterable) something like isinstance() can be used only with @runtime protocols.

IIUC @runtime is not defined (yet) in typing.py but (only) in typing_extensions.py?

Yes, and the same for Protocol (there is only old internal _Protocol in typing). We however need them in typeshed to avoid circular dependencies with typing_extensions. We discussed this with @JukkaL few moths ago, the plan (which I like) is this:

1. Iterate on PR Make python 2 subprocess consistent with python 3 #3132 until it's approved.
2. Publish Protocol in typing_extensions. Also include it in the stub for typing_extensions.
3. Merge PR Make python 2 subprocess consistent with python 3 #3132 but don't merge typeshed changes yet. This lets mypy users (at least those who use GitHub master) experiment with user-defined protocols.
4. Get an okay from PyCharm and Pytype that they are fine with merging the typeshed PR. They might need to implement some support for the Protocol special form first, but if they don't use the typing typeshed stub this may be a non-issue.
5. If major issues are found in the mypy implementation of protocols, fix them.
6. Release a new mypy version with protocols as an experimental feature!
7. Merge the typeshed PR and use it in mypy.
8. Seek acceptance of the protocols PEP once we have some practical experience and protocols seem to work fine.
9. Officially support using protocols in typeshed once Pytype and PyCharm are okay with it.
10. Release Protocol in Python stdlib typing module.

This PR is step number 7