renew
Errata:
Several opinions in my original article "python has two import mechanisms", "python has two import methods of "regular import" and "unconventional import"", that is, [point 3] in the conclusion is wrong, but about There is nothing wrong with modifying the various bugs caused by sys.path, that is, [point 4] .
I read a detailed but hypnotic blog [python import mechanism] by a big guy . Although I didn’t read it carefully (because I couldn’t understand it), I already felt that my previous idea was problematic, and then after a simple and bold attempt, Indeed shot.
Because there are too many test samples, I posted a new blog to explain:
[Python] Use exec to import modules under relative paths
original
I posted a blog [click to jump] a few days ago , which was about importing modules under the relative path of python. At that time, I also wrote a class to solve the import problem. Later, because the packaged program could not be run, I immediately added an additional explanation at the beginning of that blog-" If the project is to be packaged and run, then don't use my XJImporter script below "
I didn't want to care about this broken problem, but after thinking about it, I couldn't breathe, thinking that if I didn't get rid of this broken problem, I would have troubles in the future, so I started debugging. It's okay if I don't try it. The fog gets more and more strange. Then I wrote a few test samples after figuring it out. The following is a graphic description:
Then here is my own conjecture. It is a conjecture because I did not check the official document [click to jump] , and I did not read other big guys' answers to python's import mechanism. It is completely based on my own Don't you just say that it's a bit ridiculous if you come up with some nonsense conclusions by throwing stones and asking directions? To use a more vivid metaphor:
I am a child who has never read a book. One day I fell from the upper bunk and found it painful.
Then I fell from the lower bunk and found that there was a big difference, so I concluded that "I fell from a higher place. It will hurt more."
But in fact, as early as hundreds of years ago, a group of bigwigs had already discovered the law of gravity, and also measured physical quantities such as the acceleration of gravity,
and can use the corresponding formula to find out how high you fall and how much your weight will bear How many times the unbearable gravity, that is, how much height you fall will definitely kill you.
This is equivalent to a dimensionality reduction blow.
Forget it and continue to be a clown to give my own guess:
- During the packaging process, the project will make a lot of manipulations to the packaged program
- The packaged program, the modules called in it, if it is a module written by yourself, it is very likely to be integrated into the exe file, which is the question in the picture "Where is the *.pyc file? How can I find it?" Less than", most of it is in the exe, but it is not sure which dll file it is actually in? I didn't try it.
- There are two kinds of python imports, at least I think there are two unique import mechanisms that do not interfere with each other, namely [regular import] and [unconventional import]. import) to import the module, and when it cannot be imported smoothly, the module will be imported in the way of "unconventional import" (that is, using sys.path). So you can see the very different running results of the script and the program in my fourth picture above .
- According to the third point, I can clearly say that when you
sys.pathpress an absolute pathC:/Users/Administrator/Desktop/Test/Module/like this into it, then the program packaged by your project can run at present, but if, if you happily put This is basically what happens when you send it to others and say "try it quickly": Hey, my computer is still running fine, why can't it run when it comes to you? Is there something wrong with your computer? Or one day you feel that this project is too obstructive to put on the desktop, and you drag it to another path, then congratulations, this project has been ruined, and you will probably send out soul torture: What's going on? Why is it so evil ? The sky is fine, but why can’t I run all of a sudden, even though I haven’t moved the program files? To put it bluntly, if sys.path is pressed into a hard path (for example ), then the project will become very fragile, and even just dragging the project somewhere can make the entire project and the program packaged by the project directly scrapped.sys.path.append('E:/****/***/') - After the project is packaged into exe, the project structure will be completely inconsistent with the program directory structure. To put it bluntly, it is "my module file? Why is there no such thing as mentioned in point 2". Here is the biggest divergence between scripts and programs: scripts can ensure the correct import of modules by pressing the appropriate path through sys.path (that is, "unconventional imports"), but programs can only import modules through "regular imports". , if you insist on using "unconventional import", you need to throw the module file into the program directory (it is not recommended to throw the source code directly) or the compiled pyc file/pyd file of the module to make additional corrections to the program.
- To sum up, if your project is going to be packaged and sent out for use, then it is extremely not recommended to make any modifications to sys.path, because even if the script can run after modification, it is very likely that the packaged program cannot run.
- One of XJ's soul questions: Why does the above problem not appear after I import third-party libraries such as PyQt5 and numpy in my project? Why do directories like "PIL", "PyQt5", and "cv2" appear in the program directory after it is packaged? This is completely beyond the scope of my understanding, and I have to find a big guy to answer it.
I put the above test sample in github, if you are interested, you can play with it: https://github.com/Ls-Jan/Python_LanguageFeatures/tree/main/import