On Mon, Apr 19, 2021 at 5:49 AM Jukka Lehtosalo <jlehtosalo@gmail.com> wrote:
The partial laziness seems helpful to avoid explicit escaping in use cases like this:
type T = TypeVar(bound=D) class C(Generic[T]): ... # If we evaluate T fully, we get NameError about D class D: ...
Code like this seems somewhat common. I could find over 100 forward references in type variable bounds in a large internal codebase. Not having partial laziness could result in getting a NameError potentially far away from the source, which can be confusing.
Changing the order of definitions will sometimes help, but it's not always practical. It can create a lot of needless code churn, especially if we are talking about changing the order of big classes. Some forward references are caused by import cycles, and avoiding import cycles is often not possible without major compromises. If we'd limit the use of forward references, users might prefer the old way as more flexible.
I think you're right. I've not been able to think of a better option than some form of partial laziness. I hope it could be kept as simple and consistent as possible.
I'd just like to be able to drop the explicit string literal name argument somehow, since it looks quite awkward -- especially if the type name is long.
Agreed. Carl