@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 <module> import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools."
@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.