There are some advantages, yes.
- Does not pollute the local scope;
One of the great advantages of modularizing code is separating things into different scopes, so you have the freedom to work on your project without worrying about conflicting function names. To care about from <module> import *
you will be importing all that is stated in __all__
module or all if the module does not define this structure and therefore in this way you have no control over your own scope, which is terrible.
- The code doesn’t get magical;
Although in Python many things seem to be simple as magic step, at this point is not interesting. As commented in item (1), when doing from <module> import *
You have no control over the scope, so you can’t know what is declared. The consequence of this is that by reading the code you can read something like:
from A import *
from B import *
from C import *
...
x = get_answer() # 42
And then, where the function was defined get_answer
? You can even go after the documentation of modules A, B and C, but look at the resource you need to invest in it just to know where the function comes from, while from C import get_answer
eliminates any obscurity of the code.
- Ides thank;
Just as in (2) you will suffer to determine where the function was defined, the IDE, considering that it has the tools, will also suffer to understand where it was defined. In many cases she won’t even be able to solve the scope when done from <module> import *
, then every function or variable that uses the module the IDE won’t be able to measure if it actually exists, if the function call matches its signature, etc. Probably tools that check typing, like Mypy, will also suffer from it.
Also, you don’t need to duplicate the line; you can include more than one structure with the same import
:
from math import ceil, sqrt