# Update to PEP 692's specification

**URL:** <https://discuss.python.org/t/update-to-pep-692s-specification/32401>\
**Category:** PEPs\
**Created:** [August 27, 2023, 2:14pm UTC](https://discuss.python.org/t/update-to-pep-692s-specification/32401 "2023-08-27T14:14:26Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![franekmagiera](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/franekmagiera/32/9008_2.png) [@franekmagiera](https://discuss.python.org/u/franekmagiera)\
**Post date:** [August 27, 2023, 2:14pm UTC](https://discuss.python.org/t/update-to-pep-692s-specification/32401/1 "2023-08-27T14:14:26Z")

</div>

Hey, based on developer feedback I wanted to propose changes to PEP 692. [Here](https://github.com/python/peps/pull/3308) is a link to the PR with proposed changes.

In a nutshell, from type checkers point of view, the function signature typed with `Unpack` should be equivalent to its explicitly expanded form. Therefore:

```auto
class Movie(TypedDict):
    name: str
    year: int

def foo(**kwargs: Unpack[Movie]): ...

```

should be equivalent to:

```auto
def foo(*, name: str, year: int): ...

```

This creates a more robust specification for the feature. Alsot it is a lot simpler to remember and reason about and should not jeopardize type safety. [Ivan’s comment](https://github.com/python/mypy/pull/15612#discussion_r1298300340) goes into a bit more depth on the issue.

Also, when it comes to the _Passing kwargs inside a function to another function from_ section - we cannot expect type checkers to treat the same function call differently depending on the context, therefore this feature should be deleted from the specification. This, however, should not degrade the value of the rest of the proposal.

Let me know what you think!

---

<div class="post-metadata">

**Author:** ![franekmagiera](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/franekmagiera/32/9008_2.png) [@franekmagiera](https://discuss.python.org/u/franekmagiera)\
**Post date:** [February 21, 2024, 7:44pm UTC](https://discuss.python.org/t/update-to-pep-692s-specification/32401/2 "2024-02-21T19:44:28Z")

</div>

Any chance someone had some time to take a look at the proposal?

---

<div class="post-metadata">

**Author:** ![erictraut](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erictraut/32/15190_2.png) [@erictraut](https://discuss.python.org/u/erictraut)\
**Post date:** [February 21, 2024, 7:54pm UTC](https://discuss.python.org/t/update-to-pep-692s-specification/32401/3 "2024-02-21T19:54:27Z")

</div>

PEP 692 was accepted and is marked Final, so it probably doesn’t make sense to amend the PEP at this stage. PEPs are meant to be historical documents, not evolving documentation.

If you think that a clarification is needed, I recommend doing so in the [typing spec](https://typing.readthedocs.io/en/latest/spec/callables.html#unpack-for-keyword-arguments).

Here’s [the process](https://github.com/python/typing-council#decisions) we’re using for such updates.

---

<div class="post-metadata">

**Author:** ![Daverball](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/daverball/32/15931_2.png) [@Daverball](https://discuss.python.org/u/Daverball)\
**Post date:** [February 21, 2024, 10:14pm UTC](https://discuss.python.org/t/update-to-pep-692s-specification/32401/4 "2024-02-21T22:14:58Z")

</div>

I don’t think the specification for `Unpack` should change for a regular `TypedDict` in this way, because it introduces safety holes.

But for a closed `TypedDict`, as made possible with the changes proposed in PEP 728, we can make this bidirectional equivalency, because we can now be sure that there will be no additional keys. Incidentally PEP 728 should allow `Unpack` with `TypedDict` to be expressive enough to model every possible layout of keyword only arguments.