TypedDict -> dict compatibility

[zr40]

Feature

Allow for TypedDicts (or a new type specialized for this purpose) to be compatible with dict when the receiver declares it is not going to mutate the dict.

Pitch

When using a TypedDict, it is common to eventually pass it to a function that takes an arbitrary dict or return it to the caller expecting the same. Currently this is rejected, and the reason makes sense. For example, this is correctly rejected:

class DefinitelyContainsStatus(TypedDict):
    status: str

def delete_status(d: dict):
    del d['status']

d: DefinitelyContainsStatus = {'status': 'ok'}
delete_status(d)
assert d['status'] == 'ok'

If it were permitted, a type checker wouldn't be able to know how the dict is going to be mutated, and then any other references that may exist would still expect it to conform to the TypedDict.

However, this presumably valid case is also rejected:

def foo() -> DefinitelyContainsStatus:
    return {'status': 'ok'}

f: dict[str, str] = foo()

# error: Incompatible types in assignment (expression has type "DefinitelyContainsStatus", variable has type "Dict[str, str]")  [assignment]

Here's a real-world example that has lead to the creation of this feature request. In Flask it is allowed to return a dict from a view function, which it then converts to JSON. This is particularly convenient in order to apply type checking to a JSON-based HTTP API. However, when the return type is declared to be some TypedDict, this is rejected:

class Example(TypedDict):
    status: str

@blueprint.route("/example")
def example() -> Example:
    return {"status": "ok"}

# error: Value of type variable "ft.RouteDecorator" of function cannot be "Callable[[str], Example]"  [type-var]

On the Flask side of things, they specifically require a real dict, so they cannot change the type to accept Mapping. It would be quite useful to be able to allow returning TypedDict from a function to a caller that accepts dict.

[erictraut]

However, this presumably valid case is also rejected

Your second sample is just as unsafe as the first. If the assignment in the second example were allowed, then f could be passed to delete_status without an error.

There is already a way in the Python type system to indicate that a dict is immutable: the Mapping type. You can use the following, and no type checking error will be emitted by mypy.

f: Mapping[str, str] = foo()

[zr40]

Your second sample is just as unsafe as the first. If the assignment in the second example were allowed, then f could be passed to delete_status without an error.

Indeed, but it is only unsafe if other references to f remain that do rely on TypedDict's guarantees. TypedDict is documented to be just a dict at runtime, so if no TypedDict-typed references to f remain, it would not be unsafe to treat it as a dict.

However, that example was just for illustration; this feature request is not about that.

Consider the Flask case. The @route decorator takes a callable of which it expects its return type to be Union[dict, ...] (actual type here). It is actually immutable but they have reasons why they can't accept an arbitrary Mapping; it must actually be a dict. Since a TypedDict is indeed just a dict at runtime, and Flask promises to treat the dict as immutable, it should be representable in typing that both dicts and TypedDicts are accepted by Flask, while other Mappings that aren't actually dicts are not accepted. That is the feature I'm requesting.

[glyph]

There is already a way in the Python type system to indicate that a dict is immutable: the Mapping type. You can use the following, and no type checking error will be emitted by mypy.

This… does not appear to be the case.

from typing import TypedDict, Mapping
class DefinitelyContainsStatus(TypedDict):
    status: str

def foo() -> DefinitelyContainsStatus:
    return {'status': 'ok'}

f: Mapping[str, str] = foo()

Was this a bug reintroduced later?

[glyph]

(Its beef appears to be with the str value type. Putting Any or object as the second type parameter to Mapping makes it happy.)

[bwo]

I just encountered this when trying to remap keys in a TypedDict generated by django-stubs, the slimmed down version of which is:

from typing import Mapping, TypedDict, TypeVar

K = TypeVar('K')
V = TypeVar('V')

def mapkeys(dct: Mapping[K, V], keymap: dict[K, K]) -> dict[K, V]:
    return {keymap.get(k, k): v for k, v in dct.items()}

class Foo(TypedDict):
    foo: int

f: Foo = {'foo': 1}

b: dict[str, int] = mapkeys(f, {"foo": "bar"})

b2: dict[str, int] = mapkeys(dict(f), {"foo": "bar"})

b3: dict[str, int] = mapkeys({k: v for (k, v) in f.items()},
                             {"foo": "bar"})

playground link

There are errors on all three invocations to mapkeys.