Message399746
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. |
|
Date |
User |
Action |
Args |
2021-08-17 12:24:12 | mhils | set | recipients:
+ mhils, gvanrossum, kj |
2021-08-17 12:24:12 | mhils | set | messageid: <1629203052.1.0.154640784602.issue44926@roundup.psfhosted.org> |
2021-08-17 12:24:12 | mhils | link | issue44926 messages |
2021-08-17 12:24:11 | mhils | create | |
|