Skip to content

PEP 718: Specify binding, parametrisation and overload interactions #4649

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
Gobot1234 wants to merge 5 commits into
base: main
Choose a base branch
from
+50 −4
Open

PEP 718: Specify binding, parametrisation and overload interactions #4649

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a33030f
hopefully final round of changes
Gobot1234 Oct 8, 2025
475bd8e
I think fix the build issues?
Gobot1234 Oct 8, 2025
bd36a62
Fix title too short
Gobot1234 Oct 8, 2025
1ba67e9
fix some grammar typos and build
Gobot1234 Oct 8, 2025
4d33729
Update peps/pep-0718.rst
Gobot1234 Oct 14, 2025
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
Prev Previous commit
Next Next commit
fix some grammar typos and build
  • Loading branch information
@Gobot1234
Gobot1234 committed Oct 8, 2025
commit 1ba67e9605ebbdfa5793497e1d9c51eb911ee741
44 changes: 12 additions & 32 deletions peps/pep-0718.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -201,28 +201,9 @@ The following code snippet would fail at runtime without this change as
Interactions with ``@typing.overload``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Overloaded functions should work much the same as already, since they have no effect on
the runtime type. This change will lead to more expressiveness with user's able to
decide and the behaviour/overload can be specified by the developer rather than leaving
it to ordering of overloads/unions.

.. code-block:: python

# N.B. `class bytes(Sequence[int]): ...` and `Foo` is a non-specified generic type
@overload
def seq_first[T: Sequence[int]](x: T) -> T: ...
@overload
def seq_first[T: bytes](x: T) -> Foo[T]: ...

@overload
def bytes_first[T: bytes](x: T) -> Foo[T]: ...
@overload
def bytes_first[T: Sequence[int]](x: T) -> T: ...

reveal_type(seq_first(b"")) # type is bytes
reveal_type(bytes_first(b"")) # type is Foo[bytes]

Explicit specialisation will restrict the set of available overloads
Overloaded functions should work much the same as they already do, since they do not
Copy link
Member

@JelleZijlstra JelleZijlstra Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is about the runtime behavior of calling overloaded functions?

affect the runtime type. Explicit specialisation will restrict the set of available
overloads.
Copy link
Member

@JelleZijlstra JelleZijlstra Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth spelling out in detail how this would work. What I'd expect is that if the function is subscripted, only those overloads are considered for which the subscription may succeed. So if you have an overload make[*Ts], one with make[T], and one with just make, then a call to make[int] will only consider the first and second, and a call to make[int, str] will only consider the first. This could be another step in the overload resolution spec before all the current steps.


.. code-block:: python

Expand All @@ -232,33 +213,32 @@ Explicit specialisation will restrict the set of available overloads
def make(x: str, y: str) -> tuple[int, int]: ...

reveal_type(make[int](1)) # type is int
reveal_type(make[int]("foo", "bar")) # Invalid: no overload for `make[int](x:str, y: str)` found, a similar overload exists but explicit specialisation prevented its use
reveal_type(make[int]("foo", "bar")) # Invalid: no overload for `make[int](x: str, y: str)` found, a similar overload exists but explicit specialisation prevented its use

Functions Parameterized by ``TypeVarTuple``\ s
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Currently type checkers disallow the use of multiple ``TypeVarTuple`` \s in it's
generic parameters, however it is currently valid to have a function as such
Currently, type checkers disallow the use of multiple ``TypeVarTuple``\s in their
generic parameters; however, it is currently valid to have a function as such:

.. code-block:: python

def foo[*T, *U](bar: Bar[*T], baz: Baz[*U]): ...
def spam[*T](bar: Bar[*T]): ...

This PEP does not allow similar functions to be subscripted, for the same reason as
defined in :pep:`PEP 646<646#multiple-type-variable-tuples-not-allowed>`.
This PEP does not allow functions like ``foo`` to be subscripted, for the same reason
as defined in :pep:`PEP 646<646#multiple-type-variable-tuples-not-allowed>`.

.. code-block:: python

foo[int, str, bool, complex](Bar(), Baz()) # Invalid: cannot determine which parameters are passed to *T and *U. Explicitly parameterise the instances individually
spam[int, str, bool, complex](Bar()) # OK


Binding Rules
^^^^^^^^^^^^^
Subscriptions on methods (including classmethods, staticmethods etc.) should only have
access to their function's type parameters and not the enclosing class's. Subscription
should follow the rules specified in :pep:`PEP 696<696#binding-rules>` methods should
be bound on attribute access.
Method subscription (including ``classmethods``, ``staticmethods``, etc.) should only
have access tos their function's type parameter and not the enclosing class's.
Subscription should follow the rules specified in :pep:`PEP 696<696#binding-rules>`;
methods should bind type parameters on attribute access.

.. code-block:: python

Expand Down
Loading