[issue44926] typing.get_type_hints() raises for type aliases with forward references
Maximilian Hils
report at bugs.python.org
Tue Aug 17 08:24:12 EDT 2021
Maximilian Hils <python-bugs at maximilianhils.com> added the comment:
Thank you Ken and Guido for the super quick feedback!
> It's not fine if it were to look in the wrong namespace
That's a really good point. Here's another terrible example:
foo.py:
```
import typing
FooData: typing.TypeAlias = "Data"
class Data:
pass
```
bar.py:
```
import typing
import foo
BarData: typing.TypeAlias = "Data"
def func1(x: foo.FooData, y: BarData):
pass
class Data:
pass
print(typing.get_type_hints(func1)) # incorrectly uses bar.Data twice.
```
I don't see how we could distinguish FooData from BarData without static analysis. Changing get_type_hints to not pick the unrelated class with the same name would essentially mean not using func.__globals__, which breaks almost all ForwardRef evaluation. This doesn't seem viable.
Potential alternatives:
1. Accept the current state: get_type_hints does not work well with type aliases that use forward references.
2. Fix it at least for cases where a ForwardRef is constructed immediately (typing.List["Foo"], but not "Foo" or list["Foo"]), similar to how it's been done for #41249. I have made a very basic proof-of-concept at https://github.com/mhils/cpython/commit/4adbcf088d2857166b579f7dd2954ff9981fc7db, but it's a mess (see commit comments).
3. Deprecate/discourage use of forward references in type aliases and/or change the syntax for [forward references in] type aliases so that their origin can be tracked.
In summary, it seems like there are no really good solutions here. I'm fine if this ends up as a pragmatic wontfix, maybe with a comment added somewhere in the docs or in PEP 613.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44926>
_______________________________________
More information about the Python-bugs-list
mailing list