Hi Malthe, On Fri, Apr 8, 2022 at 12:04 PM Malthe <mborch@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