Reason given for disallowing non-concrete subtype assignment is unsound

Issue

According to the discussion https://github.com/python/typing/discussions/1305, “type checkers allow incompatible __init__ overrides, because flagging them would be too disruptive.”

Accepting above as de facto, the example given as the main reason for disallowing non-concrete subtype assignment in the following section of the spec is unsound:
https://github.com/python/typing/blob/e08290b70f58df509f998cbbe09a8e65abb57a9b/docs/spec/protocol.rst#type-and-class-objects-vs-protocols

class Proto(Protocol):
    @abstractmethod
    def meth(self) -> int:
        ...
class Concrete:
    def meth(self) -> int:
        return 42

def fun(cls: type[Proto]) -> int:
    return cls().meth() # ???
fun(Proto)              # Why should this error?
fun(Concrete)           # OK

var: Type[Proto]
var = Proto    # Why should this error?
var = Concrete # OK
var().meth()   # ???

(credit https://github.com/python/mypy/issues/4717#issuecomment-1978239641 for pointing out the contradiction)

Thoughts

One radical approach would be to remove the concreteness rule from the spec altogether. The type of Proto is type[Proto], and if the constructor compatibility is not checked, there is little reason to disallow it from being assigned to variables annotated as type[Proto].

If that is too radical, the spec can stay as is but the reasoning and associated examples should be clearly marked ‘historical’ and no longer valid. That way, we can avoid any immediate changes in practice, but at the same time encourage discussions towards appropriate future specs.

先从 docs/spec/protocol.rst 中链接的“type-and-class-objects-vs-protocols”部分开始，然后阅读链接的 typing discussion 和 mypy issue，以了解相关的论证依据。该 issue 提出了相互竞争的方向，而不是一项已经确定的变更；只有在就规范作出一致决定，并随后更新论证依据和相关示例后，才能算完成。