Runtime imports are a maintenance nightmare and can quickly fragment a codebase. Static analysis of imports is so desirable that it is almost always worth the initialization performance hit. Tradeoffs.
I guess you meant "run all imports at startup is desirable to check if they work", but I have a hard time agreeing with that (personally I think having a good test suite is needed, whereas running more code at startup is not wanted).
I agree, which is why you should design your modules correctly and import only the stuff you need.
I was pointing out that lazy imports vs runtime imports in functions are basically the same and lead to the same issues.
How do you achieve this without making gazillions of modules, where each module has just a few stuff?
Are you saying just use local import everywhere?
So when you do this
import bigmodule
Then, you have your big initializer code in bigmodule.financedata. But the stuff you need for running scripts is in bigmodule.scripts.
So when you write
from bigmodule import financedata
But if you write
from bigmodule import scripts
You don't need to have gazillion modules, just good organization. Also, in general, its a good practice to gate intensive compute/network operations behind an explicit function you need to call.
Also thank you for focusing the convo on the tech stuff instead of repeating finance bro myths
And when you have to depend on external libraries beyond your control, how do you typically handle those situations?
As for external libraries, you import them in places where you need to use them only to avoid the same pitfalls. Its also pretty easy to analyze the import process within those libraries, and then again import specific submodules only that limit what actually gets loaded.