Support inferring `@final` TypedDicts to be `Mapping[str, Union | Of | Types]`

[RobertCraigie]

Is your feature request related to a problem? Please describe.

from __future__ import annotations
from typing import Mapping, TypedDict, final

FileTypes = bytes

# this has to be key agnostic
RequestFiles = Mapping[str, FileTypes]

def post(files: RequestFiles | None = None):
    ...

@final
class FileParams(TypedDict):
    file: FileTypes

def foo(files: FileParams):
    # error: Argument of type "FileParams" cannot be assigned to parameter "files" of type "RequestFiles | None" in function "post"
    post(files)

Describe the solution you'd like

Ideally pyright could infer that the FileParams TypedDict could be safely passed to the post function as it is known to only contain keys with the type FileTypes and cannot be subclassed to add more keys because it is decorated with @final.

Additional context

I apologise if there's prior discussion surrounding this, I couldn't find any.

[erictraut]

I found a similar request posted in the mypy issue tracker. It was rejected because the person who requested the feature didn't propose to limit it to @final TypedDicts. This discussion is also relevant, and it also doesn't mention @final.

If we limit this to TypedDicts that are marked @final, I can't think of any reason why this would be unsafe from a type perspective, but it does require some pretty gross special-case logic in the type checker. Currently, the details of TypedDict are provided by the _TypedDict class definition in the typeshed typing.pyi, which indicates that all TypedDict instances derive from Mapping[str, object]. I generally don't like to override information in typeshed stubs because it's fragile to maintain such special-case logic.

None of the other type checkers currently support this either, so if I were to implement it, the behavior would be different between pyright and mypy/pyre.

I'll need to think about this a bit more. Let me know if you have any further thoughts based on the above.

[erictraut]

I spent some time prototyping this. To implement this the correct way, it involves some very gross and fragile overriding of the _TypedDict class. I can't justify doing this because it's likely to cause regressions and maintenance problems.

I'm also concerned that this will create an unnecessary and undesirable difference in behavior between Python type checkers.

If you want to pitch this idea in the python/typing discussion forum and get other type checker maintainers to agree this is a desirable feature, then I'm willing to work with the community to find a cleaner and more maintainable way to implement this.

For now, I'm going to close this request.