Research on the Mechanism of using statements to import modules or packages in Python.
This article discusses Python's from <module> import * and from <package> import *. It is a bad idea to execute and use this syntax (maybe.
Import all from one module
From <module> import * means "all names that I want to access in <module> ". For example, the following code something. py:
# something.py public_variable = 42_private_variable = 141 def public_function(): print("I'm a public function! yay!") def _private_function(): print("Ain't nobody accessing me from another module...usually") class PublicClass(object): pass class _WeirdClass(object): pass
In the Python interpreter, we can execute from something import * and see the following content:
>>> from something import *>>> public_variable42>>> _private_variable...NameError: name '_private_variable' is not defined>>> public_function()"I'm a public function! yay!">>> _private_function()...NameError: name '_private_function' is not defined>>> c = PublicClass()>>> c<something.PublicClass object at ...>>>> c = _WeirdClass()...NameError: name '_WeirdClass' is not defined
From something import * imports all names except the names starting with _ from something. According to the rules, the names starting with _ are private and are not imported.
Well, it's not that bad! What else?
We didn't mention what _ all _ is. _ All _ is a string list that specifies which symbols in the module (or the package mentioned later) will be exported when the from <module> import * is used. If we do not define _ all _ (we didn't define something. py above), the default import method for import * is to import all names starting with underscores. Again, in programming conventions, underlines indicate that a symbol is private and not imported properly. Let's see what happens when we define our own _ all _ in something. py.
# something.py __all__ = ['_private_variable', 'PublicClass'] # The rest is the same as before public_variable = 42_private_variable = 141 def public_function(): print("I'm a public function! yay!") def _private_function(): print("Ain't nobody accessing me from another module...usually") class PublicClass(object): pass class _WeirdClass(object): pass
Now, we expect that from something import * will only import _ private_variable and PublicClass:
>>> from something import *>>> public_variable42>>> _private_variable...NameError: name '_private_variable' is not defined>>> public_function()"I'm a public function! yay!">>> _private_function()...NameError: name '_private_function' is not defined>>> c = PublicClass()>>> c<something.PublicClass object at ...>>>> c = _WeirdClass()...NameError: name '_WeirdClass' is not defined
What is the package?
When importing all data from a package, the _ all _ method is basically the same as that of the module, But it processes the modules in the package (instead of importing all the names in the module ). So when we use from <package> import *. _ all _, it indicates all the modules that need to be imported into the current namespace.
The difference is that if you are in the _ init __. py does not declare _ all __, and the from <package> import * statement does not import anything (this statement is not completely correct, and the correct statement is here)
But what's worse?
Before continuing to read, execute import this in your Python interpreter and read the Python Zen again (read it to your child every night before going to bed ).
Being clear is better than being vague.
From <module> import * is not clear. It does not tell us what we are importing or what we are bringing to the current namespace. It is better to explicitly import all the names we need. In this way, the reader (probably yourself in the future) will not be confused about where a variable, method, class, or other things are used in your code, this also tells us the next point:
Readability is important
Even if you need to import many things, it is clearer to import them one by one explicitly. Use PEP 328:
from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text, LEFT, DISABLED, NORMAL, RIDGE, END)
Now you can clearly understand what is in your namespace, and use ctrl + f to quickly tell you where they come from.
At the same time, you are always at risk of changing the list content (Add/subtract) by the module/package author. That is, one of the following two:
The author deletes a string from _ all. If your code uses that name, your code will report a NameError and it is difficult to find out why.
The author adds many things in _ all. You may not need the added content, so you just fill your namespace with the things you don't care about. They even replace other content with the same name when you don't pay attention to it.
Of course, it is useful to import all the content from a module or package. However, think twice before doing so. In my experience, this is usually just a result of laziness.