In Python, if you want to programmatically import a module, you can do:
module = __import__('module_name')
If you want to import a submodule, you would think it would be a simple matter of:
module = __import__('module_name.submodule')
Of course, this doesn’t work; you just get module_name again. You have to do:
module = __import__('module_name.submodule', fromlist=['blah'])
Why? The actual value of fromlist don’t seem to matter at all, as long as it’s non-empty. What is the point of requiring an argument, then ignoring its values?
Most stuff in Python seems to be done for good reason, but for the life of me, I can’t come up with any reasonable explanation for this behavior to exist.
In fact, the behaviour of
__import__()is entirely because of the implementation of theimportstatement, which calls__import__(). There’s basically five slightly different ways__import__()can be called byimport(with two main categories):In the first and the second case, the
importstatement should assign the “left-most” module object to the “left-most” name:pkg. Afterimport pkg.modyou can dopkg.mod.func()because theimportstatement introduced the local namepkg, which is a module object that has amodattribute. So, the__import__()function has to return the “left-most” module object so it can be assigned topkg. Those two import statements thus translate into:In the third, fourth and fifth case, the
importstatement has to do more work: it has to assign to (potentially) multiple names, which it has to get from the module object. The__import__()function can only return one object, and there’s no real reason to make it retrieve each of those names from the module object (and it would make the implementation a lot more complicated.) So the simple approach would be something like (for the third case):However, that won’t work if
pkgis a package andmodormod2are modules in that package that are not already imported, as they are in the third and fifth case. The__import__()function needs to know thatmodandmod2are names that theimportstatement will want to have accessible, so that it can see if they are modules and try to import them too. So the call is closer to:which causes
__import__()to try and loadpkg.modandpkg.mod2as well aspkg(but ifmodormod2don’t exist, it’s not an error in the__import__()call; producing an error is left to theimportstatement.) But that still isn’t the right thing for the fourth and fifth example, because if the call were so:then
tmpwould end up beingpkg, as before, and not thepkg.modmodule you want to get thesubmodattribute from. The implementation could have decided to make it so theimportstatement does extra work, splitting the package name on.like the__import__()function already does and traversing the names, but this would have meant duplicating some of the effort. So, instead, the implementation made__import__()return the right-most module instead of the left-most one if and only if fromlist is passed and not empty.(The
import pkg as pandfrom pkg import mod as msyntax doesn’t change anything about this story except which local names get assigned to — the__import__()function sees nothing different whenasis used, it all remains in theimportstatement implementation.)