1. Fundamentals
- Importing a module is nothing but granting access to another Python code.
There is a difference between a package and a module.
- A module is simply a single Python file while a package is a set of modules (Python scripts/files) inside of a directory that may have an __init__.py file (in the case of a namespace there’s no __init__.py file)
Relative Vs Absolute imports
- Absolute imports specify the full path from the top-level package folder. However, absolute imports are not always a great approach if the structure of the project is complex, for example:
from myproject.subpkg1.subpkg2.subpkg3.module import wtf
- Relative imports specify the path from the current directory. With relative import, we can simply reduce the previous import statement to:
from ..subpkg3.module import wtf
2. Holy Namespace Packages
- Namespace packages let you split the sub-packages/modules within a single package across multiple and separate distribution packages.
- In Python 3.3 and later versions with Implicit Namespace packages, there is no need for __init__.py
- __init__.py? Namespace packages in Python 3.3 and later be like
3. Behind the scenes
When you make an import statement, it can be triggered through an import function as well; like __import__() or importlib.import_module() Python looks for it in several directories.
The interpreter searches for the imported module/package in the following locations sequentially
- Current directory
- Library of standard modules
- sys.path or PYTHONPATH (they are not the same but they relate)
Modules/Packages are imported once per process, and that’s because they get stored in the cache aka sys.modules.
4. Asterisk operator *
- It’s not advisable to use the Asterisk operator in the import statement because it corrupts the namespace as it imports all the methods and attributes into your own namespace.
from dontDoThis import *
- But there’s another way to make it legit, which is by using __all__ and defining what modules shall be loaded, as below:
5. What does Venv exactly do?
In order to create an isolated Python environment you can use venv/virtualenv which will create a directory that will allow you to use a custom version of python.
But how does it relate to sys.prefix?
sys.path is assembled of 3 parts:
- sys.prefix
- PYTHONPATH
- site.py
So in order to define the installation path, the venv/virtualenv need a prefix that is usually to get from base_exec_prefix which is:
Set during Python startup, before site.py is run, to the same value as exec_prefix. If not running in a virtual environment, the values will stay the same; if site.py finds that a virtual environment is in use, the values of prefix and exec_prefix will be changed to point to the virtual environment, whereas base_prefix and base_exec_prefix will remain pointing to the base Python installation. (Python doc, 2022)
Finally, as a recap for this article:
- Modules are just objects
- Asterisk can be controlled
- Venv/virtualenv does nothing but play with the prefix
Reference:
- Python doc. (2022). sys — System-specific parameters and functions. Retrieved from https://docs.python.org/3/library/sys.html
