Lazy imports for Python

Posted Sep 9, 2022 8:15 UTC (Fri) by farnz (subscriber, #17727)
In reply to: Lazy imports for Python by NYKevin
Parent article: Lazy imports for Python

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.

Lazy imports for Python

Posted Sep 10, 2022 16:57 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

The concern is that, possibly, the imports are done by the application and not by the library itself. In other words, we might have something like this:

main.py:

import primary_library
import some_plugin
import another_plugin

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."