steering-council
steering-council copied to clipboard
python
PEP 692 -- Using TypedDict for more precise **kwargs typing
Please consider PEP 692 -- Using TypedDict for more precise **kwargs typing https://peps.python.org/pep-0692/
- [x] The PEP has been discussed in threads listed in its
Post-Historyheader - [x] The PEP was annonunced on the python-dev list (link in
Post-History) - [x] The PEP includes all relevant Suggested Sections
- [x] The PEP includes endorsements from the projects/groups/people it helps https://github.com/python/mypy/issues/4441
- [x] The PEP has a CODEOWNERS entry
SIG-specific:
- [x] typing-sig PEPs: link to Guido/Jelle's summary of the typing-sig discussion: below
- [ ] Packaging PEPs: don't file the issue here, ask the delegate (Paul Moore) on Packaging Discourse
Jelle and I are debating who should write the summary of the typing-sig discussion.
Jelle and I support this PEP. It has several moving parts: a grammar change, a new dunder, a new special in typing.py, and of course implementations in type checkers. However, almost the only thing that users will see is a small piece of new grammar:
class Movie(TypedDict):
title: str
year: int
def foo(arg1: type1, **kwds: **Movie) -> type2:
...
Or the pre-3.12 equivalent using typing.Unpack:
from typing_extensions import Unpack
def foo(arg1: type1, **kwds: Unpack[Movie]) -> type2:
...
(The dunder exists solely to be able to implement Unpack properly, no types besides TypedDict need to worry about it.)
The main objection brought in on Discourse, also heard on typing-sig, is that the use case is a bit weak: why would you write the above foo() definition instead of this?
def foo(arg1: type1, *, title: str, year: int) -> type2:
...
The answer is that if you're writing new code, you probably would write it that way, but if you're adding type annotations to a large code base that happens to use this pattern (for whatever reason) it would require an unreasonable amount of refactoring to do everything "right", and this syntax is a pretty good way to get such functions to be fully annotated (including type checking of individual keyword types, rejection of unknown keywords, and requiring certain keywords).
The typing-sig discussion helped the author firm up the design and the text of the PEP in various ways, and we're happy with the result. Note that the feature is already implemented in mypy and a prototype implementation also exists in pyright. The other type checkers will be able to quickly follow this lead, should the PEP be accepted.
almost the only thing that users will see is a small piece of new grammar...The main objection brought in on Discourse, also heard on typing-sig, is that the use case is a bit weak...The answer is that if you're writing new code, you probably would write it that way, but if you're adding type annotations to a large code base that happens to use this pattern (for whatever reason) it would require an unreasonable amount of refactoring to do everything "right"
This is my sentiment as well. Very glad to have the new Unpack/** functionality, but admittedly I had hoped PEP 692 would include a variadic TypedDict (akin to TypedVarTuple) that could be used to type hint **kwargs as used in older existing (3rd-party) code bases.
It feels odd to me that we can type hint *args with a TypeVarTuple, but that similar variadic support for **kwargs is not available. The Intended Usage does feel weak to me too.
Something like TypeVarTuple for **kwargs would be more beneficial for me (personally), but I am happy this PEP is being considered 😃.
The SC tracker is not the place to have this discussion. Note that my post here was to satisfy th SC’s requirement from the checklist above.
The SC tracker is not the place to have this discussion. Note that my post here was to satisfy th SC’s requirement from the checklist above.
Apologies.
Thanks! I added this to the SC agenda.
@gvanrossum, I see the word summary in the template is misleading -- what I was imagining to get from you is more of a quick confirmation/pronouncement that the PEP captures the typing-sig discussions/consensus, so the SC doesn't need to go through the archives, and we can consider it approved by “typing-sig as a whole”. The discussions should ideally be summarized in the PEP itself, rather than the SC ticket. I'll get that clarified. Anyway, thanks for the info! Hopefully writing the comment wasn't the hard part of your research.
@adam-grant-hendry, the place to discuss the PEP is linked in its Discussions-To header.
Left a comment on behalf of the SC at https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314/52 .
@gvanrossum now that the PEP has been updated to not have the syntax change, are you up for being the PEP delegate? We wanted to make sure you are still happy with the PEP even w/o the syntax.
Guido just said elsewhere that he'll be mostly absent for a little while, FYI. However, https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314/70?u=jelle suggests he's OK with accepting the PEP without the syntax change. He did not review the PEP change (python/peps#2941).
What Jelle said. I'm okay with accepting this PEP (though I still would have preferred it with the syntax change).
@franekmagiera or @JelleZijlstra, please could you update the PEP to mark it as accepted?
https://peps.python.org/pep-0692/
