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

Ранее я уже упоминал о другой фишке из ˍˍ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

Знаете ли вы про "магические" методы классов ˍˍ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