Allowing this is inconsistent with point 3 in the "Assignment" section of the PEP. It states that this should be allowed: def takes_name(name: str): ... def takes_moviebase(**kwargs: **MovieBase): ... takes_moviebase = takes_name But then takes_moviebase(**movie) would fail at runtime.

This is tricky, it may be worth thinking hard about whether some of the other semantics need adjusting. It is already a requirement of TypedDict semantics that a value of type `Movie` must be considered compatible with type `MovieBase`. As a result, we have to allow splatting a `Movie` because this can't be fixed in PEP 692 ... even if we didn't allow *directly* splatting, the fact that upstream code would be allowed to upcast `Movie` to `MovieBase` would mean the extra arguments can be there. Only a final TypedDict can be assumed to have no extra keys. As a result, henbruas is correct that if we're going to allow using a TypedDict to deal with the type of `**kwargs` in a way where we validate bottom-of-the-stack calls against functions that fail with extra keyword argumetns (like `takes_name`), then we should probably insist that those typed dicts must be final. Just to make sure I'm communicating why we have to assume there are extra keys, it is always legal to write this code: ``` has_year_field: Movie = {"name":"Holy Grail", "year":1975} still_has_year_field: MovieBase = d ``` and as a result, any type checking rules we write need to make sense when `MovieDict` includes an extra field like `year`. This can be confusing because at the moment this code won't typecheck: ``` has_year_field_directly_assigned: MovieBase = {"name":"Holy Grail", "year":1975} ``` This creates a situation in which it's easy to mistakenly believe values of MovieBase can't have extra fields, but they can.

Hi all, I like the idea of the pep and the pep itself. But, from what I've observed, proposing syntax changes can sometimes create barriers to pep acceptance, which would be a shame, since I've wanted better typing of **kwargs forever. So, I wanted to throw out an alternative idea to requiring a syntax change (and effectively new operator/dunder method). I don't think I saw this mentioned; apologies if it has been already. Anyways, the idea: a future import (or equiv) that changes the meaning of what a **kwargs type annotation means. e.g. ``` from __future__ import exact_kwargs_annotations def foo(**kwargs: TypedDict[...]): ... def bar(**kwargs: dict[str, int]): ... # or alternatively, a decorator: from typing import exact_kwargs @exact_kwargs def foo(**kwargs: TypedDict): ... def bar(**kwargs: dict[str, int]): ... ``` (the decorator could also be something trailed in e.g. typing_extensions for early feedback and backwards compatibility) On Sat, Aug 6, 2022 at 11:06 AM Franek Magiera <framagie@gmail.com> wrote:

Could you explain a bit more what you mean by "It wouldn't limit **kwargs to whatever's declared in the type"?

That is an interesting idea, but I don't think it is realistic. What should be the type of the kwargs parameter inside the function body in that case? Kwargs are a built in dict object. That means that inside the function body kwargs are used like a dict, so they need to support indexing (like kwargs["name"]) and all the methods that dict supports. TypedDict already takes care of that. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: richardlev@gmail.com

Well, normal classes are just a nice syntax for a dictionary. If a Protocol can describe class without limiting its members or requiring explicit base declaration, why it shouldn't be able to describe a dictionary? Perhaps there could be TypedDictProtocol ABC that would behave like amalgam of TypedDict and Protocol? PS. Sorry for the delay. It's my first post on a python mailing list and it turned out the mail delivery was disabled.

I agree with Franek. A TypedDict is effectively a protocol (a structural type) that describes a typed dictionary. It is theoretically possible to manually define a protocol class that is the equivalent of a TypedDict, but it would involve so much verbose boilerplate that no one would ever do it. Consider the following: ```python class Foo(TypedDict): x: Required[int] y: NotRequired[str] ``` This is effectively equivalent to the following protocol: ```python class FooProto(Protocol): def __init__(self, x: int, y: str): ... def copy(self: Self) -> Self: ... def update(self: _T, __m: _T) -> None: ... def items(self) -> ItemsView[str, object]: ... def keys(self) -> KeysView[str]: ... def values(self) -> ValuesView[object]: ... @overload def get(self, k: Literal["x"]) -> int: ... @overload def get(self, k: Literal["x"], default: _T) -> int | _T: ... @overload def get(self, k: Literal["y"]) -> str: ... @overload def get(self, k: Literal["y"], default: _T) -> str | _T: ... @overload def setdefault(self, k: Literal["x"], default: int) -> int: ... @overload def setdefault(self, k: Literal["y"], default: str) -> str: ... @overload def pop(self, k: Literal["y"]) -> int: ... @overload def pop(self, k: Literal["y"], default: _T) -> int | _T: ... ``` Also, as Franek said, the flexibility of protocols make them unsuitable for `**kwargs` because the runtime type for `kwargs` is a dict, so its type must conform to the interface of a dict. That's what a TypedDict is designed to do. -- Eric Traut Contributor to pyright & pylance Microsoft