PEP 718: Specify binding, parametrisation and overload interactions by Gobot1234 · Pull Request #4649 · python/peps

Gobot1234 · 2025-10-08T15:10:31Z

Change is either:
- To a Draft PEP
- To an Accepted or Final PEP, with Steering Council approval
- To fix an editorial issue (markup, typo, link, header, etc)
PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

📚 Documentation preview 📚: https://pep-previews--4649.org.readthedocs.build/

python-cla-bot · 2025-10-08T15:10:35Z

All commit authors signed the Contributor License Agreement.

Gobot1234 · 2025-10-08T15:13:35Z

Please can someone get the CLA bot to re-run? I'm not sure why it's requesting that email TBH. I've already signed it for my email gobot1234yt@gmail.com

Sorry I can't test I can't get make installed

defjaf · 2025-10-08T16:29:13Z

I don't think that the word "subscription" is being used correctly.

hugovk · 2025-10-08T16:32:58Z

Please can someone get the CLA bot to re-run? I'm not sure why it's requesting that email TBH. I've already signed it for my email gobot1234yt@gmail.com

You committed with your Git client configured with that email, see https://github.com/python/peps/pull/4649.patch

You also need to sign it with that.

JelleZijlstra · 2025-10-10T00:05:01Z

-the runtime type. The only change is that more situations will be decidable and the
-behaviour/overload can be specified by the developer rather than leaving it to ordering
-of overloads/unions.
+Overloaded functions should work much the same as they already do, since they do not


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

JelleZijlstra · 2025-10-10T00:06:23Z

-of overloads/unions.
+Overloaded functions should work much the same as they already do, since they do not
+affect the runtime type. Explicit specialisation will restrict the set of available
+overloads.


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.

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

PabloRuizCuevas · 2025-11-04T13:35:01Z

@Gobot1234 please if you need help don't hesitate to ask, I'm very interested on this feature and would be a pity to see it abandoned

PabloRuizCuevas · 2025-11-10T09:54:18Z

@JelleZijlstra Is there something I can do to move the needle on this PEP if the original author don't reply in a reasonable amount of time? like contributing to the writing of this PEP?

JelleZijlstra · 2025-11-10T14:49:13Z

@Gobot1234 is still around, I'd wait a bit longer. But this PEP has been sitting for a long time and as I've written on Discuss before, I personally have some reservations about it. If you're interested in renewing the discussion and addressing the concerns that have been raised about the PEP, you could work with James to improve the PEP, or even write your own replacement PEP.

PabloRuizCuevas · 2025-11-11T04:51:32Z

@JelleZijlstra I already wrote James in Discourse, in GitHub and in private offering my help on September, after that he did reappear (but didn't particularly requested my help).

Now is almost a month without updates from him and I would really like to see this coming in python 3.15 (if is approved etc ofc), given that he did vanish for more than a year last time (look in discourse the message of Guido on 7 May 2023), I think is reasonable to move forward with the PEP after almost a month without updates from him. So how can I do my own PEP replacement / edit this? Would I count with your sponsorship or the original one from @gvanrossum ?

thanks in advance

JelleZijlstra · 2025-11-11T05:23:24Z

You'd need a new sponsor. I'm not currently interested in sponsoring a version of this PEP, but another core dev might be.

Gobot1234 · 2025-11-11T09:52:41Z

@PabloRuizCuevas I'm happy to review stuff for it and would happily add you as a co-author. I just don't really have the time/motivation to finish it as my usage of python is so little nowadays

gvanrossum · 2025-11-11T17:31:08Z

Alas, I can't take on sponsoring a new PEP either. But I will continue to fulfill my promises on the old one.

As a sponsor, I have to ask: what are the chances that the Typing Council will approve this PEP? That's the first and most important hurdle for typing PEPs.

PabloRuizCuevas · 2025-11-12T03:06:03Z

Ok I will help @Gobot1234 on finishing this one, @JelleZijlstra answering the concerns of Guido, and given that you belong to the typing council (right?), do you think that this PEP has any chance of being approved? If there is chances what would be the priority changes for me to make to advance on it. thanks in advance.

I guess the overload resolution as you already pointed out is one of them, right? anything else? I was planning to add other examples, motivations and ideas that were mentioned in discourse.

JelleZijlstra · 2025-11-12T06:34:06Z

I don't know what the Typing Council will decide but I wrote this last year: https://discuss.python.org/t/pep-718-subscriptable-functions/28457/38 and still feel the motivation for the PEP is weak.

hugovk · 2026-02-25T21:50:21Z

Lint is failing but the logs have expired. I've updated from main to get a fresh run.

Where are we up to with this PEP?

Reminder that the 3.15 feature freeze of 2026-05-05 is drawing near, and before this, the PEP will need:

to be finished
sent to the Typing Council for a recommendation
sent to the Steering Council for a decision
implemented and merged into CPython

Otherwise 3.16 is always an option.

Gobot1234 · 2026-04-16T16:07:41Z

@gvanrossum @JelleZijlstra would one of you mind reviewing this when you get the chance :)

I'm not really expecting it to make the 3.15 cut off but I'd still like to carry on moving forward with this.

JelleZijlstra

Left a few comments. As before I find a lot of the use cases dubious so I'm not the best person to advocate for this change.

JelleZijlstra · 2026-04-17T02:26:01Z

+
+.. code-block:: python
+
+   NameNumberDict = dict[str, int]


Suggested change

NameNumberDict = dict[str, int]

NameNumberDict: dict[str, int]

Oh sorry this is not what you meant. I think this example would be clearer as something like name_number_dict = dict[str, int](one=1, ...)

I think it's fine to keep this example exactly as it is.

JelleZijlstra · 2026-04-17T02:29:20Z

+   C[int].method[str](0, "")  # OK
+   C[int].cls[str](0, "")     # OK
+   C.cls[int, str](0, "")     # Invalid: too many type parameters
+   C.cls[str](0, "")          # OK, T is ideally bound to int here though this is open for type checkers to decide


What else should type checkers do? Infer Literal[0]?

I assume @JelleZijlstra meant "What else could type checkers do?" I guess another option would be Any if the binding is done as soon as C.cls is seen (C not subscripted). Also if T had a default it could legally be used in preference over inferring from the call? (I'm fuzzy about this myself.)

JelleZijlstra · 2026-04-17T02:30:20Z


   def foo[T](x: Sequence[T] | T) -> list[T]: ...

   reveal_type(foo[bytes](b"hello"))


But if you'd write foo[int](b"hello") it would also type check, right? So this is inherently unsound.

Right, this isn't a good motivational example. The bytes | Sequence[int] and str | Sequence[str] ambiguities need solutions elsewhere (and I don't know how I'd do it).

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

gvanrossum

Despite leaving a bunch of comments, I would be okay with merging this now so readers of the PEP have a newer version available, and split hairs in a follow-up PR. (PRs are cheap.)

gvanrossum · 2026-04-20T18:51:03Z

+
+.. code-block:: python
+
+   NameNumberDict = dict[str, int]


I think it's fine to keep this example exactly as it is.

gvanrossum · 2026-04-20T18:53:01Z

+
+.. code-block:: python
+
+   def my_list[T](arr) -> list[T]:


Should this be augmented with arr: Iterable[T] (which reflects what list(arr) expects) or is that a distraction?

gvanrossum · 2026-04-20T18:55:07Z

-   def make_list[T](*args: T) -> list[T]: ...
-   reveal_type(make_list())  # type checker cannot infer a meaningful type for T
+   class my_list[T]:
+        def __call__(self, *args: T) -> list[T]:


Oh, this signature is inconsistent with make_list(arr) above.

gvanrossum · 2026-04-20T18:57:57Z

+
+   my_integer_list = my_list[int]()  # TypeError: 'function' object is not subscriptable
+
+There are a few workarounds:


I think both examples would benefit from an example call of the resulting make_list() too. This seems esp. important for (2), which would reveal the clumsiness of that solution for callers.

gvanrossum · 2026-04-20T19:00:15Z

+   my_integer_list: list[int] = my_list()
+
+This solution isn't optimal as the return type is repeated and is more verbose and
+would require the type updating in multiple places if the return type changes.


Additionally, it's verbose when the intention is to pass the specialized value into another call -- now the reader has to deal with the distraction of seeing a temporary variable declaration.

gvanrossum · 2026-04-20T19:37:20Z

-the runtime type. The only change is that more situations will be decidable and the
-behaviour/overload can be specified by the developer rather than leaving it to ordering
-of overloads/unions.
+This PEP opens the door to overloading based on type variables:


Given the complexity and ambiguity already present in @overload I'm not sure that "opens the door" is enough of a specification.

gvanrossum · 2026-04-20T19:41:47Z

+   def spam[*T](bar: Bar[*T]): ...
+
+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>`.


That reason is so simple to explain that I'd just repeat it here. Also make it explicit that spam is acceptable here (rather than waiting to show it in the example below).

gvanrossum · 2026-04-20T19:43:27Z

+
+Binding Rules
+^^^^^^^^^^^^^
+Method subscription (including ``classmethods``, ``staticmethods``, etc.) should only


What is covered by the casual "etc." here? In a spec it need to specified, not left as a guess for the reader based on an example.

gvanrossum · 2026-04-20T19:44:18Z

+Binding Rules
+^^^^^^^^^^^^^
+Method subscription (including ``classmethods``, ``staticmethods``, etc.) should only
+have access to their function's type parameter and not the enclosing class's.


Suggested change

have access to their function's type parameter and not the enclosing class's.

allow their function's type parameters and not the enclosing class's.

gvanrossum · 2026-04-20T19:50:22Z

+   C[int].method[str](0, "")  # OK
+   C[int].cls[str](0, "")     # OK
+   C.cls[int, str](0, "")     # Invalid: too many type parameters
+   C.cls[str](0, "")          # OK, T is ideally bound to int here though this is open for type checkers to decide


I assume @JelleZijlstra meant "What else could type checkers do?" I guess another option would be Any if the binding is done as soon as C.cls is seen (C not subscripted). Also if T had a default it could legally be used in preference over inferring from the call? (I'm fuzzy about this myself.)

gvanrossum · 2026-04-20T19:56:04Z

@Gobot1234 Let me know your preference about how to proceed. I can promise to quickly merge what you have (including my suggestion) -- I can't promise to do another big review soon.

FWIW After a conversation with Claude I'm feeling more and more confident that we should do this. The counter-arguments "you don't need this" and "you can already do this with other means" don't convince me it's a bad idea.

hopefully final round of changes

a33030f

Gobot1234 requested a review from gvanrossum as a code owner October 8, 2025 15:10

Gobot1234 added 2 commits October 8, 2025 16:22

I think fix the build issues?

475bd8e

Sorry I can't test I can't get make installed

Fix title too short

bd36a62

fix some grammar typos and build

1ba67e9

JelleZijlstra reviewed Oct 10, 2025

View reviewed changes

JelleZijlstra reviewed Oct 11, 2025

View reviewed changes

Comment thread peps/pep-0718.rst Outdated

Update peps/pep-0718.rst

4d33729

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

Merge branch 'main' into pep-718-even-more-updates

7e2dd28

final round of changes

6ac59eb

Gobot1234 requested a review from JelleZijlstra March 5, 2026 11:22

JelleZijlstra reviewed Apr 17, 2026

View reviewed changes

Split long sentence in two for style

c6b4588

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>

gvanrossum reviewed Apr 20, 2026

View reviewed changes

	NameNumberDict = dict[str, int]
	NameNumberDict: dict[str, int]


		def foo[T](x: Sequence[T] \| T) -> list[T]: ...

		reveal_type(foo[bytes](b"hello"))


		my_integer_list = my_list[int]() # TypeError: 'function' object is not subscriptable

		There are a few workarounds:

	have access to their function's type parameter and not the enclosing class's.
	allow their function's type parameters and not the enclosing class's.

Uh oh!

Conversation

Gobot1234 commented Oct 8, 2025 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

python-cla-bot bot commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Gobot1234 commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

defjaf commented Oct 8, 2025

Uh oh!

hugovk commented Oct 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

PabloRuizCuevas commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PabloRuizCuevas commented Nov 10, 2025

Uh oh!

JelleZijlstra commented Nov 10, 2025

Uh oh!

PabloRuizCuevas commented Nov 11, 2025

Uh oh!

JelleZijlstra commented Nov 11, 2025

Uh oh!

Gobot1234 commented Nov 11, 2025

Uh oh!

gvanrossum commented Nov 11, 2025

Uh oh!

PabloRuizCuevas commented Nov 12, 2025

Uh oh!

JelleZijlstra commented Nov 12, 2025

Uh oh!

hugovk commented Feb 25, 2026

Uh oh!

Gobot1234 commented Apr 16, 2026

Uh oh!

JelleZijlstra left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gvanrossum left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gobot1234 commented Oct 8, 2025 •

edited by github-actions bot

Loading

python-cla-bot bot commented Oct 8, 2025 •

edited

Loading

Gobot1234 commented Oct 8, 2025 •

edited

Loading

PabloRuizCuevas commented Nov 4, 2025 •

edited

Loading