Linux python import module

Python import, как и для чего?

В языке программирования Python подключение пакетов и модулей осуществляется с помощью import. Это позволяет распределять код по логическим «узлам» приложения(модели данных, обработчики, и тп.), что позволяет получить менее нагруженные кодом файлы.

• Повышается читаемость кода.
• Код логически разбит по «узлам», его поиск и дальнейший отлов ошибок становится понятнее и проще.
• Для разработки в команде это дает более четкое понимание, что и где делает каждый при выполнении «задания».

Как использовать import?

Синтаксис import в Python достаточно прост и интуитивно понятен:

# В данной строке импортируется something_we_want import something_we_want # В данной строке импортируется something_we_want, как aww(логично и просто) import something_we_want as aww # В данной строке импортируется из something_we_want something(логично и просто) from something_we_want import something # В данной строке импортируется из something_we_want something, как s(логично и просто) from something_we_want import something as s # Синтаксис as позволяет обращаться к импортируемому по новому нами описанному # далее имени(это работает только в рамках нашего файла)

Что можно импортировать?

Для более глубокого понимания import стоит рассмотреть пример, представленный ниже.

def something(): pass somedata = 5

# 1 случай import something_we_want something_we_want.something() import something_we_want print(something_we_want.somedata) # 2 случай import something_we_want as aww aww.something() import something_we_want as aww print(aww.somedata) # 3 случай from something_we_want import something something() from something_we_want import somedata print(somedata) # 4 случай from something_we_want import something as s s() from something_we_want import somedata as sd print(sd) # Классы импортируются по аналогии с функциями

Красиво, читаемо и понятно.

В чем же подвох?

Но даже в таком простом примере есть подвох, о котором многие не догадываются(если вы начинающий программист, то лучше перейдите к следующему оглавлению).

Идеология Python достаточно интересна, что позволяет ему иметь низкий порог вхождения, низкое время написания кода, высокую читаемость, но именно в ней и кроется подвох.

По своему опыту использования данного языка, сложилось отчетливое ощущение главной идеи ООП(все есть объект). Что же в этом плохого?

Все файлы, функции и тд. это объект. Но что это за объект и класс стоят за файлами(модулями)?

Все просто, это любимый всеми программистами класс, использующий паттерн проектирования Singleton.

Поэтому при достаточно ветвистой структуре, импорт переменной и дальнейшая ее модификация может порождать достаточно не простые в понимании баги(переменная в своем цикле жизни может иметь любое значение и никаких гарантий нет).

Ветвистая структура приложения и существующие подходы импортирования

Часто в разработке приложений программисты пытаются разбить программу по логическим «узлам». Данный подход повышает читаемость и позволяет вести разработку в команде(один человек занимается реализацией одного «узла», второй другого). Так порождается структура приложения, которая зачастую виду сложности функционала является достаточно обширной(ветвистой, потому что имея одну точку входа откуда уже обрастая функционалом это становится похожим на дерево).

Пример ветвистой структуры:

Существует 2 подхода импортирования(лучше выбрать один и придерживаться его весь проект):

Пример именованного импорта из models.py в auth.py:

# auth.py from app.models import User

Пример неименованного импорта из models.py в auth.py:

# auth.py from ..models import User # Количество точек указывает на сколько (обьектов) мы поднимаемся от исходного. # В данном примере первая точка поднимает нас на уровень обьекта handlers, # А вторая точка поднимает нас на уровень обьекта app

Это два абсолютно разных подхода. В первом случае мы «идем» из «корня»(входной точки нашего приложения). Во втором случае мы «идем» от «листа»(нашего файла).

Плюсы и минусы подходов импорта:

Видна структура импорта и приложения.

Видна часть структуры импорта.

Программисту не нужно знать полную структуру приложения.

Импорт не зависит от точки входа.

Код становится не привязанным к приложению. Что по сути позволяет исполнить код из любой точки(тесты, отдельно и тд.). Повышается отлаживаемость. Появляется возможность разработки отдельных узлов приложения без полного вовлечения программиста в проект.

Импорт зависит от точки входа.

Программисту необходимо знать структуру приложения. Код сильно связан с приложением. Что по сути усложняет отладку, тестирование, и тд. Программист становится сильно вовлеченным в проект.

Снижается читаемость импорта.

Хоть первый подход и имеет существенные минусы в использовании, но тем не менее он популярен. Программистам он привычнее, хоть и имеет недостатки. А начинающие часто не задумываются об альтернативах.

P.S.

Данная статья была написана для начинающих программистов, которые хотят научиться писать на языке программирования Python, поэтому часть примеров заведомо упрощена и нацелена на освещение существующих подходов.

Пишите тот код, который бы сами хотели получить от исполнителя.

Источник

How to import local modules with Python

Importing files for local development in Python can be cumbersome. In this article, I summarize some possibilities for the Python developer.

TL; DR: I recommend using python -m to run a Python file, in order to add the current working directory to sys.path and enable relative imports.

Definitions

Script: Python file meant to be run with the command line interface.

Module: Python file meant to be imported.

Package: directory containing modules/packages.

Example

Consider the following project structure:

project ├── e.py └── src ├── a │ └── b.py └── c └── d.py 

Say that in b.py , we want to use d.py :

Let’s try to run python from the project directory:

~/Documents/code/project$ python3 src/a/b.py Traceback (most recent call last): File "/home/qfortier/Documents/code/project/src/a/b.py", line 4, in import src.c.d ModuleNotFoundError: No module named 'src' 

What happened? When Python tries to import a module, it looks at the paths in sys.path (including, but not limited to, PYTHONPATH):

~/Documents/code/project$ python3 src/a/b.py ['/home/qfortier/Documents/code/project/src/a', '/usr/lib/python38.zip', '/usr/lib/python3.8', . ] 

We see that the directory containing b.py (the script we run) is added to sys.path . But d.py is not reachable from the directory a , hence the above error.

1st solution: add root to sys.path

We can add the path to the root of the project:

~/Documents/code/project$ python3 src/a/b.py ['/home/qfortier/Documents/code/project/src/a', . '.'] 

The added path ‘.’ refers to the current working directory (from which Python was run) ~/Documents/code/project. Python can indeed import c.d from this directory.

This solution works regardless of the directory used to run Python:

~/Documents/code/project$ cd ../.. ~/Documents$ python3 code/project/src/a/b.py ['/home/qfortier/Documents/code/project/src/a', . 'code/project'] 

It should also work on a different computer, with a different filesystem or OS, thanks to Pathlib.
However, modifying sys.path at the beginning of every file is tedious and hard to maintain. A better solution would be to use a context.py file modifying sys.path and imported by every other file, but this is still unsatisfying.
Another possibility is to add the root directory to PYTHONPATH (before running the script). This is done automatically by poetry , for example.

Relative import

Relative imports were introduced in PEP 328 as a way to improve maintainability and avoid very long import statements. They must use the from .module import something syntax:

~/Documents/code/project$ python3 src/a/b.py Traceback (most recent call last): File "src/a/b.py", line 4, in from ..c import d ImportError: attempted relative import with no known parent package 

This is not working! Indeed, relative imports rely on the __name__ or __package__ variable (which is __main__ and None for a script, respectively).
If we import b.py from another file, everything is fine:

~/Documents/code/project$ python3 e.py Name: src.a.b Package: src.a 

Note: to go up several directories in relative imports, use additional dots: from . c import d would go 2 directories up, for example.

2nd solution: run as a module

It is unfortunate that scripts can’t use relative imports. PEP 338 overcomes this limitation by adding the -m option. With this option, a script is run as if it was imported as a module.

~/Documents/code/project$ python3 -m src.a.b # note that we use . and not / here Name: __main__ Package: src.a 

python3 -m src.a.b acts as if a Python file containing import src.a.b was run in the current directory, with two notable differences:

• the __package__ variable is filled, enabling relative imports (see PEP 366)
• the directory from which Python was run (here: ~/Documents/code/project) is added to sys.path

Since I don’t see any drawback to this, I recommend always using python3 -m to run a script.

Run as a module on Visual Code

The default launch configuration in Visual Code runs Python files as scripts (without -m ). This GitHub issue explains how to add -m automatically:

• add the “Command Variable” extension to Visual Code
• set the following Python launch configuration in your settings.json:

3rd solution : modify PYTHONPATH

With Visual Code, you can automatically add the root directory to your project by adding a line to the launch configuration :

Alternatively, you can add a .env file in the root directory :

4rd solution (outdated): install in editable mode

pip install -e . installs a package in editable mode, which can then be imported anywhere on the computer. In practice, this is essentially a symbolic link to your package. Therefore, any modification of the package is reflected on the code importing it. It requires a setup.py at the root of your package.

Note: according to PEP 517, this is no longer recommended: Python packages should rely on a toml file (see Poetry) and not on setup.py anymore.

References

Updated: May 9, 2021

Источник