[ty] Meta-type of type variables should be type[..]

[sharkdp]

Summary

Came across this while debugging some ecosystem changes in #18347. I think the meta-type of a typevar-annotated variable should be equal to type, not <class 'object'>.

Test Plan

New Markdown tests.

[github-actions]

mypy_primer results

Changes were detected when running on open source projects

beartype (https://github.com/beartype/beartype)
- error[invalid-return-type] beartype/_util/utilobjmake.py:194:12: Return type does not match returned value: expected `T`, found `object`
- Found 573 diagnostics
+ Found 572 diagnostics

pydantic (https://github.com/pydantic/pydantic)
+ warning[unused-ignore-comment] pydantic/v1/fields.py:1049:49: Unused blanket `type: ignore` directive
- Found 760 diagnostics
+ Found 761 diagnostics

hydra-zen (https://github.com/mit-ll-responsible-ai/hydra-zen)
+ warning[unused-ignore-comment] src/hydra_zen/structured_configs/_implementations.py:1074:60: Unused blanket `type: ignore` directive
- error[invalid-return-type] src/hydra_zen/structured_configs/_implementations.py:1314:20: Return type does not match returned value: expected `_T`, found `object`

[AlexWaygood]

Makes sense to me! The implicit upper bound of a TypeVar that does not have bounds or constraints is object, and the meta-type of object is type.

(tiny nit: I would spell it "meta-type" rather than "meta type")

[sharkdp]

Makes sense to me! The implicit upper bound of a TypeVar that does not have bounds or constraints is object.

Yes: That's also why I added that second test: to show that an unbounded T behaves the same way as T: object 👍