classification
Title: Remove ParamSpec from __parameters__ of most typing generics
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.11, Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: kj Nosy List: gvanrossum, kj, levkivskyi, miss-islington, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2021-05-10 09:41 by kj, last changed 2021-07-31 13:36 by serhiy.storchaka. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 26013 merged kj, 2021-05-10 09:50
PR 26091 merged miss-islington, 2021-05-13 05:24
Messages (8)
msg393373 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2021-05-10 09:41
``typing.List`` includes ``ParamSpec`` in ``__parameters__`` but the builtin ``list`` doesn't. The behavior of the latter is correct, as PEP 612 states that: "As before, parameters_expressions by themselves are not acceptable in places where a type is expected".

https://www.python.org/dev/peps/pep-0612/#valid-use-locations

This patch just makes the typing version same as the builtin version by excluding ``ParamSpec`` from ``__parameters__`` (except for Concatenate, Callable, and Generic).
msg393589 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-05-13 17:19
New changeset c55ff1b352f8b82184f80d9dea220e832691acfc by Miss Islington (bot) in branch '3.10':
bpo-44098: Drop ParamSpec from most ``__parameters__`` in typing generics (GH-26013) (#26091)
https://github.com/python/cpython/commit/c55ff1b352f8b82184f80d9dea220e832691acfc
msg393662 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2021-05-14 14:17
All patches have landed. Thanks Guido!
msg398283 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-07-27 08:06
I think that List[P] should be illegal at first place.
msg398300 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-07-27 14:17
Yeah, but we shouldn't go out of our way to reject it. Especially since in 3.11 we'll likely have something equivalent to PEP 563 or PEP 649 (the SC is thinking deep about this right now) and either of those means that usually it won't be evaluated at all anyway (you'd have to call get_type_hints() with PEP 563, or use __annotations__ with the other).
msg398346 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-07-28 05:01
I am writing a patch which generalizes and significantly simplifies the code for type variables and parameter specifications substitution, and opens a way for more runtime validation. But it is incompatible with these changes.
msg398393 - (view) Author: Ken Jin (kj) * (Python committer) Date: 2021-07-28 14:59
@Serhiy, could you please briefly describe what you are planning? I'm guessing you're generalizing for _TypeVarLike?

My main concern is that we should have as few differences between builtin and typing types as possible. typing.List is deprecated and set to remove in Python 3.13/14, so I'm hoping the transition will be fairly painless.

Originally, the builtin types supported ParamSpec, but I removed that in GH-25449 for various reasons listed in that PR.
msg398641 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-07-31 13:36
See issue44796.
History
Date User Action Args
2021-07-31 13:36:10serhiy.storchakasetmessages: + msg398641
2021-07-28 14:59:14kjsetmessages: + msg398393
2021-07-28 05:01:19serhiy.storchakasetmessages: + msg398346
2021-07-27 14:17:59gvanrossumsetmessages: + msg398300
2021-07-27 08:06:44serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg398283
2021-05-14 14:17:17kjsetstatus: open -> closed
resolution: fixed
messages: + msg393662

stage: patch review -> resolved
2021-05-13 17:19:31gvanrossumsetmessages: + msg393589
2021-05-13 05:24:44miss-islingtonsetnosy: + miss-islington
pull_requests: + pull_request24731
2021-05-10 09:50:00kjsetkeywords: + patch
stage: patch review
pull_requests: + pull_request24664
2021-05-10 09:41:35kjcreate