-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Add support for TypedDict extra_items= and closed= (PEP 728) #18176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The PEP has been updated and no longer specifies the |
Good catch -- I missed that. In that case, I think it makes sense to wait for I have opened a |
The |
I think all the prerequisites are ready to start work on the implementation -- we just need somebody who has time and interest to work on this. |
Uh oh!
There was an error while loading. Please reload this page.
Feature
PEP 728 proposes changes to
TypedDict
, including the ability to specify the types of unspecified keys.This has been implemented in
typing_extensions
with the__extra_items__
keyword since version 4.10.I would like to see support for this added to
mypy
.Pitch
I am working on using mypy to validate Python code associated with rest API services. It is not uncommon for the OpenAPI specs we use to include objects whose
additionalProperties
values map to schemas. This is how OpenAPI handles the case of objects whose keywords are not known in advance, but whose values must be of a particular type.I want to be able to type annotate these schemas in Python, but currently there is no good mechanism for doing this. That is one of the problems that PEP 728 attempts to solve.
Currently with mypy I have found a few ways to handle this (in the absence of adding the requested support):
typeddict-unknown-key
errors. But of course that means no type checking is happening for the additional keys being used.For both 2 and 3, it would definitely be less clean and much lengthier than using the solution in
typing_extensions
.From my research when trying to figure out how to handle this problem, I get the impression I am not the only one trying to handle this case. That is also indicated by the fact that the current JSON schema and OpenAPI spec includes this ability. And of course, that is part of the motivation for the PEP being opened in the first place.
The text was updated successfully, but these errors were encountered: