
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. 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.) It also has overlap with use cases served by the existing `demandimport` library used by hg, and `importlib.util.LazyLoader`, 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. Carl