-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
PEP 747: More precise discussion of subtyping #4465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@@ -311,15 +311,15 @@ Assignability | |||
t1: TypeForm[int | str] = get_type_form() # OK | |||
t2: TypeForm[str] = get_type_form() # Error | |||
|
|||
``type[T]`` is a subtype of ``TypeForm[T]``, which means that ``type[B]`` is | |||
assignable to ``TypeForm[A]`` if ``B`` is assignable to ``A``:: | |||
Given two fully static types ``T1`` and ``T2``, ``type[T1]`` is a subtype of ``TypeForm[T2]`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the original wording was incorrect, but I find the new wording to be confusing because it justifies assignability only for "two fully static types". Assignability should not depend on whether either type is fully static; it should work fine for any gradual type. Maybe it's best to simply delete the preamble of this sentence (the part before the comma) and simply state that "type[B]
is assignable to TypeForm[A]
if B
is assignable to A
".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking here was that subtyping is the more "fundamental" operation; assignability follows from subtyping plus materialization. In particular, from the sentence I wrote plus the definition of assignability, your sentence follows, but not the reverse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I understand your thinking. If a subtyping rule is defined, then assignability rules are implied by it.
This section in the PEP is named "Assignability", so I guess I was expecting to see assignability rules. Your point is that the assignability rule is implied, but it might be best to spell it out here in addition to the subtyping rule.
We seem to be inconsistent in the spec currently. In most places, we spell out assignability rules without talking about the underlying subtyping rules. For example, the Callables chapter has a section named Assignability rules for callables, and it doesn't talk about subtyping. Same with TypedDict. But in the tuples chapter, we talk more broadly about "type compatibility rules" and do mention subtyping.
I don't have a strong opinion here, so I'm OK if we stick with your proposed wording.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think we have more work to do to make the spec more consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One way to sidestep discussion of the nuances of "fully static types" here, while still being correct, would be to say that for any two types T1
and T2
where T1
is a subtype of T2
, TypeForm[T1]
is a subtype of TypeForm[T2]
.
These paragraphs don't properly reflect the notion of "subtyping" in the spec. I reworded them to align more explicitly with the way assignability and subtyping are defined in the spec.
In particular, the subtyping relation exists only for fully static types. This makes the statement "TypeForm is a subtype of object" suspect: TypeForm by itself is TypeForm[Any], which is not a fully static type and therefore doesn't participate in subtyping.
📚 Documentation preview 📚: https://pep-previews--4465.org.readthedocs.build/