Re:HRT's Python Fork: Leveraging PEP 690 for Faster Imports
by 82716f12 on Friday August 08, 2025 @05:21PM
(#44841811)
That sounds good in theory, but I haven’t come across a codebase that’s really optimized and free of unnecessary imports, especially in large companies.
And when you have to depend on external libraries beyond your control, how do you typically handle those situations?
Re:HRT's Python Fork: Leveraging PEP 690 for Faster Imports
by ActorNightly on Friday August 08, 2025 @05:43PM
(#44841989)
As codebases get larger, inefficiencies are bound to happen. Having explicit imports that I can go look up and see where they are is better for resolving this, because you can trace how every module gets imported and time them. Having interpreter code that runs with lazy loading that is all hidden is not the way to solve this.
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.
So when you do this
It doesn't do anything functionality, and you may only have some small top level things available for you, like bigmodule.config, or bigmodule.logging.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
This code will take a while.But if you write
This will load fast.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