Lazy imports for Python
Lazy imports for Python
Posted Sep 8, 2022 20:24 UTC (Thu) by NYKevin (subscriber, #129325)In reply to: Lazy imports for Python by mathstuf
Parent article: Lazy imports for Python
Posted Sep 9, 2022 8:15 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (1 responses)
Or, on the assumption that you're willing to do work to support lazy loading, you move all of the global code bar imports into the init function, and then have the last line of your module be init(). This is a bigger refactor, but it means that old users get the behaviour they expect (import runs the code), and new users can do a lazy load followed by a call to init to get the same behaviour.
Posted Sep 10, 2022 16:57 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
main.py:
import primary_library
Each of the plugin files imports primary_library and then calls some magic init function from there, but the actual API is primary_library (i.e. you just import some_plugin for the magic init side-effect and not to actually use it directly). The plugins are third-party code. You can't just fix it in primary_library, because primary_library doesn't know about the plugins and can't find and init them by itself, even if the application does call primary_library.init().
The reasonable solution is to require the application to call primary_library.init(some_plugin) and explicitly say which plugin(s) to init. But that might be a more significant refactoring job. OTOH, explicit is better than implicit, and this is IMHO a superior coding style to just "write import x and magic happens."
Lazy imports for Python
Lazy imports for Python
import some_plugin
import another_plugin
