[Typing-sig] Re: Any way to express that a dict is expected to have a key(s) but don't care about other keys?

March 10, 2022

      I think this is a reasonable idea. 

Some things to consider...

You proposed that there should be _no_ specification of the types of the extra fields, which means they would implicitly have the type `Any`. It's worth considering whether it would be useful in a subset of cases to specify (and enforce) the type of the extra fields. And if so, would it be useful for that type to be generic?

A rule would need to be established for a TypedDict that derives from another TypedDict. If the base class specifies `extra_fields=True` but the derived class does not, is that an error? Does the derived class inherit the `extra_fields` property? What if both specify `extra_fields` but they contradict each other?

Here's an alternative formulation that addresses the above issues. We could support a special dunder field that type checkers recognize and treat specially. Let's say we call it `__extra__`. Then the TypedDict definition would look like the following:

```python
class A(TypedDict):
    x: int
    __extra__: str | None
```

The normal rules for variable inheritance would apply in a natural way.

```python
class B(A):
    pass # B supports __extra__ because it inherits it from A

class C(A):
    __extra__: str # This is OK because "str" is a subtype of "str | None"

class D(A):
    __extra__: int # This is an error because "int" isn't a subtype of "str | None"
```

There has also been serious discussion of adding generic support for `TypedDict`, and this alternate formulation would work well for generics.

```python
class A(TypedDict, Generic[T]):
    foo: str
    __extra__: T

class B(A[int]):
    bar: str
```

 -Eric

--
Eric Traut
Contributor to Pyright & Pylance
Microsoft