This discussion should probably be held on typing-sig@python.org. (Hope you're aware of that list.) I will have to admit that in PEP 484 we screwed up with `*args` and `**kwds` -- we thought that these would always be homogeneous and we thought we'd save the user some time by letting them write `*args: int` instead of `*args: Tuple[int, ...]` (and similar for `**kwds`), but this use case and a few others have shown that we would have been better off with the more verbose syntax. It's too late to change, alas. PEP 646 is one example where we had to twist ourselves into knots to make something work for `*args`. On Sun, Feb 7, 2021 at 9:58 AM Paul Bryan <pbryan@anode.ca> wrote:

I'm encountering a situation where it would be far cleaner to use **kwargs (multiple functions taking the same set of parameters); I'd like to have type hints, and avoid repeating multiple function definitions, explicitly enumerating all parameters for each function definition.

Therefore, I'd like to have some meaningful type hint for **kwargs. First, I thought TypedDict would be a great fit, until I found this passage in PEP 589:

These features were left out from this PEP, but they are potential extensions to be added in the future: ... TypedDict can't be used for specifying the type of a **kwargs argument. This would allow restricting the allowed keyword arguments and their types. According to PEP 484, using a TypedDict type as the type of **kwargs means that the TypedDict is valid as the value of arbitrary keyword arguments, but it doesn't restrict which keyword arguments should be allowed. The syntax **kwargs: Expand[T] has been proposed for this [11]. ... [11] https://github.com/python/mypy/issues/4441

In the mypy issue discussion, there seems to be two issues:

1. Ambiguity of whether the type hint applies to the **kwargs dict vs. each value in the dict. I think this could be a red herring; kwargs presents as a dict and I think TypedDict can unambiguously represent the structure of that dict. I don't see how it should be different than any other dict parameter being defined as a function parameter.

2. A question of whether one needs to assume that for a TypedDict, the type validator should assume total=False. I think what keys are required should be explicitly determined by the TypedDict (required keys inferred from total). I suspect the issue could be that mypy may not be able to determine this during static type analysis?

In summary, **kwargs is a dict; TypedDict can specify its structure; static type checker limitations should not necessarily restrict its use in this way.

Therefore, I propose a short PEP be drafted to codify the validity of using TypedDict to specify the type of a **kwargs argument.

Paul

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F64KJN... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>

This discussion should probably be held on typing-sig@python.org. (Hope you're aware of that list.) I will have to admit that in PEP 484 we screwed up with `*args` and `**kwds` -- we thought that these would always be homogeneous and we thought we'd save the user some time by letting them write `*args: int` instead of `*args: Tuple[int, ...]` (and similar for `**kwds`), but this use case and a few others have shown that we would have been better off with the more verbose syntax. It's too late to change, alas. PEP 646 is one example where we had to twist ourselves into knots to make something work for `*args`. On Sun, Feb 7, 2021 at 9:58 AM Paul Bryan <pbryan@anode.ca> wrote:

I'm encountering a situation where it would be far cleaner to use **kwargs (multiple functions taking the same set of parameters); I'd like to have type hints, and avoid repeating multiple function definitions, explicitly enumerating all parameters for each function definition.

Therefore, I'd like to have some meaningful type hint for **kwargs. First, I thought TypedDict would be a great fit, until I found this passage in PEP 589:

These features were left out from this PEP, but they are potential extensions to be added in the future: ... TypedDict can't be used for specifying the type of a **kwargs argument. This would allow restricting the allowed keyword arguments and their types. According to PEP 484, using a TypedDict type as the type of **kwargs means that the TypedDict is valid as the value of arbitrary keyword arguments, but it doesn't restrict which keyword arguments should be allowed. The syntax **kwargs: Expand[T] has been proposed for this [11]. ... [11] https://github.com/python/mypy/issues/4441

In the mypy issue discussion, there seems to be two issues:

1. Ambiguity of whether the type hint applies to the **kwargs dict vs. each value in the dict. I think this could be a red herring; kwargs presents as a dict and I think TypedDict can unambiguously represent the structure of that dict. I don't see how it should be different than any other dict parameter being defined as a function parameter.

2. A question of whether one needs to assume that for a TypedDict, the type validator should assume total=False. I think what keys are required should be explicitly determined by the TypedDict (required keys inferred from total). I suspect the issue could be that mypy may not be able to determine this during static type analysis?

In summary, **kwargs is a dict; TypedDict can specify its structure; static type checker limitations should not necessarily restrict its use in this way.

Therefore, I propose a short PEP be drafted to codify the validity of using TypedDict to specify the type of a **kwargs argument.

Paul

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F64KJN... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>