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.

Sign up for GitHub

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
Open

PEP 747: More precise discussion of subtyping #4465

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions peps/pep-0747.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

if ``T1`` is a subtype of ``T2``::

def get_type() -> type[int]: ...

t3: TypeForm[int | str] = get_type() # OK
t4: TypeForm[str] = get_type() # Error

``TypeForm`` is a subtype of ``object`` and is assumed to have all of the
Any specialization of ``TypeForm`` is a subtype of ``object`` and is assumed to have all of the
attributes and methods of ``object``.


Expand Down