Python Заметки

Думаете ˍˍfutureˍˍ нужен только для Python2? Нет, это процесс постоянный. В Python3 тоже есть свои "future". from __future__ import annotations Похоже на бекпорт аннотаций типов из Python3 в Python2, но это не так. Это имплементация PEP 563 Postponed Evaluation of Annotations которая будет дефолтной только в Python4. Что делает этот future? Если вы активно используете аннотации типов в Python3 то знаете, как они обычно выглядят. def func(x: int) -> int: return x * 2 При этом у объекта функции появляется атрибут ˍˍannotationsˍˍ >>> print(func.__annotations__) {'x': <class 'int'>, 'return': <class 'int'>} Видно, что в этой переменной находится словарь. Ключ словаря это имя аргумента функции, а значение это непосредственно ссылка на тип. А так же есть тип для return. В более сложных случаях это будут инстансы объектов из модуля typing from typing import List def func(x: int) -> List[int]: return [x] * 10 >>> print(func.__annotations__) {'x': <class 'int'>, 'return': typing.List[int]} Что происходит если мы импортим annotations из ˍˍfutureˍˍ? Изменяется способ определения аннотаций. Дело в том, что все эти инстансы типов создаются в момент определения функции когда модуль импортируется. Так же как и значения по умолчанию они должны исполниться и вернуть какой-то объект. В нашем случае это ссылка на тип int или инстанс класса typing.List. И тут возникает две проблемы, описаные в PEP. Если коротко то звучит это так: 1. Если в подсказке указывается тип, который еще не определён, это вызовет ошибку. Приходится описывать его просто строкой или менять порядок определения. 2. Определение ссылок на типы порой занимает много времени, так как требуется импорт модулей и создание инстансов. Но если вы импортируете наш future, то активируется так называемое отложенное определение ссылок (Postponed Evaluation of Annotations). В результате вместо создания инстансов и ссылок в ˍˍannotationsˍˍ просто записывается строка с этой подсказкой. from __future__ import annotations def func(x: int) -> int: return x * 2 >>> print(func.__annotations__) {'x': 'int', 'return': 'int'} В дальнейшем ваши IDE и ресолверы типов могут брать эти строки и исполнять самостоятельно где то на фоне, когда все необходимые типы уже определены. Для преобразования этих строк в привычный вид есть готовая функция >>> import typing >>> typing.get_type_hints(func) {'x': <class 'int'>, 'return': <class 'int'>} Но делать это можно уже только по необходимости. #pep

Когда разрабатываете свой GUI с помощью PyQt для какого-либо софта бывает необходимо позаимствовать цвета из текущего стиля интерфейса. Например, чтобы правильно раскрасить свои виджеты, подогнав их по цвету. Ведь бывает, что ваш GUI используется в разных софтах. Причём некоторые со светлой темой а другие с тёмной. По умолчанию стили наследуются, но если вы задаёте какую-либо раскраску для части виджета через свой styleSheet, то требуется ссылаться на цвета текущего стиля. Как это сделать? Как получить нужный цвет из палитры имеющегося стиля? Это достаточно просто, нужно использовать класс QPalette и его роли. Например, мне нужно достать цвет текста из одного виджета и применить его в другом как цвет фона (не важно зачем именно так, просто захотелось😊). Получаем палитру виджета и сразу достаём нужный цвет, указав его роль. from PySide2.QtGui import QPalette color = main_window.palette().color(QPalette.Text) теперь можем использовать этот цвет в стилях my_widget.setStyleSheet(f'background-color: {color.name()};') Готово, мы динамически переопределили дефолтный стиль используя текущий стиль окна! На самом деле есть запись покороче, в одну строку и без лишних переменных. Не очень-то по правилам CSS, но Qt это понимает. my_widget.setStyleSheet('background-color: palette(Text);') Этот способ не подходит если вам нужно как-то модифицировать цвет перед применением в своих стилях. В этом случае потребуется первый способ. Зато он прекрасно сработает в файле .qss, то есть не придётся в коде прописывать раскраску отдельных элементов через ссылки на палитру, всё красиво сохранится в отдельном файле .qss! QListView#my_widget::item:selected { background: palette(Midlight); } Про имеющиеся роли можно почитать здесь🌍 #qt#tricks

Ранее я уже упоминал о другой фишке из ˍˍfutureˍˍ , это оператор деления. from __future__ import division Суть проста. Раньше сложность типа данных результата поределялась типом самого сложного операнда. Например: int/int => int int/float => float В первом случае оба операнда int, значит и результат будет int. Во втором float более сложный тип, поэтому результат будет float. Если нам требуется получить дробное значение при делении двух int то приходилось форсированно один из операндов конверировать в float. 12/float(5) => float Но с новой "философией" это не требуется. В Python3 "floor division" заменили на "true division" а старый способ теперь работает через оператор "//". >>> 3/2 1.5 >>> 3//2 1 То есть теперь деление int на int даёт float если результат не целое число. В классах теперь доступны методы __floordiv__() и __truediv__() для определения поведения с этими операторами. Данный переход описан в PEP238. #pep#2to3#basic

Вторая по частоте future-функция, которую я использовал, это абсолютный импорт from __future__ import absolute_import Что она делает? Изменения, которые вносит эта инъекция описаны в PEP328 Покажу простой пример. Допустим, есть такой пакет: /my_package /__init__.py /main.py /string.py Смотрим код в my_package/main.py # main.py import string Простой пример готов) Вопрос в том, какой модуль импортируется в данном случае? Есть два варианта: 1. модуль в моём пакете my_package.string 2. стандартный модуль string И вот тут вступает в дело приоритет импортов. В Python2 порядок следующий: помимо иных источников, раньше ищется модуль внутри текущего пакета, а потом в стандартных библиотеках. Таким образом мы импортнём my_package.string. Но в Python3 это поведение изменилось. Если мы указываем просто имя пакета, то ищется именно такой модуль, игнорируя имена в текущем пакете. Если мы хотим импортнуть именно подмодуль из нашего пакета то, мы должны теперь явно это указывать. from my_package import string или относительный импорт, но с указанием пути относительно текущего модуля main from . import string Еще одной неоднозначностью меньше 😎 Подробней про импорты здесь: https://docs.python.org/3/tutorial/modules.html #2to3#pep#basic

Что именно мы можем импортнуть из будущих версий? Явно не всё, иначе это была бы, собственно, новая версия. В ˍˍfutureˍˍ выносятся только ключевой функционал, от которого серьезно зависит синтаксис или использование возможностей языка. Самое очевидное это директива print, которая в Python3 стала функцией print(). from __future__ import print_function Что стало удобней с этой функцией? 🔸 Теперь это функция а не ключевое слово, её можно передать как аргумент или вернуть как результат def get_logger(): if condition: return some_handler.write else: return print 🔸 С помощью аргументов sep и end можем настроить минимальное форматирование вывода. sep: разделитель для нескольких объектов end: последний символ вместо перехода на новую строку >>> items1 = [1, 2, 3] >>> items2 = [4, 5, 6] >>> print(*items1, sep='-', end='-') >>> print(*items2, sep='-') 1-2-3-4-5-6 🔸 Аргумент flush форсированно пробрасывает буфер аутпута в файл. Полезно для вывода из блокирующих операций. Например, когда вам нужно в stdout выводить прогресс операции, запущенной в subprocess. Если не сделать flush то весь аутпут прилетит только по завершению процесса. for i in range(100): print(f'Progress: {i}%', flush=True) time.sleep(1) Этот прогресс мы можем отслеживать в реальном времени. А вот так приходилось делать раньше: import sys sys.stdout.write(text + '\n') sys.stdout.flush() 🔸 Аргумент file позволяет перенаправить вывод в другой поток. Например в файл, сеть или что угодно, что имеет метод write. print(text, file=open('filename.txt', 'w')) ___________ Ну да, теперь приходится писать лишние скобочки и сложно переучиться на новый лад. Но плюсов, я думаю, больше. #2to3#tricks

Что за магический модуль ˍˍfutureˍˍ? Это имплементация поведения интерпретатора из будущих версий Python. Разные версии в Python развиваются параллельно. Разработчики ядра Python внедрили модуль ˍˍfutureˍˍ чтобы помочь писать код на старых версиях, но совместимый с новыми версиями интерпретатора. Это помогает более мягко обновить Python, не переписывая всю кодовую базу. Можно сказать что это бекпорт фичей. Модуль ˍˍfutureˍˍ позволяет "импортировать" функционал Python3 работая с Python2, или использовать фишки из Python3.9 имея в распоряжении только 3.6. Но что именно делает этот модуль? Если вы откроете исходник, то ничего магического вы там не найдете. Простой класс, несколько флагов и набор инстансов этого класса. По идее, если его импортнуть, ничего поменяться не может, так как там нет никакого исполняемого кода! Только объявления объектов. А ответ кроется в необходимости делать импорты из ˍˍfutureˍˍ самой первой строкой. Дело в том, что парсер специально заточен на поиск импорта этого модуля в первой строке. Он смотрит что вы там импортнули и специальным образом изменяет поведение интерпретатора, которое в него вшито с помощью бекпортов. Весь дальнейший синтаксический разбор будет с учётом изменений. Именно поэтому импорт ˍˍfutureˍˍ обязательно должен быть первым! Не можем же мы половину модуля исполнять по-старым правилам а вторую половину по-новым))) #2to3

Почему форматов для хранения простых конфигов так много? Всё как обычно. В какой-то момент возникает ситуация: АДМИН: Этот конфиг просто не поддерживает то что я от него хочу! ПРОГЕР: Подержите моё пиво... И рождается новый формат))) А если серьёзно, разные форматы поддерживают разный функционал. Например, поддержка группировки, вложенности данных, глубина вложенности, поддержка разных структур данных, поддержка экспрешенов и наследования, удобство расширения и тд. Возможно самое главное, это человекочитаемость! Так как очень часто конфиги пишут и читают люди. Если бы это было не так, то все писали бы в binary и не выдумывали всякое хитрое форматирование. На мой взгляд самый удобный в коде это JSON, а самый читаемый и удобный в ручном редактировании это YAML. Никто не мешает вам создать собственный формат, если не достаточно того что имеется или если слишком много свободного времени) PS. 4 формата рядом для сравнения синтаксиса 🌎 #libs

В стандартной библиотеке Python есть поддержка нескольких текстовых форматов файлов. Я имею в виду общепринятые форматы хранения текстовых данных. Чаще всего это конфигурационные файлы. И вот что может читать Python из коробки: 🔸JSON (JavaScript Object Notation) Модуль json Один из лидеров по популярности. Используется во многих сферах, от простых конфигов до протоколов передачи данных. Формат простой и понятный. Очень похож на простой Python-код. https://ru.wikipedia.org/wiki/JSON https://www.json.org/ 🔸CSV (Comma-Separated Values) Модуль csv Формат описания табличных данных. Его используют аналитики, датасаентисты и Exel-мастера. Что-то вроде текстовой базы данных. https://ru.wikipedia.org/wiki/CSV https://www.w3.org/TR/tabular-data-primer/ 🔸XML (eXtensible Markup Language) Модуль xml Самый популярный формат в WEB, так как любая HTML страница (то есть все страницы в сети) это XML. Многие программы используют эту разметку для сохранения данных. Удобный формат многоуровневой вложенности объектов с атрибутами. https://www.xml.com/ https://ru.wikipedia.org/wiki/XML 🔸INI (Initialization file) Модуль configparser Очень простой формат конфига для Windows с возможностью группировать параметры. Мало популярен, но в простых случаях вполне подходит. https://ru.wikipedia.org/wiki/.ini Есть еще один популярный формат для конфигов, но к сожалению не в стандартной поставке. Я решил его тоже упомянуть. 🔹YAML (Yet Another Markup Language) В основном используется для конфигов. https://ru.wikipedia.org/wiki/YAML https://yaml.org/ Установка: pip install pyyaml ___________ Конечно же существуют и другие форматы. CFG или CONF (парсер для него был в стандартной библиотеки Python2 в модуле ConfigParser), TOML и другие. Но в большинстве случаев стандартно поддерживаемых форматов хватает чтобы закрыть все потребности. #libs

Как проверяется текущая версия Python? Допустим, вам нужно выбрать конкретное действие в зависимости от версии используемого интерпретатора. В моём примере мне нужна версия Python больше чем 3.5. Самый очевидный способ проверки мажорной версии такой: >>> import sys >>> print sys.version_info.major > 3 True С минорной версией будет чуть длинней >>> print sys.version_info.major == 3 and sys.version_info.minor > 5 Можно ли сократить эту запись? Конечно! Иначе поста бы не было 😊 Вспоминаем как работает сравнение итерируемых объектов в Python. Элементы сравниваются попарно. Если первая пара совпала, проверяется следующая пара, и так пока не найдутся разные элементы или закончится один из итераторов. Например, сравним кортежи. >>> (1, 2) > (1, 3) False >>> (1, 4, 5) > (1, 4, 3) True Теперь преобразуем version_info в кортеж (или список) >>> tuple(sys.version_info) (3, 7, 3, 'final', 0) И можем использовать его для сравнения кортежей >>> tuple(sys.version_info) > (3, 5) True На самом деле можно и не преобразовывать явно, главное запомнить что сравнивать нужно с кортежем. >>> sys.version_info > (3, 5) True Можно еще как-то иначе? Можно! Строки тоже итерируемый объект. Они сравниваются не по длине или кодам символов, а так же попарно, и по порядку символа в таблице (или в алфавите). >>> 'a' > 'b' False >>> 'e' > 'c' True >>> '5' < '4' False А что у нас есть еще в sys? Правильно, переменная version. >>> print (sys.version) '3.7.3 (default, Dec 20 2019, 18:57:59) \n[GCC 8.3.0]' Сравниваем эту переменную с другой строкой: >>> sys.version > '3.5' True ⚠️Этот метод со строкой перестанет работать когда версия Python станет 3.10+. Не используйте его! # tricks

Небольшой экспрешн, с помощью которого можно выяснить, находимся ли мы в интерактивном режиме интерпретатора или нет. Например, в обычном (не интерактивном) режиме команда input() приведет к ошибке (ожидание ввода с клавиатуры). А в интерактивном режиме не всегда получится открыть какой-то диалог. Этот экспрешн поможет выбрать способ ввода данных, например авторизация пользователя. is_interactive = bool(getattr(sys, 'ps1', sys.flags.interactive)) Возможно, кто-то скажет: "зачем такие сложности??? Просто проверяем наличие переменной ˍˍfileˍˍ, в интерактивном режиме она не создаётся!" Всё верно, так оно и работает, но только до того момента, пока вы не импортируете какой-либо модуль. Внутри неймспейса этого модуля переменная ˍˍfileˍˍ определённо существует, даже если вы импортнули его в интерактиве. То есть внутри модуля способ не работает. А с помощью нашего выражения проверка правильно сработает в любом случае. PS. Не работает с некоторыми режимами эмуляции интерпретатора. #tricks

Знаете ли вы про "магические" методы классов ˍˍgetattributeˍˍ() и ˍˍgetattrˍˍ()? ˍˍgetattributeˍˍ вызывается всякий раз когда идёт обращение к атрибуту объекта. Например метод или какая-то переменная. ˍˍgetattrˍˍ вызывается когда атрибут не найден. И вот тут-то начинается самое интересное. Вы можете написать алгоритм определения динамического атрибута. Вы получаете его имя и можете решить, что вернуть учитывая запрошенное имя. Например, можете сделать запрос в базу данных или просто вернуть значение по умолчанию. Но пост на самом деле не об этом. Дело в том, что в Python 3.7 добавили возможность определять функцию ˍˍgetattrˍˍ() в модуле с аналогичной функциональностью! (PEP562) То есть, создав внутри модуля функцию ˍˍgetattrˍˍ() мы определяем действие в случае запроса несуществующего атрибута модуля. Ровно так же как это делаем в классах. Тем самым можно динамически определять состав модуля. А еще можно создать функцию ˍˍdirˍˍ(), определяющую поведение для стандартной функции dir(). Пример модуля: # example.py my_variables = {'var1': 1, "var2": 2} def __getattr__(name): try: return my_variables[name] except KeyError: raise AttributeError def __dir__(): return list(my_variables.keys()) Как использовать модуль >>> import example >>> print(example.var1) 1 >>> print(example.var3) AttributeError >>> print(dir(example))) ['var1', 'var2'] #tricks#pep

В посте про правильное использование аргумента shell упоминалось что в некоторых случаях атрибуты следует отправлять списком а не строкой. Что делать, если команда приходит именно строкой? Как её преобразовать в список? Ответ очевиден >>> cmd_str = 'ls -sl' >>> cmd_lst = cmd_str.split(' ') >>> print(cmd_lst) ['ls', '-sl'] Но что, если команда имеет более сложный вид в плане пробелов? >>> cmd_str = 'mkdir "My Folder Name"' >>> print(cmd_str.split(' ')) ['mkdir', '"My', 'Folder', 'Name"'] Определённо что-то пошло не так! Имя директории содержит пробелы, поэтому весь путь взят в кавычки. Нам определённо не надо её разделять на аргументы. Чтобы сделать всё правильно нам потребуется распарсить строку чтобы обнаружить, что там в кавычках а что нет. Но в стандартной поставке Python давно уже есть готовое решение, моудль shlex (shell lexical analyzers) который всё это умеет. >>> import shlex >>> shlex.split('mkdir "My Folder Name"') ['mkdir', 'My Folder Name'] Теперь команда сработает верно. И не переживайте что кавычки пропали, subprocess сам всё разрулит с пробелами 😎. На Windows всё аналогично. #libs