Skip to content

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

JelleZijlstra
Copy link
Member

@JelleZijlstra JelleZijlstra commented Jun 17, 2025

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/

@@ -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]``
Copy link
Contributor

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".

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants