About the module import method under the Python package [go]

2012 there is a goal I did not achieve, that is in-depth study and use of the Python language. This goal by other learning tasks and work ruthless preemption, of course, the main reason is that I value enough ^_^.

In the near future, there are some Python project development work to do, and in the way a bit more in-depth study of Python: read a few Python English tome, such as "Learning Python 4th Edition", "Python Essential Reference 4th Edition "," Programming python 4th Edition "," Expert python Programming "and" The Python standard library by Examp " Le ", see I have some to vomit ^_^. Although previously developed with Python BUILDC, but the self-feeling is still a python absolute beginner, this time through the books of the study is a more systematic understanding of python.

To get to the point, today is a question about the module import under the Python package, which I encountered when I was doing a Python project source organization design. In general, our engineering code is organized as follows:

py-proj/
main.py
pkg1/
__init__.py
mod1.py
pkg2/
__init__.py
mod2.py
test/
__init__.py
testmod1.py
testmod2.py

The project's dev requirements are as follows:

* Execute main.py (which import the module of each pkg)
* One module under PKG can be executed separately
* Brother Pkg can import module between each other
* The test case of a module under test can be executed separately
* Can execute test case of all module under test at once

Based on these dev requirements for the project, let's take a look at the module import options.

Python supports two package import methods since version 2.5: Absolute import and relative import. However, Guido van Rossum explicitly recommended absolute import in Pep 8 for the following reasons: more portable and more readable. After testing, I personally feel that Guido van Rossum's advice is very pertinent. The support semantics of relative import vary between versions and are somewhat complex to understand. "Learning Python 4th Edition" has spent nearly a section of the package relative import, feeling complex difficult to understand. Although relative import can solve some problems, but the sense of input-output is not high. Let's see if package absolute import meets all of our engineering dev needs.

* Executive main.py

Regardless of which directory is currently working directory (current working directory), once executed Main.py,python will automatically add the main.py directory to the Sys.path, as a module search Path of the entry. This way, as long as the works under the documents are absolute Import,python can correctly find and import the correct module.

* Execute a module under a pkg individually

We have this requirement at dev: executing the code for a module that is being written separately to get feedback on some of the execution results. However, with the code structure in the example above, if we go into the Pkg1 directory to execute Python mod1.py, once mod1.py references Pkg2.mod2, you will receive the following error (if you use absolute import):

$ python mod1.py

Traceback (most recent):
File "mod1.py", line 2, <module>
Import PKG2.MOD2
Importerror:no module named PKG2.MOD2

Because Python is simply adding the PKG1 path to the module search path, there is obviously no pkg2/mod2.py under this path. However, we can execute the MOD1 code separately by executing the "python-m pkg1.mod1" under the project top-level path, so that absolute import is still in effect and will not cause import error.

* Brother Pkg can import module between each other

This is similar to the above execution method, as long as the top-level under the python-m execution, then no matter how much the PKG level, no matter how many brothers Package,python can always find the correct module and import.

* Test case of a module under test is executed separately

This is somewhat similar to the case of referring to the sibling package. We do this by executing the python-m test.testmod1 in the top-level path.

* Test use Case for all module at once execution test

Newer versions of Python have been able to automatically discover and execute test cases. By executing python-m unittest discover test in the top-level directory, we execute all the unit test case files under the test directory that meet the UnitTest package conventions requirements. When you execute this command, Python adds the top-level path and the test path to the module search path.

Finally, Absolute import can meet all requirements. Although sometimes absolute import will look a bit verbose from the code (via the From ... import ... can be mitigated), but the simplicity and readability of the semantic understanding makes me more inclined to do so in this way. In addition, normally we do not need to reset the Pythonpath, also can not use the. pth file, and do not need to modify the code in the Sys.path to change the Python module search path.

Note: The above tests were tested under Ubuntu 12.04 LTS Python 2.7.3.

from:http://tonybai.com/2013/01/24/the-module-import-way-under-python-package/

About the module import method under the Python package [go]