Hi Larry,
This is a creative option, but I am optimistic (now that the SC
decision has removed the 3.10 deadline urgency) that we can find a
path forward that is workable for everyone and doesn't require a
permanent compiler feature flag and a language that is permanently
split-brained about annotation semantics. Since I have access to a
real-world large codebase with almost complete adoption of type
annotations (and I care about its import performance), I'm willing to
test PEP 649 on it (can't commit to doing it right away, but within
the next month or so) and see how much import performance is impacted,
and how much of that can be gained back by interning tweaks as
discussed in the other thread.
Thanks for the kind offer, Carl! I know I would find it useful in evaluating PEP 649 is we had a real-world perf evaluation like you're offering.
My feeling is that if the performance
turns out to be reasonably close in a real codebase, and we can find a
workable solution for `if TYPE_CHECKING`, we should go ahead with PEP
649: IMO aside from those two issues its semantics are a better fit
for the rest of the language and preferable to PEP 563.
I do think that a solution to the `if TYPE_CHECKING` problem should be
identified as part of PEP 649. My favorite option there would be a new
form of import that is lazy (the import does not actually occur until
the imported name is loaded at runtime). This has prior art in
previous discussions about "module descriptors"; IIRC Neil Schemenauer
even had a branch a while ago where all module attributes were
modified to behave this way (I might be remembering the details
wrong.)
Nope, you're remembering right; it was Neil. I think he started looking at this topic at the core dev sprints when they were hosted at Microsoft (2018?).
It also has overlap with use cases served by the existing
`demandimport` library used by hg, and `importlib.util.LazyLoader`,
I'm not sure if it's diverged, but he's solution was originally a copy of importlib.util.LazyLoader, so the approach was the same.
although it is strictly more capable because it can work with `from
module import Thing` style imports as well. If there's any interest in
this as a solution to inter-module annotation forward references, I'm
also willing to work on that in the 3.11 timeframe.
I know I would be curious, especially if backwards compatibility can be solved reasonably (for those that haven't lived this, deferred execution historically messes up code relying on import side-effects and trackbacks are weird as they occur at access time instead of at the import statement).
-Brett