Set TypedDicts to always be their declared type as opposed to the type inferred when instantiated

[rowillia]

TypedDicts appear to have explicitly decided not to accept subtypes on fields,
but this behavior is counter intuitive. This made it so TypedDicts didn't
respect Any and caused problems with what should have been ducktype
compatible. This also brings TypedDicts more in line with other container
types and with how fields on classes behave. The following code is already OK
with mypy:

from typing import Dict

def foo() -> Dict[float, object]:
    x: object = 50.5
    return {
        1: 32
    }

This fixes #2610

[gvanrossum]

@davidfstr What do you think of this? It looks reasonable to me -- if you agree I'll merge it.

[JukkaL]

Making the typed dict field types covariant isn't safe, since the fields are mutable. Dictionaries are invariant as well. The dictionary example works because mypy uses "type context" to infer the key/value types for a dict literal. The modified example below won't work, since now there's no type context when we define d:

from typing import Dict

def foo() -> Dict[float, object]:
    d = {   # inferred type is Dict[int, int]
        1: 32
    }
    return d  # error

I think that the correct fix would be for the call to a typed dict type to result in the exact declared typed dict type. Example:

from mypy_extensions import TypedDict

A = TypedDict('A', {'x': object})

def f() -> A:
    a = A(x=int)  # type of a should be TypedDict(x=object)
    return a

[davidfstr]

Making the typed dict field types covariant isn't safe, since the fields are mutable.

+1. Yes this is unfortunate. I originally had the fields support covariance until I noticed they were mutable.

I think that the correct fix would be for the call to a typed dict type to result in the exact declared typed dict type.

Yes this would make sense to me. I'm actually a bit surprised this isn't the current behavior.

[rowillia]

@JukkaL @davidfstr makes sense. So it sounds like a proper fix would be able to pass with all of the test cases I added and the existing test case that enforces invariance. Assuming we fix #2487, how would this interact with dictionary literals?

[davidfstr]

I imagine the following two code fragments would create values of equivalent types, i.e. Point:

d1 = Point({'x': 1, 'y': 2})
d2 = {'x': 1, 'y': 2}  # type: Point

I believe there is still a problem where an unknown type (i.e. Any) is not treated as "equivalent" to a required item type. So I suspect the following would still fail:

def make_point(x, y):
    return Point({'x': x, 'y': y})  # probably fails because x and y are of Any type

[JukkaL]

Any is equivalent with all other types, so it shouldn't be a problem.

#2487 would need to consider the type context when inferring the type of a literal. For example, if the context has a type like {'x': List[int]}, the type of [] in {'x': []} should be List[int] based on the type context.

[rowillia]

@davidfstr I took @JukkaL 's advice and made the type of the TypedDict always the declared type. This matches what I would expected anyway.

This did break a few existing test cases, I'd love your input on the changes.

[davidfstr]

@rowillia these changes look good to me, including the test changes.

Not related to your commit, but I'm surprised the revealed types of the named types (like Point) don't actually give the named type (i.e. Point) but rather the anonymous type (TypedDict(x=int, y=int)). It's possible the original tests and the output for reveal_type() predate the maintenance of the named type information. Something to look at in a different PR...

[rowillia]

@davidfstr yeah I'd love to see that fixed.

[JukkaL]

Looks good now! Just a few test case related requests.

I'd like to see a type context related test case, where a value type is, say, List[int], and it's given an empty list [] as an argument, e.g. MyTypedDict(items=[]). Use reveal_type on the resulting typed dict.

Another thing below.

[JukkaL]

Can you also do something like reveal_type(Point(x=1, y=2)) in a test case?

[JukkaL]

@rowillia Are you interested in finishing this up? If you are currently busy, I can do the remaining bit of work and get this merged.

[JukkaL]

@rowillia I merged this as #3099 with a few test updates. Thanks for working on this!