I don't understand this – why would you import a package into your code that you weren't using?
So it turns out people who care about performance already turn all Python imports into local ones under the hood: both Hudson River Trading, and Meta's production python auto lazy import:

Oct 9, 2025 · 10:46 AM UTC

5
1
7
Replying to @hammer_mt
could it be the the same script, depending on the control flow will not activate all path at every runtime?
Oh I guess so. When they say 'performance' do they mean it takes a while to deploy? I didn't think imports slowed down execution much.
Replying to @hammer_mt
One example that comes to mind is that DSPy has a numpy dependency that is only sometimes used. If you aren't using that part of the codebase, but still importing dspy, you shouldn't eat the overhead.
1
3
Ah ok, makes sense. I figured out I never run into this problem because I always use the same env for multiple scripts / notebooks.
Replying to @hammer_mt
imagine an app that renders a matplotlib image or outputs to a pandas dataframe on a user request, not having to load that package until it’s being used makes the startup time much faster since python imports every package into the global namespace when it’s at the top of the file
I guess I had a blind spot because I don't really code things that way. Usually my apps are focused on one thing as a service so I use everything I import.
1
1
Replying to @hammer_mt
I think it's more about using a package conditionally, in which case this is really a great thing. I have also found that many libraries, due to the amount of imports they have, make the startup very slow. Lazy imports will fix that!
5
Replying to @hammer_mt
also this allows you to properly patch packages _before_ they're used anywhere in your app, which avoids the problem of imports loaded --> you patch their source --> the patch is ineffective because your module has already loaded them