PEP 747: Updated to reflect the latest round of feedback #4204
Conversation
| of ``TypeForm[T]``. This was ultimately rejected because there are ways to | ||
| create an object of type ``type[T]`` that does not encode a valid type expression. | ||
| For example, the expression ``type[1]`` is not a valid type expression. Likewise, | ||
| the expression ``type[S]`` is not a valid type expression if ``S`` is an | ||
| out-of-scope type variable. This same argument applies to other special forms |
There was a problem hiding this comment.
Although I agree with the conclusion that type[T] should not be a subtype of TypeForm[T], I don't think this argument makes sense. type[1] and type[S] do not "create an object of type type[T]" in the first place, so they are irrelevant here. They do create an object of type types.GenericAlias, but we are not discussing here whether types.GenericAlias should be a subtype of TypeForm (it should not).
The type type[C] is inhabited by the Python type/class object C and its subclasses. Example expressions that evaluate to an object of type type[C] are C or C().__class__. Note that none of these expressions use the type[...] syntactic form, because we are also not talking here about whether type[C] should be a subtype of TypeForm[type[C]] (it clearly should not.)
The intuitive reason for thinking that type[C] might be a subtype of TypeForm[C] is that the expression C both evaluates at runtime to the class object C (which inhabits the type type[C]) and is a valid spelling of the type C. The reason type[C] is not a subtype of TypeForm[C] is that the expression C().__class__ also evaluates at runtime to the class object C (which inhabits the type type[C]) but is not a valid spelling of the type C.
Since this PR has already landed, I can put up a PR with my suggested changes to this argument.
| out-of-scope type variable. This same argument applies to other special forms | ||
| like objects of type ``UnionType``, which may or may not encode a valid type | ||
| expression. Rather than carving out a special case for ``type[T]`` that would | ||
| allow for potential unsoundness, it was decided to treat all type forms |
There was a problem hiding this comment.
I also don't think there is any possible unsoundness that could result from making type[T] a subtype of TypeForm[T], because the runtime objects that inhabit type[T] (the Python type/class object T and its subclasses) must already be handled by any function taking TypeForm[T], since a type/class object named by a valid type expression and one named by an invalid type expression are indistinguishable at runtime. The argument for making type[T] not a subtype of TypeForm[T] is a purely theoretical one, deriving from the requirement that only a valid type expression can evaluate to a TypeForm[T] type.
3 participants
microsoft/pyright#9397 (reply in thread)
PEP 123: Summary of changes)📚 Documentation preview 📚: https://pep-previews--4204.org.readthedocs.build/