(Partial) support for dynamically generated types

Feature

I don't know about implementation details of mypy, whether it uses an own parser for Python code or could work based on Python's introspection capabilities. However, I think the amount of stuff that mypy could "see" and work with could increase dramatically, if it would actually load a module (thereby running some code that possibly generates some annotations), and only THEN analyze resulting type hints.

Pitch

I am working on a project which heavily uses types (due to heavy use of pydantic), but at the same time is very dynamic.

Example 1:

Sometimes I need something on value level as well as on type level. Currently I use a pattern like that in the module, if I want both mypy to check types and also do some runtime checking to catch misuse:

OpenMode = Literal["r", "r+", "a", "w", "w-", "x"]
_OPEN_MODES = list(get_args(OpenMode))

But there are situations, where going the other way is more natural, i.e. "lift" a value into a type, instead of unpacking it.

Example 1b:

Given a function I wrote and use for dynamically adjusted pydantic models, make_literal,

# evaluates to a TypedDict with a: Literal["foo"] and b: Literal[123]
LiftedValue = make_literal(dict(a="foo", b=123))  

is much more convenient than doing the inverse (having to write out the TypedDict by hand, then unpacking it).

Having this "expansion" work for types defined on value level, so they can be validly understood in following code, would be great.
Of course I understand this is probably impossible to support in an actual annotation, because annotations cannot be assumed to be evaluated in general.

Example 2:

A part of the project "dynamicism" comes from the fact that it is centered around an entry-point based plugin system.

I would like to be able to load some entry points and adjust the __annotations__, so that mypy can pick them up. That would also require that I can tell mypy where the something is coming from, without importing it - because I could basically tell mypy for some entity where the source code lives!

So I would like to have something like that work:

ObjectType = type_from_entrypoint(ep)
my_object: ObjectType = my_fancy_plugin_loader(ep)

or actually:

for p_name, plugin in my_fancy_plugins.items():
  globals()[p_name] =plugin.p_cls
  if TYPE_CHECKING:
     __annotations__[p_name] = Annotated[plugin.p_cls, EntryPoint[plugin.ep]]

So I would simply like that mypy is able to treat classes loaded from entrypoints just like it can make sense of imports - the source code location for entrypoints is easily accessible too! And proper type information is simply one load of the module away.

I think restricting this kind of dynamically added type hinting to "things that automatically are evaluated on module load" would be a natural and good trade-off, because loading a module usually won't run arbitrarily complex or expensive computations, and at the same time it would be immensely powerful.

Now of course this would increase the "risk" of circular imports and affect type checking speed, but sometimes you have to work around that even without using type hints. But I see how this could be an opt-in feature and not something enabled by default.

Or, if this is totally unthinkable for mypy, does anyone know a Python type checker that can do something like that?

Das Issue nennt keine Quelldateien, Tests oder Implementierungseinstiegspunkte; es schlägt vor, Module auszuwerten und Plugin-Einstiegspunkte während der Typprüfung aufzulösen. Kläre zunächst mit den Maintainer:innen das beabsichtigte Opt-in-Verhalten und den Umfang und identifiziere dann den relevanten mypy-Code zum Laden von Typen und für Plugin-Einstiegspunkte. Für den Abschluss wären ein abgestimmtes Design und Tests für dynamisch generierte Annotationen erforderlich.