El jue, 10 mar 2022 a las 7:34, <j.scholbach@posteo.de> escribió:
It looks to me, as this was the end of the discussion about a way to allow extra fields to a `TypedDict`. Is this correct? (I am new to the list and just checked the history, but I might have missed something.) If no, there is no need to read further, please just point me to the current state of the discussion.
I would like to make a point for introducing the option to have extra fields in a `TypedDict` definition. I would also like to make a proposal of how to do it. I think this feature totally makes sense and it would help me in my Python programming. I would even (try to) write a PEP for this. I am new to this kind of discussion, and I have read a hint somewhere, that before writing a PEP, one should better discuss this here on the list.
Welcome to this list! Introducing extra_fields would be an interesting idea, but it should be kept separate from the idea of supporting TypedDict for kwargs, so it would be better to discuss it in a separate thread. If you're interested in pursuing the idea, I think you're on the right track: first get initial feedback on this list, then write a PEP and see it through the process.
I would be happy to get feedback and direction on writing a PEP: Does it make sense to write a PEP for this? Or are there some goods reasons this would probably be a waste of time?
Thanks!
Jonathan
# Arguments in favor of optionally allowing extra fields
## "We are all consenting adults here".
When dealing with external data sources (JSON APIs and mongo db have already been mentioned in the thread), superfluous keys might come, and the programmer might just want to ignore them. The argument for keeping the strict keys was to prevent the hiding of typos. This is a good argument for having key-strictness as the standard behavior of TypedDict. But it is not a sufficient argument for not having a different optional behavior. Imho, the programmer should have the choice to declare whether they want to face that risk in order to trade it in for some benefit they might prefer.
## Duck typing
Giving `TypedDict` the power to optionally allow extra keys is also in the spirit of duck typing. Static duck typing has been introduced with `typing.Protocol` (PEP-544) Allowing static duck typing for dictionaries is in the same spirit.
## Typing **kwargs
There is a discussion to introduce typing for `**kwargs` (https://github.com/python/mypy/issues/4441). Most naturally, `**kwargs` would be specified using a `TypedDict` definition. As `**kwargs` are by design unspecified, this would need a way to define a `TypedDict` which allows for the existence of unspecified keys.
# Proposal
I would suggest to introduce one additional optional boolean parameter `extra_fields`, defaulting to `False` to the constructor of `TypedDict`. The value should be stored in the `__extra_fields__` attribute of the TypedDict.
There should be _no_ specification for the types of the extra keys and values. First, if this gets pressing, it can be left for a later iteration without harm. Second, from my point of view, it looks like specifying the types of keys and values is somewhat against the idea of duck typing -- if you don't even want to specify the extra keys, that means your logic should not rely on them. This second argument is not an absolute argument against specifying, but more a point of mitigating the harm of not having these specifications, which strengthens the first point.
The name should be `extra_fields`, or `additional_fields`. `extra_keys` or `additional_keys` is a worse name, because this would rather indicate a type definition on the extra keys. If later there should be type specifications for keys and values of the extra fields (because the arguments from the paragraph above are deemed invalid or insufficient), `extra_keys` and `extra_values` could be used for defining these. _______________________________________________ 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: jelle.zijlstra@gmail.com