Guido van Rossum <gu...@python.org> added the comment:
Maximilian, I think your last analysis is spot on. The problem is specific to type aliases and how at runtime they do not carry information about scope with them. The current type alias syntax (both the original form and the form using "x: TypeAlias = ...") was designed for static analysis only. I suppose we could fix cases like A = List["Foo"] but we can't fix for example A: TypeAlias = "Foo" since at runtime this just ends up creating a variable A whose value is the string "Foo", and if you import and use that in another module, all you have is the value "Foo". I think we have to accept this as a limitation of type aliases when combined with runtime access to types (it's not just get_type_hints(), but any mechanism that introspects types at runtime). I'm reluctant to fix the List["Foo"] case, if only because that case is being phased out in favor of list["Foo"] anyway, and because it depends on typing.List being special -- we can't do the same kind of fixup for user-defined classes (e.g. C["Foo"]). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44926> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
