Python Заметки

2021-02-03 12:00:17 Что делать если нужно поставить какую-то Python-библиотеку а root-прав нет? То есть в систему библиотеку никак и ничего не поставить.
Есть как минимум два способа это решить правильно!

Сделать виртуальное окружение и ставить там что угодно.
Это позволит создать полностью независимое исполняемое окружение для ваших приложений.
Все библиотеки будут храниться в домашней директории юзера а значит доступ на запись имеется.
Создать очень просто:

python3 -m venv ~/venvs/myenvname

Теперь активируем окружение

# Linux
source ~/venvs/myenvname/bin/activate

# Windows
%userprofile%\venvs\myenvname\Scripts\activate.bat

Можно ставить любые библиотеки и запускать приложение.
Это стандартный метод работы с любым проектом. Если еще не используете его, то пора начинать. Даже при наличии root доступа!

Бывает, что нет возможности запустить приложение из своего виртуального окружения. Например, его запускает какой-то сервис от вашего юзера и вставить активацию окружения вы не можете.

В этом случае можно установить библиотеки для Python не глобально в систему, а только для юзера.
Выполните этот код в консоли:

python3 -m site

Вы получите что-то такое:

sys.path = [
'/home/user',
'/usr/lib/python37.zip',
'/usr/lib/python3.7',
'/usr/lib/python3.7/lib-dynload',
'/home/user/.local/lib/python3.7/site-packages',
...
]
USER_BASE: '/home/user/.local'
USER_SITE: '/home/user/.local/lib/python3.7/site-packages'
ENABLE_USER_SITE: True

Нас интересует параметр USER_SITE. Это путь к пользовательским библиотекам, которые доступны по умолчанию, если они есть.
Именно сюда будут устанавливаться модули если добавить флаг --user при установке чего-либо через pip

pip install --user requests

Для этой команды не нужны root-права.
После неё можно запускать системный интерпретатор без виртуальных окружений и установленная библиотека будет доступна для текущего юзера.

Параметр USER_BASE показывает корневую директорию для хранения user-библиотек. Её можно изменить с помощью переменной окружения PYTHONUSERBASE

export PYTHONUSERBASE=~/pylibs
python3 -m site
...
USER_BASE: '/home/user/pylibs'
USER_SITE: '/home/user/pylibs/lib/python3.7/site-packages'

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

Дописывание пути в PYTHONPATH
Этот способ не входит в список "двух правильных", но тоже рабочий. Здесь придётся сделать всё несколько сложней.
Сначала ставим библиотеку в любое место указывая путь установки

pip3 install -t ~/mylibs modulename

Библиотека установится без привязки к какому-либо интерпретатору. То есть по умолчанию не будет видна. Теперь в нужный момент добавляем этот путь в sys.path или в PYTHONPATH.

Не буду советовать так делать. Единственный раз когда этот способ мне пригодился и решил поставленную задачу, это при создании общей библиотеки для кластера компьютеров.
Модули лежат в сети и подгружаются для всех из одного и того же места. То есть обновлять файлы требуется только один раз а не на всех хосты отдельно.

Минусы такого подхода:
Нужно всем хостам пробить нужный путь в .bashrc или ещё куда-то чтобы он сетапился на старте.
Чем больше хостов тем больше нагрузка на сеть. Иногда такой способ не подходит именно по этой причине. Тогда Ansible вам в помощь.
Не очень подходит если хосты с разными операционками. Некоторые библиотеки различаются для Linux и Windows (там, где есть бинарники) и приходится мудрить более сложные схемы.

#tricks #basic Открыть/Комментировать

2021-02-01 12:00:15 Вы заметили что с интерактивной консолью из прошлого поста что-то не так? Что происходит если нажать стрелки вверх/вниз? Полный бардак!
Давайте поправим это дело!
Для сохранения и загрузки истории будем использовать специальный модуль readline.

Что добавлено?

Сохранение истории команд с возможностью выбора предыдущих (клавиши )
Сохранение истории в файл перед выходом из интерактива для будущих сессий
Автокомплит по нажатию клавиши TAB
Cписок вариантов автокомплита по двойному нажатию TAB


Код забираем здесь

#tricks #source Открыть/Комментировать

2021-01-29 12:00:14 Ранее мы уже говорили о том, как выполнить какой-либо код перед открытием интерактивной консоли.

Расскажу еще один способ! На самом деле, даже запустив интерпретатор в обычном режиме с выполнением скрипта из файла вы можете в любом месте активировать интерактивный режим. Или даже несколько по очереди. За это отвечает модуль code.

Как это может пригодиться?

Вам не хватает pdb и хочется больше "власти"
Нужно запросить у юзера данные в достаточно сложном виде. В этом случае можно попросить его создать что ему надо и сохранить в определённую переменную, с которой потом и работать.
Нужна изолированная среда для выполнения каких-либо действий.
Просто забавы ради

Запускается консоль очень просто

import code
ic = code.InteractiveConsole()
try:
ic.interact()
except SystemExit:
pass

Выход обратно на предыдущий уровень происходит как обычно, вызов функции exit() или клавиши Ctrl+D (Ctrl+Z для Windows).

Я набросал простой пример с некоторым функционалом

Меняются символы приглашения
В неймспейсы добавляются дополнительные объекты
Считается время, проведённое в интерактивном режиме
Скрипт просит юзера заполнить переменную и по выходу распечатывает её значение

Код здесь

Для запуска сохраните код в файл и запускайте как обычный скрипт.

python my_console.py

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

alias py="python3 /home/username/my_console.py"

#tricks #source Открыть/Комментировать

2021-01-27 12:00:18 Вы уже знаете, что можно добавить ZIP архив в PYTHONPATH и использовать его как библиотеку.
У Python есть еще одна интересная стандартная библиотека zipapp. Она поможет создать стендалон (или почти стендалон) приложение с помощью ZIP архива.
На самом деле мы получим всё тот же архив но с некоторыми дополнениями

У него будет точка входа, то есть функция, которая запускается при старте приложения
У архива будет расширение PYZ, хотя, это тот же ZIP
Архив можно сделать исполняемым как простое приложение (только для Linux)

Давайте создадим простое приложение. Можно указать директорию или файл. Удобней всего делать приложение из директории. При этом все файлы внутри указанного пути попадут в архив.
Вот такая структура приложения у нас есть:

myapp/
app.py

А это код приложения

# app.py
def main():
print('START APP')

Создаём ZIP-приложение:

python3 -m zipapp myapp

Скорее всего вы получите ошибку, так как не указана точка входа.

ZipAppError: Archive has no entry point

Чтобы это исправить следует в директории рядом с app.py создать файл __main__.py. Именно он будет выполняться при старте приложения. Либо просто указать флагом --main функцию внутри архива которую надо выполнить, и zipapp сам создаст этот файл с нужными импортами.

python3 -m zipapp myapp --main=app:main

Мы получим файл myapp.pyz который можно запустить с помощью Python

$ python3 ./myapp.pyz
START APP

Чтобы запускать это приложение просто по даблклику без дописывания python, следует сделать файл исполняемым и в начало дописать так называемый shebang line (только для Linux).
Вы скорее всего видели их в Bash-скриптах. Там написано с помощью какого интерпретатора запускать данный скрипт. В нашем случае надо дописать в начало ZIP-файла такую строку:

#!/usr/bin/env python3

Это можно сделать с помощью флага --python

python3 -m zipapp myapp --main=app:main --python '/usr/bin/env python3'

Теперь в начало архива добавится нужная строка а сам файл станет исполняемым.

А вот так можно добавить эту строку ручками после создания архива

echo '#!/usr/bin/env python3' > myapp2.pyz
cat ./myapp.pyz >> myapp2.pyz
chmod +x myapp2.pyz

Остаётся добавить флаг --compress чтобы сжать архив.

python3 -m zipapp myapp --main=app:main --python '/usr/
bin/env python3' --compress

Можно сказать, что наше элементарное приложение готово

Что ещë можно сделать?

Как видите, это не полноценный стендалон. Для запуска приложения всё ещë требуется Python в системе. Чтобы ваше приложение завелось на чистой системе можно добавить в директорию myapp все зависимости приложения, то есть любые нестандартные внешние библиотеки. Для работы приложения потребуется только сам Python.

Можно добавлять любые файлы ресурсов. Для их использования потребуется извлечение этих файлов из архива. Например, если закинуть картинку в корень myapp

myapp/
app.py
image.jpg

то достать её можно так:

import pkgutil
# достаём данные
img_data = pkgutil.get_data('__main__', 'image.jpg')
# сохраняем в файл
open(filename, 'wb').write(img_data)

На самом деле исполняемый файл можно сделать и для Windows, но там всё несколько сложней

#tricks Открыть/Комментировать

2021-01-25 12:00:54 В PYTHONPATH или в sys.path можно указать путь к ZIP архиву с Python-модулями и пакетами.
export PYTHONPATH=~/my_py_archive.zip

Всё будет выглядеть так, как если бы архив был директорией.

Можно также указать вложенную директорию внутри архива.

export PYTHONPATH=~/my_py_archive.zip/lib

Следует только помнить, что в таком случае пути к модулям будут не актуальны. То есть переменная __file__ будет вести к файлу внутри архива, но с ним не стоит работать как с обычным файлом.

>>> import main
>>> print(main.__file__)
'/home/user/my_py_archive.zip/main.py'

Если вы в архив поместили какие-то ресурсы, то следует сначала их извлечь во внешние файлы или загрузить в память прямо из архива.

import pkgutil
text = pkgutil.get_data(my_pkg.__name__, 'README.md')

____________________
WHL файлы тоже являются ZIP-архивами. Так что с ними это сработает тоже. Но у них иная задача и лучше так не делать.

#tricks Открыть/Комментировать

2021-01-22 12:00:14 Как работает функция reload()?

Эта функция нужна для того, чтобы перезагрузить изменившийся код из py-файла без рестарта интерпретатора.
Дело в том, что любой импортированный модуль при повторном импорте не будет перечитывать файл. Функция импорта вернёт уже загруженный в память объект модуля. Чтобы обновить код, нужно либо перезапустить всю программу, либо использовать функцию reload()

from importlib import reload
reload(my_module)

Функция reload() принимает в качестве аргумента только объект модуля или пакета. Она не может перезагрузить класс или функцию. Только весь файл целиком!

Перезагрузка пакета перезагрузит только его файл __init__.py, если он есть. Но не вложенные модули.

Она не может перезагрузить ранее не импортированный модуль.

При вызове функция reload() перечитывает и перекомпилирует код в файле, создавая новые объекты. После создания новых объектов перезаписывается ранее созданный неймспейс этого модуля.
Это значит, что если где-то этот модуль импортирован через import и обращение к атрибутам происходит через неймспейс (имя) модуля, то такие атрибуты обновятся.
Если какие-либо объекты из этого модуля импортированы через from то они будут ссылаться на старые объекты.

Напишем простой модуль

# mymodule.py
x = 1

Теперь импортируем модуль и отдельно переменную х из модуля

>>> import mymodule
>>> from mymodule import x
>>> print(mymodule.x)
1
>>> print(x)
1

Не перезапуская интерпретатор вносим изменения в модуль

# mymodule.py
x = 2

Делаем перезагрузку модуля и проверяем х ещё раз

>>> reload(mymodule)
>>> print(mymodule.x)
2
>>> print(x)
1

То же самое будет если присвоить любой объект переменной (даже словарь или список)

Повторный импорт обновляет значение

>>> from mymodule import x
>>> print(x)
2

Созданные инстансы классов не обновятся после перезагрузки модуля. Их придётся пересоздать.

#tricks #basic Открыть/Комментировать

2021-01-20 12:00:16 Как получить минимальную информацию о модули не импортируя сам модуль?
Стандартная библиотека pyclbr позволяет это сделать. Она не импортит модуль, а только парсит код и возвращает список имеющихся в модуле классов и функций в виде специальных объектов. Например, вы сможете узнать какие в модуле есть классы, от чего они наследованы и какие у них методы.

Возьмём для примера такой простой модуль

# mymodule.py
class Cls1:
def __init__(self):
pass

def execute(self):
pass

class Cls2(Cls1):
pass

def start():
pass

Запускаем анализ

>>> import pyclbr
>>> mdata = pyclbr.readmodule_ex('mymodule')
# список всего что нашлось
>>> print(mdata)
{'Cls1': ,
'Cls2': ,
'start': }

# список методов класса (имя метода и строка объявления)
>>> mdata['Cls1'].methods
{'__init__': 3, 'execute': 6}

# получения наследуемых классов
>>> mdata['Cls2'].super
[]
>>> mdata['Cls2'].super[0].name
'Cls1'

#libs #tricks

2.2K views09:00

Открыть/Комментировать

2021-01-18 12:00:14 Бывает начинающие в процессе обучения создают файлы с именем модуля который они изучают. В результате на тестовых запусках ничего не работает

Всё потому, что появилась коллизия имён. Например, изучаете вы модуль datetime, и создаёте с таким именем файл (ну логично же ) прямо в рабочей директории.
Потом, при попытке импортировать datetime модуль, из-за приоритета импорта будет импортирован файл из рабочий директории а не оригинальная библиотека. Ведь имя файла это суть имя модуля!

А знаете ли вы, что не все стандартные модули можно так перезаписать? Коллизии имён не подвержены builtin модули. Они всегда стоят на первом месте в приоритете импорта, поэтому их нельзя заменить.

Полный список таких модулей можно посмотреть в списке sys.builtin_module_names.

То есть, вы сломаете весь Python если назовёте свой модуль os или site, но если назовёте time или gc то ничего страшного не случится)))

Тем не менее, никогда не называйте модули уже занятыми именами!!!

Я всегда рекомендую всем своим файлам делать именной префикс из 2-3 символов. Например я называю свои проекты так:

pw_project_name
pw_ui_tools.py
pw_something/main.py

Либо под ситуацию

tst_scriptname.py
(не "test" чтобы не подхватывал pytest)
dbg_script.py
maya_ui.py
hou_menu_tools.py

И искать проще, и коллизий нет.

#tricks #basic Открыть/Комментировать

2021-01-15 12:00:16 Релятивный импорт в исполняемом файле

Часто встречается ситуация, когда исполняемый скрипт находится внутри Python-пакета. Например, представим такую структуру библиотеки:

my_lib/
cmd/
start.py
stop.py
core.py
services.py

Для запуска каких-то процессов мне надо исполнить скрипт start.py и вот как я делаю его вызов:

python3 /mnt/libs/my_lib/cmd/start.py

Пока выглядит всё красиво.
Но что, если я внутри этого файла хочу импортировать модуль services.py? При этом я хочу использовать релятивный импорт

# start.py
if __name__ == "__main__":
from .. import services

Я получу такую ошибку:

ValueError: attempted relative import beyond top-level package

Эта ошибка возникает потому, что интерпретатор просто не знает что мы находимся внутри пакета и не может понять куда это мы собрались выйти на уровень выше)

Есть три способа как избежать этой ошибки. Все они требуют чтобы библиотека my_lib находилась в доступном для импорта месте, то есть в моëм случае чтобы путь /mnt/libs был в sys.path.

Просто пишем полный путь импорта

if __name__ == "__main__":
from my_lib import services

Это сработает. Но, очевидно, что это не то, что мы ищем. Нам нужен релятивный импорт.

Если интерпретатору подсказать имя пакета в котором мы находимся, то всё заведётся. И есть два способа это сделать. Первый способ — это запускать не через имя файла а по имени модуля

python -m my_lib.cmd.start

Уже самой командой мы обозначили все необходимые неймспейсы.

Если предыдущий способ недоступен (то есть запускаем именно по пути к файлу .../start.py), то объявляем имя пакета прямо внутри кода. Для этого используем переменную модуля __package__

if __name__ == "__main__":
if __package__ is None:
__package__ = 'my_lib.cmd'
from .. import services

Кстати, мы также можем при необходимости:
динамически определить имя пакета в котором находимся
добавить необходимые пути к основной библиотеке в sys.path перед импортом
переместить обновление __package__ в начале скрипта вместе со всеми импортами но обязательно с проверкой is None!

#tricks Открыть/Комментировать

2021-01-13 12:00:16 Мы уже знаем, что на текущую сессию интерпретатора изменение PYTHONPATH никак не повлияет. Но если вы запустите дочерний процесс, то он унаследует окружение текущего процесса, а значит и изменения в любых переменных будут на него влиять.
Вот небольшой пример:

Объявляем переменную

user@host:~$ export PYTHONPATH=/path1

Запускаем интерпретатор

user@host:~$ python3

Проверим что в sys.path

>>> import sys
>>> print(sys.path)
['', '/path1', '/usr/lib/...', ...]

Добавляем что-то в переменную

>>> import os
>>> os.emviron['PYTHONPATH'] = '/path1:/path2'
>>> print(sys.path)
['', '/path1', '/usr/lib/...', ...]

Изменений нет. Но давайте запустим дочерний процесс и посмотрим там

>>> os.system('python3')
# теперь мы находимся в другом процессе
>>> import sys
>>> print(sys.path)
['', '/path1', '/path2', '/usr/lib/...', ...]

Тоже самое будет и с subprocess, так как по умолчанию текущее окружение тоже наследуется.

>>> import subprocess
>>> subprocess.call(['python3', '-c', 'import sys;print(sys.path)'])
['', '/path1', '/path2', '/usr/lib/...', ...]

______________________
Лучшей практикой является передача энвайронмента явно через аргумент env!

import subprocess
subprocess.call(cmd, env={'PYTHONPATH': '...'})

Это поможет точно понимать какое окружение будет у запускаемого процесса и при этом не изменять окружение текущего процесса.

#basic Открыть/Комментировать