
On Sat., Apr. 24, 2021, 20:55 Carl Meyer, <carl@oddbird.net> wrote:
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
Carl _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VBG2LXU6... Code of Conduct: http://python.org/psf/codeofconduct/