[ty] Fix attribute access on TypedDicts

[sharkdp]

Summary

This PR fixes a few inaccuracies in attribute access on TypedDicts. It also changes the return type of type(person) to type[dict[str, object]] if person: Person is an inhabitant of a TypedDict Person. We still use type[Person] as the meta type of Person, however (see reasoning here).

Test Plan

Updated Markdown tests.

[github-actions]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[github-actions]

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

[sharkdp]

These were just (slightly) wrong before. FYI @BurntSushi.

[sharkdp]

This is a small bugfix. Instead of trying to access the member on instances of the parent class, just access them on the type that we're adding completions for — similar to how it's done in the method above. If we don't do this, the descriptor protocol will be invoked with the wrong instance type (which is why we see the changes in bound methods).

It was also possible to change this for TypedDict, because "instances"/inhabitants of TypedDict-based classes are not represented by Type::NominalInstance, but Type::TypedDict.

[AlexWaygood]

Shouldn't this be a class-literal type rather than a subclass-of type? Similar to the way we know that an int-literal must be an instance of exactly int (not a subclass of int), it's invalid for a TypedDict inhabitant to be an instance of a dict subclass -- it must be an instance of exactly dict, I think? This is different to NominalInstance types, which is why we use SubclassOf types as the meta-types for most instance types.

[sharkdp]

Shouldn't this be a class-literal type rather than a subclass-of type?

This is what I had at first. Then I noticed that type({}) is type[dict[Unknown, Unknown]] and I tried to model that similarly.

it's invalid for a TypedDict inhabitant to be an instance of a dict subclass -- it must be an instance of exactly dict

Yes, I think that's right. Will change back to <class 'dict[str, object]'>.

[AlexWaygood]

This is what I had at first. Then I noticed that type({}) is type[dict[Unknown, Unknown]] and I tried to model that similarly.

yeah, the apparent inconsistency here is due to the fact that with x = {}, we infer the type of x as dict[Unknown, Unknown], which is "lossy" -- looking at the source code, we know that it is (for now) an instance of exactly dict, but this is not recorded in the type we infer: the type we infer allows for the possibility that x could be an instance of a subclass of dict. That lossiness in the type then means that the only safe type we can infer for type(x) here is type[dict[Unknown, Unknown]] rather than <class 'dict[Unknown, Unknown]'>

And the "lossiness" of the type we infer for x there is sort-of deliberate: you usually want to be able to substitute a subclass of dict wherever a dict is expected! But for TypedDict types, that's not allowed, so we can use a more precise type for type() calls on TypedDict inhabitants.

[AlexWaygood]

Thank you!