Hi Malthe,

On Fri, Apr 8, 2022 at 12:04 PM Malthe <mbo...@gmail.com> wrote:
> Actually, to me the interesting idea is not so much lazy imports – I
> think they should not be lazy, at least that was my initial thought. I
> think they should be immediately resolved before anything else in that
> module:

I'm +0.25 on your idea as simply a streamlined syntax for inline
imports (given actually finding an appropriate syntax, which I haven't
thought much about; @ probably doesn't work due to the conflict with
decorator syntax, but there might be other options.). If it existed I
would probably use it occasionally, but I don't feel a strong need for
it.

But I think your proposal is much stronger if you eliminate the
hoisting from it; with the hoisting I'd be -1. Out-of-source-order
execution like this is just quite surprising in the context of Python.

> 1. This would settle any discussion about performance impact (there
> wouldn't be any).

If the inline import is actually a performance problem because a
certain code path is very hot, the solution is simple: don't use the
inline import there, use a top-of-module import instead.

> 2. This would enable IDEs, typers and other tooling to know the type
> using existing import logic.

I don't think it enables any such thing. Static-analysis tooling has
only the source code to work with, runtime behavior doesn't affect it.
If the runtime executes these imports out-of-order, that won't make
the slightest difference to how easily IDEs and type checkers can
analyze the source code.

> 3. Catch errors early!

The very strong precedent in Python is that errors in code are caught
when the code runs, and the code runs more or less when you'd expect
it to, in source order. If you want to catch errors earlier, use a
static analysis tool to help catch them.

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/ARI44O62CRMAF2IKPHJVLU5D2ADR2DP6/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to