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/

Reply via email to