-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
PEP 821: Support for unpacking TypedDicts in Callable type hints #4764
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
base: main
Are you sure you want to change the base?
Conversation
|
Hello, PEPs need a sponsor before opening and assigning a PEP number. Please can you find a core dev sponsor via the discussion thread, and we can re-open then? See https://peps.python.org/pep-0001/#submitting-a-pep Thanks. |
|
I can sponsor this PEP. I think PEP 821 is taken by now but @Daraan if you renumber it to the latest available number, we can merge it. |
|
823 is next, please update the files to use this. |
|
Actually, 821 isn't used, please keep it :) |
hugovk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also wrap to ~80 columns.
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
|
Thank you very much @JelleZijlstra for the sponsorship! Thank you very much @hugovk for the first review. I've applied your suggestions and additional minor changes. |
|
@JelleZijlstra Please review and merge when you're happy with it :) |
| ======================= | ||
|
|
||
| This feature is an additive typing-only feature. | ||
| Existing code is unaffected; runtime behavior does not change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to change something about how TypeVar substitution works? I haven't checked.
|
|
||
| Callable[[int, str, Unpack[TD]], R] | ||
|
|
||
| Semantics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the spec should mostly be that this works the same as PEP 692 (now in the typing spec at https://typing.python.org/en/latest/spec/callables.html#unpack-for-keyword-arguments ). The semantics should mostly follow from general rules; if we have to define a complex set of new rules for this feature, I feel we're doing it wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel the same way. Most should follow from the existing rules we already have.
For that reason I also removed the notion about inline TypedDicts in 59f6cb3, I think it follows naturally.
| How to Teach This | ||
| ================= | ||
|
|
||
| This feature is a shorthand for Protocol-based callbacks. Users should be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pedagogically, teachers might want to introduce this feature before Protocols.
peps/pep-0821.rst
Outdated
| how to handle overlapping keys of non-identical types? Which restrictions | ||
| should apply in such a case? Should the order matter? | ||
| * Is there a necessity to differentiate between normal and ``ReadOnly`` keys? | ||
| * Is it necessary to specify generic behavior for ``TypedDict`` and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should follow from general rules. If TD is a generic TypedDict, then Callable[Unpack[TD], R] means unpacking from TD[Any], and Callable[Unpack[TD[T]], R] means the callable itself is generic over T.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the sentence
Daraan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank very much for the feedback and review :)
Currently I think if we should also add the case Callable[[..., Unpack[TD], R]], i.e. abritary extra positional arguments.
If so why then not also an expension to Callable[[int, ..., Unpack[TD], R]].
In my brain it kind of conflicts with the current Concatenate semantics, or rather it raises the question why does one have to use Concatenate in one case and not the other.
peps/pep-0821.rst
Outdated
| how to handle overlapping keys of non-identical types? Which restrictions | ||
| should apply in such a case? Should the order matter? | ||
| * Is there a necessity to differentiate between normal and ``ReadOnly`` keys? | ||
| * Is it necessary to specify generic behavior for ``TypedDict`` and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the sentence
|
|
||
| Callable[[int, str, Unpack[TD]], R] | ||
|
|
||
| Semantics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel the same way. Most should follow from the existing rules we already have.
For that reason I also removed the notion about inline TypedDicts in 59f6cb3, I think it follows naturally.
peps/pep-0821.rst
Outdated
|
|
||
| * Each key in the ``TypedDict`` must be accepted as a keyword parameter. | ||
| * TypedDict keys cannot be positional-only; they must be valid keyword | ||
| parameters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: Depending on the question of allowing multiple TypedDicts "may appear only once"
Basic requirements (all PEP Types)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approvalAuthor,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History@ Editors and Team - There has been an initial discussion which went off track. I am inclined to open up a new one, or should the old one be continued?
📚 Documentation preview 📚: https://pep-previews--4764.org.readthedocs.build/