Difference between `builtins.type` and `Type[Any]`

[harahu]

Bug Report

I have a protocol:

class SupportsStr(Protocol):
    def __str__(self) -> str:
        ...

Surprisingly, builtins.type is compliant with this, while Type[Any] isn't.

To Reproduce

Link to mypy playground: https://mypy-play.net/?mypy=latest&python=3.11&gist=355a1b96812a523f6e374eb8ca6f4635

Expected Behavior

I would think both should be compliant, given that the typing.Type docs states that:

Type[Any] is equivalent to Type which in turn is equivalent to type, which is the root of Python’s metaclass hierarchy.

Actual Behavior

Surprisingly, builtins.type is compliant with this, while Type[Any] isn't.

Your Environment

See link to mypy playground.

Mypy 0.960 and python 3.11

[harahu]

Turns our None is not compliant with this protocol either.

It is hard for me, as a user, to understand why, as the error message I get is highly opaque:

error: Argument 1 has incompatible type "None"; expected "SupportsStr"  [arg-type]

I'd love for the error to contain a sort of delta between the concrete type and the protocol, explaining what is missing for the type to adhere to the protocol.

@JelleZijlstra should I make separate issues for one or both of:

• None not being compliant with SupportsStr
• The error message quality

Or should we keep the discussion in here?

[JelleZijlstra]

I think make a new issue for the None/SupportsStr compatibiliity. The error message seems fine to me; it's pretty clear but just wrong.

[harahu]

The error message seems fine to me; it's pretty clear but just wrong.

Not saying it is incorrect or unclear. It is both correct and clear, as you say. I'm claiming it is opaque. It only provides one bit of information: that the types are incompatible. It doesn't provide any hint as to how one could remediate the situation. If the message also said something about why the types are incompatible, it would make it easier for the developer to do one of the following:

• Adjust the concrete type to match the protocol
• Adjust the protocol to allow the concrete type
• Write a targeted and concise bug report to mypy, should it turn out that mypy misunderstands some part of a type.

This is a very simple protocol, with only one member, so it is clear to me that the type mismatch must come from mypy's understanding of None.__str__. But I still would like to know, in the error message, how mypy thinks None.__str__ and SupportsStr.__str__ are different. And if I was dealing with a more complex protocol, I wouldn't even know at this point that the __str__ method is where I should be looking for issues. I'd risk having to go through a really annoying manual debugging process in order to work out what the issue was.

[harahu]

I think make a new issue for the None/SupportsStr compatibiliity.

Done: #13081