141–150 of 247 posts
One thing the PEP doesn't really talk about, and that I find very annoying is that many python linters will complain if you don't put all of your imports at the top of the file, so you get lint warnings if you do the most obvious way to implement lazy imports. And that is actually a problem for more than just performance. In some cases, importing at the top might actually just fail. For example if you need a platform…
Earlier quoted context omitted.
Oof. I wish they could support version imports import torch==2.6.0+cu124 import numpy>=1.2.6 and support having multiple simultaneous versions of any Python library installed. End this conda/virtualenv/docker/bazel/[pick your poison] mess
Really what is the headache with virtual environments? They’ve been solved. Use UV or python’s built in venv creator and you’re good to go. uv venv —seed —python=3.12 && source .venv/bin/activate && pip3 install requests && …
I should be able to do "python foo.py" and everything should just work. foo.py should define what it wants and python should fetch it and provide it to foo. I should be able to do "pyc foo.py; ./foo" and everything should just work, dependencies balled up and statically included like Rust or Go. Even NodeJS can turn an entire project into one file to execute. That's what a modern language should look and work like.
The moment I see "--this --that" just to run the default version of something you've lost me. This is 2025.
I could, and sometimes do, go through all the imports to figure out which ones are taking a long time to load, but it's a chore.
One thing the PEP doesn't really talk about, and that I find very annoying is that many python linters will complain if you don't put all of your imports at the top of the file, so you get lint warnings if you do the most obvious way to implement lazy imports. And that is actually a problem for more than just performance. In some cases, importing at the top might actually just fail. For example if you need a platform…
Earlier quoted context omitted.
In Python? I almost never see that. And I’ve certainly never signed off on a PR that did that.
Recursively importing other modules is itself a side effect. In fact, all the code you see in the module is "side effects", in a sense. A `class` body, for example, has to actually run at import time, creating the class object and attaching it as an attribute of the module object. Similarly for functions. Even a simple assignment of a constant actually has to run at module import. And all of these things add up. Furt…
Sure thing you can declare globals variable and run anything on a module file global scope (outside funcs and class body), but even that 'global' scope is just an illusion, and everything declared there, as yourself said, is scoped to the module's namespace
(and you can't leak the 'globals' when importing the module unless you explicity do so 'from foo import *'. Think of python's import as eval but safer because it doesn't leaks the results from the module execution)
So for a module to have side-effect (for me) it would either:
- Change/Create attributes from other modules
- Call some other function that does side-effect (reflection builtins? IO stuff)
Earlier quoted context omitted.
You're welcome to bring a concrete proposal to, e.g., https://discuss.python.org/c/ideas/6 , or ask around the core devs to find a PEP sponsor. Note that you will be expected to have familiarized yourself generally with previous failed proposals of this sort, and proactively considered all the reasonably obvious corner cases.
In spite of the 'You're welcome to bring' this does not actually sound like an encouragement but more of a veiled statement that some non-technical reason will be found to shoot down the proposal if it were to be made so you might as well not bother.
There are many people here who think enabling lazy imports is as simple as flipping a light switch. They have no idea what they're talking about.
Previously, if you had some thread hazardous code at module import time, it was highly likely to only run during the single threaded process startup phase, so it was likely harmless. Lazy loading is going to unearth these errors in the most inconvenient way (as Heisenbugs)
(Function level import can trigger this as well, but the top of a function is at least a slightly more deterministic place for imports to happen, and an explicit line of syntax triggering the import/bug)
One thing the PEP doesn't really talk about, and that I find very annoying is that many python linters will complain if you don't put all of your imports at the top of the file, so you get lint warnings if you do the most obvious way to implement lazy imports. And that is actually a problem for more than just performance. In some cases, importing at the top might actually just fail. For example if you need a platform…
I don't think there is any solution for that but "fix your broken linter".
Probably because PEP 8 says
> Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants
Lazy imports are a great way to create runtime errors far into the operation of a long lived service. Yes, it gives the superficial benefit of 'fast startup', but that upside is negated by the downside of not being sure that once something runs it will run to completion due to a failed import much further down the line. It also allows for some interesting edge cases with the items that are going to be imported no lon…
Earlier quoted context omitted.
I don't think there is any solution for that but "fix your broken linter".
It isn't just one though. Every linter I've used has warned about that. Probably because PEP 8 says > Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants
I banished the worst/heaviest libraries to this list at my workplace and it's been really helpful at keeping startup times from regressing.