I have started a draft for a PEP for this. It is my first draft of a PEP. Any feedback and input on it is very much appreciated: https://github.com/jonathan-scholbach/peps/blob/main/pep-9999.rst I have written the draft in ignorance of your message, Eric Traut. I answer here, and point to the draft, where it makes sense.
A) Typing of extra fields: I have taken this into consideration with some detailed reasoning on the draft. The baseline is that I find it hard to come up with a use case for that. The problems you line out for the inheritance of the __extra__ attribute (if it holds the value type constraint) could also be seen as a strengthener for the tendency to keep it simple (just a boolean flag). But if you could name a good use case for value type constraints on the extra fields, that would increase my understanding of the implications of this a lot.
I don't find this feature very compelling if there is no way to specify the type of the extra fields. TypedDicts in general already allow extra keys to exist (because they support structural subtyping), so if we can't say what the type of the extra keys is, we really don't gain much from this new feature.
Your proposed PEP doesn't say much about what specific operations are allowed on an extra=True TypedDict but not a regular TypedDict.
B) Inheritance behavior of `extra` (I think that name is better than `extra_fields`, the argument for this is on the draft, too): The idea is to conceptualize `extra` in close analogy to `total` (find the reasoning on the draft). `total` already showed the problem that inheritance could lead to slight inconsistency (https://bugs.python.org/issue38834). I agree there should be an `__extra__` dunder attribute on the TypedDict, which just behaves like a normal attribute under inheritance. But I still think, it would be sweet syntax to have `extra` as a parameter of the constructor instead of writing the dunder parameter in the dictionary definition. In particular, it is relevant that
```python
class A(TypedDict):
foo: str
__extra__: str
```
is ambiguous: it could mean that a key `"__extra__"` with value type `str` would be enforced on the dictionary.
But I agree with you that is important to handle the fact that
```python
class A(TypedDict, extra=True):
x: int
class B(TypedDict, extra=False):
pass
```
leads to an inconsistency. The problem with this is that the class hierarchy would not be aligned with the type hierarchy any more. That is unexpected and a smell. For `total` this problem does not occur, as in something like
```python
class A(TypedDict, total=True):
a: int
class B(A, total=False):
pass
B.__required_keys__ # frozenset({'a'})
```
the child class's `total` specification has effect only on the keys that are added on the child class. The solution for `extra` would be to allow the inheriting class only to flip the value of `extra` from False to True when changing it. I think, that makes sense. I actually think, analogue behavior of `total` would also make sense, because I consider
```python
class A(TypedDict, total=True):
a: int
b: str
class B(A, total=False):
a: int
B.__required_keys__ # frozenset({'a', 'b'})
```
a gotcha. But this is probably out of scope here.
C) Generics: This is a good point. I think it makes sense to discuss this, once A) is settled. I just don't know when a point could be considered "settled" :) I am sure this particular question is not settled yet (but far away from this), but any feedback on how these discussions are lead here, is very much appreciated.
_______________________________________________
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