Maximilian Hils <python-b...@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 <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
