@fatrat from … import *
doesn’t import everything. The module’s author can decide what’s included.
But note that it’s generally considered bad practice to use from … import *
as it dumps lots of stuff into the main namespace. It is safer to keep namespaces separate
@JHB17 @fatrat A good way to explore this is to try it out. Create a script, let’s call it test.py
and include the following variables:
some_variable = 10
_another_variable = 20
__yet_another_one = 30
Then try from test import *
in the REPL/Console. You’ll see that only some_variable
is public so only that variable is imported.
But now, add the following at the top of the script:
__all__ = ["_another_variable", "__yet_another_one"]
and try from test import *
in a new REPL/Console (not the same one as before, as the old version is already imported there)
@s_gruppetta @JHB17 great, thx again, tried it.
@s_gruppetta
thx for the kind answer. Does indeed explain my question. Nevertheless I read "from xy import *" a lot, even in quite actual books. Where do I find what a module is offering - >>> help(module)?
@fatrat Yes, you do find that a lot, but that doesn’t make it good. Many things are a matter of preference, but this is one of those things where it’s now generally considered best to avoid.
You can see what’s imported by accessing the __all__
property, so:
tkinter.__all__
If a module doesn’t have this defined, then all the non private names will be imported. But if a module has __all__
defined, then only what’s included in __all__
will be defined
@fatrat In fact, here’s what the official Python style guide, PEP 8, says about the matter:
“Wildcard imports (from
@s_gruppetta @fatrat
"import * doesn’t import everything. The module’s author can decide what’s included."
Thank you! I've stumbled into this several times and did not realize what was happening.