On Sat., Apr. 24, 2021, 20:55 Carl Meyer, <c...@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-le...@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/VBG2LXU6OHROQ3NPF373L7W4W23B24DE/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/NDM5WTHZUJIZSG7VKWTVNFJ7AGIBCWVG/ Code of Conduct: http://python.org/psf/codeofconduct/