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.

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