Skip to content

Conversation

@Daraan
Copy link

@Daraan Daraan commented Dec 30, 2025

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/

@Daraan Daraan requested a review from a team as a code owner December 30, 2025 17:14
@hugovk
Copy link
Member

hugovk commented Jan 5, 2026

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.

@hugovk hugovk closed this Jan 5, 2026
@JelleZijlstra
Copy link
Member

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.

@JelleZijlstra JelleZijlstra reopened this Jan 12, 2026
@hugovk
Copy link
Member

hugovk commented Jan 12, 2026

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

@hugovk hugovk changed the title PEP 821: Support for unpacking TypedDicts in Callable type hints PEP 823: Support for unpacking TypedDicts in Callable type hints Jan 12, 2026
@hugovk hugovk changed the title PEP 823: Support for unpacking TypedDicts in Callable type hints PEP 821: Support for unpacking TypedDicts in Callable type hints Jan 12, 2026
@hugovk
Copy link
Member

hugovk commented Jan 12, 2026

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

Copy link
Member

@hugovk hugovk left a 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.

@hugovk hugovk added the new-pep A new draft PEP submitted for initial review label Jan 12, 2026
@Daraan
Copy link
Author

Daraan commented Jan 13, 2026

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
Copy link
Member

hugovk commented Jan 13, 2026

@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.
Copy link
Member

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
Copy link
Member

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.

Copy link
Author

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
Copy link
Member

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.

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
Copy link
Member

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the sentence

Copy link
Author

@Daraan Daraan left a 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.

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
Copy link
Author

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
Copy link
Author

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.


* Each key in the ``TypedDict`` must be accepted as a keyword parameter.
* TypedDict keys cannot be positional-only; they must be valid keyword
parameters.
Copy link
Author

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

new-pep A new draft PEP submitted for initial review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants