#python #tkinter #import

I don't get the processes behind "import" and "from xyz import". When I code:

from tkinter import *

then I import, I thought, the whole tkinter names into my namespace. But I can't use neither

tkinter.messagebox.showinfo("title", "someinfo")
nor
messagebox.showinfo(...)

To use that, I have to

from tkinter import messagebox

to access it. the same with

import tkinter as tk

... there is no:

tk.messagebox.showinfo...

@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

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

@JHB17 @fatrat Although in general, it’s always best to avoid from ... import *

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

peps.python.org/pep-0008/#impo

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.