PEP 821: Support for unpacking TypedDicts in Callable type hints

[Daraan]

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
• Suggested sections included (unless not applicable)
  • Motivation
  • Rationale
  • Specification
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• Python-Version set to valid (pre-beta) future Python version, if relevant
• Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-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/

[hugovk]

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.

[JelleZijlstra]

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.

[hugovk]

823 is next, please update the files to use this.

[hugovk]

Actually, 821 isn't used, please keep it :)

[hugovk]

Please also wrap to ~80 columns.

[Daraan]

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.

[hugovk]

@JelleZijlstra Please review and merge when you're happy with it :)

[JelleZijlstra]

Do we need to change something about how TypeVar substitution works? I haven't checked.

[JelleZijlstra]

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.

[JelleZijlstra]

Pedagogically, teachers might want to introduce this feature before Protocols.

[JelleZijlstra]

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.