Warning: sizeof(): Parameter must be an array or an object that implements Countable in /home/helpmekim2dhsefl3pwmseak8ismo2/wwwroot/wp-content/plugins/ad-injection/ad-injection.php on line 824 Warning: count(): Parameter must be an array or an object that implements Countable in /home/helpmekim2dhsefl3pwmseak8ismo2/wwwroot/wp-content/plugins/ad-injection/ad-injection.php on line 831

The consequence of the directory from xxx import * is why you should not thank you for the invitation “under any circumstances”. The consequences of from xxx import * are very clear to everyone. This method of from xxx import * may cause naming conflicts. For example, A sells digital products, and B sells fruits. A and B serve the same boss. They all have a suitcase, and now they are all in front of the boss, supplying goods to the boss. Now there are two situations: look at a piece in the box and take it out (from B import apple). For convenience, pour it out (from A import *, from B import *). Now there are both in boxes A and B. An iPhone box (assuming it is the same iPhone) A’s iPhone box, a mobile phone B’s iPhone box, and a Red Fuji apple (don’t ask B why he did this, ask is creative) If A and B All the luggage items are poured out (from A import *, from B import *), can you tell which box contains the mobile phone and which box contains the Red Fuji? from A import *
from B import *
use(apple) But if you need to take it out when needed, we can clearly know that if you want Red Fuji, you can go directly to B’s suitcase and get it (from B import apple) from B import apple
If the box is not opened, it is difficult to tell which apple is an iphone and which apple is an apple based on the appearance of the box. Why shouldn’t I use this method “in any case” by the way. I will tell you why you shouldn’t use this method “in any case”. Because of the broken window effect. Take a building with a few broken windows as an example. If those windows are not repaired, there may be more windows destroyed by vandals. Eventually they will even break into the building. If they find that no one is inhabited, they may settle there or set fire. If some graffiti appears on a wall and is not cleaned off, the wall will soon become messy and unsightly. This theory believes that if undesirable phenomena in the environment are allowed to exist, they will induce people to imitate or even worsen it. For small projects, it’s okay. For large software projects, if you don’t have a good code specification, it is very easy to lose control. This is why many people complain that there is little freedom in doing things in large companies, but the success rate of doing things is higher. You may be very clear about what functions are in your module. You boldly use from your_own_module import *, but your code does not only belong to you, your code belongs to the entire team. When other members of the team see you writing this way, it is easy for them to follow suit. After all, the project code style is not the result of the cooperation between the teams? After you finish writing this code, you can’t tell everyone, “Although I used import, this is my privilege. You can’t learn from me”, right? Therefore, it is better to make a good code specification directly across the board. It’s hard to make people self-discipline, but it’s much easier to make people obey the rules


By zhiwo

0 0 vote
Article Rating
Notify of
Most Voted
Newest Oldest
Inline Feedbacks
View all comments
8 months ago

There is no such absoluteness. Some modules are designed for import *. These modules export a large number of symbols. It is not acceptable whether it is imported one by one or always with the module name. It is common in certain DSL definitions. Library. These modules will carefully consider variable naming and rename symbols that should not be exported to the form beginning with an underscore to prevent them from being accidentally exported by import *. When using these libraries, you can choose to inport * in a separate module or a function to avoid symbol name conflicts to the greatest extent. Modules other than this are generally not suitable for arbitrarily using import *. It will be difficult to control the symbol names imported into the current module. Once multiple modules have the same name, it will be very troublesome.

8 months ago

The essence of this question is very simple: because naming a child is afraid of the same name, writing a program is also afraid of the same name. Almost all modern programming languages ​​use this method to avoid duplication of names: write variable names or function names in a complete “package name + identifier” way. For example, random.randint(1,9) or math.cos(0). This is similar to many people named Wang Qiang, but they can be named in the way of Zhiqiang Primary School. Third Grade Second Class. Wang Qiang, avoiding duplicate names. Happening. When we write simple small programs, we don’t want to write very long function names. We can use simple writing: from random import *The advantage of this is that it is very convenient to use the functions of the random library. Just write randint directly, which saves trouble. The disadvantage is that if the program is large, the problem of duplicate names will almost certainly occur. And for a dynamic language like Python, the same name will cause the variable to be overwritten directly, which is simply a disaster: def randint():
print(“This is a random function”)
from random import *
# Operation result: TypeError: randint() missing 2 required positional arguments:’a’ and’b’
# Reason: When import *, the previously defined randint was directly overwritten. So the conclusion is: for small enough exercises and test programs, how to write and how to write. Once you have a slightly larger program, try not to use from xxxx import * as much as possible. If you are not careful, the problem of variable names will occur. Just to save a few words and cause a lot of trouble. In fact, other languages ​​are the same, such as C++: using namespace xxx; will also cause similar problems.

8 months ago

Using the wildcard import (from xxx import *) will make it unclear which variables or method identifiers are in the current namespace. The consequence of this is that when others look at your code (including yourself in the future), they will be very confused about some of the variables or methods used in your code because they are not explicitly declared. At the same time, the wildcard import may also cause interference to some automated code analysis tools, as well as the problem of conflicting identifiers of variables or methods in different packages. However, in a package, the internal interface is repackaged for public use, such as in the __init__.py of some packages. In this case, it is possible to use the wildcard import. Example: angr/__init__.py 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. There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn’t known in advance) .

8 months ago

I’ve seen some projects done like this in my work. This kind of writing is very disgusting. In addition to causing problems such as overwriting of variable\function names under different modules, it also causes extremely poor code readability. After a project imports more modules, readers are often confused: Damn, where does this function come from? What the hell is that function? Is it customized by the author? Or is it a built-in function? Is it numpy or scipy? Is it PIL.Image or cv2? Greatly increase the workload of reading code. The wording of from xxx import *, except for the interactive command line, cannot appear in any project file.

8 months ago

You can look at the code abstractly. Import numpy can be understood as creating a folder on the first layer, main.py
def function1()def function2()
numpy |- numpy.random()
|- The numpy.exp() function is placed in the second-level folder, so the full function name should be used to direct the call when calling it. numpy.random() will become main.py if from numpy import *
def function1()
def function2()
np.random()np.exp() When your custom function or functions of several libraries have the same name, the previous function will be overwritten. Especially when large projects, the library called is complicated and has disastrous consequences. …The extended operation is: when your project file looks like this-project
|- file1
|- test1.py
|- file2
|- test2.py If you want to use test2.py in test1.py, you can use import sys
from file2 import test2.py is like visiting the upper-level folder of this file first, and then importing the same-level files. So generally it’s best to write import numpy as np
import torch
From torchvision import datasets, transforms are relatively easy to read, and you can search for the place of import at any time when you can’t remember the calling situation.

8 months ago

Give a simple example. If you want to import a package, you choose to use from a import *. Then you need to import the b package again, and you also wrote from b import *. Coincidentally, there is a method named add in both packages. So when you write add(), who knows whether you are calling the add method in package a or the method of the same name in package b. The use of import a and import b is simple and straightforward. When you want to use the add method, you will naturally write a.add() or b.add(), and the difference will be clear and identifiable.

8 months ago

Because this way of writing is poisonous. . . When you are maintaining a large-scale project, you have finally finished writing the code, and a circular dependency warning is found after running a bit. It took a long time to solve the circular dependency. Especially when the layering is not well designed, this kind of circular dependency, the lower layer depends on the upper layer, often occurs, and it is painful to maintain. contains a large number of classes, it is easy to conflict with other imports, and the principle of least dependency should be observed when importing, and try to avoid the impact of importing other useless components. When it is maintained in the future, new modules are imported, and there are components with the same name as the current *. These components are overwritten. This bug is really a cup of tea, a pack of cigarettes, and a bug for a day.

8 months ago

Let me also write an answer. I strictly require my subordinates to neither write from import * nor import. I hope they strictly write from import a, b, c. Because I need them to know exactly which specific methods are used in the current code file. I also need to let me know at a glance what is being used during code review. So what should I do if there is the same function name (such as a function) in the from import * and from ooo import * mentioned by Xiongtai below? A nice way is that the IDE will tell you that when you write from xxx import a and from ooo import a, it will prompt an error. If an error is prompted, the next-level referer needs to rewrite it into from ooo import a as func_a or similar code.

8 months ago

For python, it will cause naming conflicts. This other answer has already said, but if it is not limited to python, the sentence “in any case” is not accurate. The core of this problem is if this kind of writing will cause errors, when will the error be discovered? For scripting languages like python, the error will be reported at runtime, so you need to avoid this kind of writing. It usually doesn’t matter for compiled languages. If there is an ambiguity that cannot be compiled, it will not cause a runtime error. As long as it does not cause a runtime error, it does not matter, just use it. Even if it is python, if you use MicroPython AOT to compile to the microcontroller, there is no problem with from import

8 months ago

Those who oppose this way of writing are mainly because this way of writing will cause the imported method to have the same name. However, shouldn’t the duplicate name check be done by the computer? Why sacrifice the convenience of programmers? You know you will use multiple methods in this library, why not introduce them at once? If a language can’t even do this basic reminder, just switch to another language, why not go with yourself. Reading the code starts from the entry of the code. I have never seen anyone who can read the import, so the import is written purely for the computer. Don’t worry about the nonsense that improves readability. The most important thing to understand when reading the code is to understand what it does. It would be a waste of time to manually check whether there is a duplicate name.

Would love your thoughts, please comment.x