> Yes, that exact scenario is supported with TypedDict.
I don't think so. I just threw together a simple example that doesn't work:
from typing import TypedDict
class A(TypedDict):
name: str
age: int
def myfunc(**kwargs: A):
print(kwargs)
myfunc()
No errors with mypy. In fact, kwargs is inferred as `dict[str, A]`, which is unbelievable given that Python explicitly supports `**kwargs` as a way to represent a grab-bag of keyword arguments.
> And while that is a simple pattern, it's not a good pattern, and quickly becomes unmaintainable in a program of any size
It's not though, if you had a proper type system. For example, you could do this trivially in Typescript and it would automatically infer the types of the rest of the kwargs. That means that your type information is preserved, making it possible to keep using your subclass without losing information about the total set of arguments it supports. The advantage is that you can add/remove arguments to your base class without having to hunt down every subclass, and you're guaranteed to be correct (and it would error otherwise!).
I don't think so. I just threw together a simple example that doesn't work:
No errors with mypy. In fact, kwargs is inferred as `dict[str, A]`, which is unbelievable given that Python explicitly supports `**kwargs` as a way to represent a grab-bag of keyword arguments.> And while that is a simple pattern, it's not a good pattern, and quickly becomes unmaintainable in a program of any size
It's not though, if you had a proper type system. For example, you could do this trivially in Typescript and it would automatically infer the types of the rest of the kwargs. That means that your type information is preserved, making it possible to keep using your subclass without losing information about the total set of arguments it supports. The advantage is that you can add/remove arguments to your base class without having to hunt down every subclass, and you're guaranteed to be correct (and it would error otherwise!).