Zen of Python - дзен

Правила типизации Python рассыпаны по десяткам PEP и страницам документации, а два разных проверяющих на одном коде дают разные ответы. Андрей Наку и Дорел Лукану попробовали собрать это в одну модель. Отправная точка: каждый тип в Python представлен классом, класс задаёт абстрактный тип данных, а такой тип описывается в терминах экзистенциальных типов. Дальше авторы разводят три отношения, которые в разговорах обычно смешивают: быть подклассом, быть экземпляром объекта и быть экземпляром типа. По дороге разбираются вещи, полезные и без формализма: 🔘 почему объединение типов и классов в Python 2.2 и переход к порядку разрешения методов C3 в 2.3 определили нынешнее поведение множественного наследования; 🔘 чем Protocol отличается от абстрактного базового класса и где проходит граница между проверкой во время выполнения и статической; 🔘 как устроен слой метаклассов, где класс одновременно и шаблон для экземпляров, и обычное значение; 🔘 чем расходятся mypy и Pyright: первый сильнее опирается на аннотации и знание стандартной библиотеки, второй заточен под быстрый статический анализ. Авторы честно ограничивают область: формализм описывает программы, где типы не меняются на ходу, а подтипизация и динамика оставлены на будущее. @zen_of_python

Тесты бэкенда PyPI шли 163 секунды, стали 30 — при том что самих тестов стало больше: было около 3900, стало больше 4700. Алексис Шалланд описал, что именно сделали. Порядок действий подойдёт любому медленному набору на pytest: 🔘 распараллелить через pytest-xdist с --numprocesses=auto; на 32 ядрах замер упал с 191 до 63 секунд; 🔘 чтобы процессы не топтали данные друг друга, фикстура базы берёт идентификатор рабочего процесса: у каждого своя база tests-{worker_id}; 🔘 для покрытия в параллельном режиме добавить sitecustomize.py с coverage.process_startup(); 🔘 переключить измерение покрытия на механизм наблюдения из Python 3.12 через COVERAGE_CORE=sysmon — с 58 до 27 секунд; 🔘 указать testpaths: сбор тестов ускорился с 7,84 до 2,60 секунды; 🔘 прогнать python -X importtime и выкинуть лишний импорт. Логику тестов при этом не меняли и покрытие не снижали. @zen_of_python

Ромен Моротти разобрал профилировщиком, куда уходит время pip install, и довёл установку до двукратного ускорения, а скачивание — до семикратного. На картинке тот самый профиль в SnakeViz. 🔘 создание каталогов при установке одного пакета вызывалось 14 425 раз; осталось 1 538; 🔘 набор поддерживаемых меток колёс, 889 значений, пересчитывался заново для каждого пакета — кэширование дало около 17 процентов; 🔘 функция получения установленного пакета вела себя квадратично: на трёхстах пакетах итоговая сводка занимала треть времени; 🔘 распаковка читала архив мелкими кусками, блок в 1 мебибайт дал ещё около 10 процентов; 🔘 библиотека запросов тянула сеть кусками по 10 килобайт: переход к 256 килобайтам поднял скорость с 60 до 260 мегабайт в секунду; 🔘 отрисовка полосы прогресса съедала до 30 процентов времени загрузки. Поучительна и судьба правок: исправление двойного сброса на диск, а это 7 процентов, не приняли из-за разного поведения файловых систем. @zen_of_python

Почему obj.prop вызывает функцию, а C.prop возвращает объект, и откуда метод знает про self Антонио Куни разобрал по шагам, что происходит при обращении к атрибуту — от байткода до кода CPython. Порядок поиска на картинке. Из него сразу объясняется несколько загадок. Дескриптор данных, то есть объект с __get__ и __set__, проверяется раньше словаря экземпляра — поэтому property не перекрыть, положив одноимённый ключ в obj.__dict__. И property остаётся дескриптором данных, даже когда сеттера нет: он определяет __set__ и сам поднимает AttributeError. Там же видно, откуда берётся связанный метод: обычная функция — это дескриптор без записи, и obj.meth разворачивается в C.meth.__get__(obj, C). У классов поиск устроен иначе: сначала дескрипторы данных метакласса, потом полный проход по порядку разрешения методов. Автор берёт CPython 3.12.11: в 3.13 этот код усложнён оптимизациями. @zen_of_python

Дескрипторы — та часть объектной модели Python, которую большинство использует каждый день, не зная названия. Официальное руководство Раймонда Хеттингера объясняет её по шагам и остаётся живой документацией, а не архивом. Протокол состоит из трёх методов: __get__, __set__ и __delete__. Класс, реализующий их, перехватывает доступ к атрибуту. Из этого собрано больше, чем кажется: 🔘 property, staticmethod, classmethod и super() — всё это дескрипторы, и в руководстве показаны их упрощённые реализации на Python; 🔘 обычная функция становится связанным методом ровно потому, что функция — тоже дескриптор; 🔘 __set_name__ позволяет дескриптору узнать имя атрибута, под которым его объявили; 🔘 разница между дескрипторами с записью и без определяет, кто победит: дескриптор или словарь экземпляра; 🔘 на этом же построены __slots__ и модели в ORM. Практическая часть — готовый класс Validator и валидаторы OneOf, Number и String: проверка типов и диапазонов при присваивании, без единой строчки проверок в коде, который этими полями пользуется. @zen_of_python

Марк Шеннон и Даниэле Пармеджани опубликовали PEP 805 «Safe Parallel Python»: параллелизм в CPython без гонок по умолчанию. Целевая версия 3.16, статус Draft. 🔘 Каждый объект получает атрибут __shareable__ только на чтение, со значением Immutable, Local, Protected или Synchronized. Контролируется доступ к объекту, а не отдельные операции: проверка нужна лишь при создании ссылки потока из ссылки в куче. 🔘 Классы, функции и модули создаются Local. Замыкание, меняющее nonlocal, останется Local, и передача его в чужую группу потоков даст IllegalThreadAccessException. 🔘 Добавляются SynchronizedList, SynchronizedDict и SynchronizedSet; sys.modules станет первым, sys.path — вторым. Авторы предупреждают: эти классы защищают объект от порчи, но потокобезопасности не дают. 🔘 Мотив: PEP 703 даёт параллелизм, но допускает гонки, а PEP 734 безопасен, но объекты между интерпретаторами без копирования не передать. Без чего-то подобного, считают авторы, две сборки CPython останутся навсегда. @zen_of_python

PEP 842 предлагает ключевое слово export и прячет из модуля всё, что им не помечено Питер Бирма опубликовал черновик 25 июля, целевая версия — Python 3.16. Идея в том, чтобы у модуля появился явный публичный интерфейс, а не соглашение об именах с подчёркиванием и переменная __all__, о которой знает только импорт со звёздочкой. 🔘 объявление помечается прямо в определении: export class Public видно снаружи, а обычный class Private из dir(module) исчезает; 🔘 при обращении к скрытому имени поднимается ExportError, наследник AttributeError; 🔘 переменная __export__ со списком строк работает как список экспорта, а имена в ней могут быть ещё не определены, но тогда импорт со звёздочкой упадёт; 🔘 запись from module export NAME равносильна импорту имени с последующим его экспортом; 🔘 export перед def и class разрешён только на уровне модуля, внутри функции это синтаксическая ошибка; 🔘 слово мягкое, то есть существующий код с переменной по имени export продолжит работать, а модули без __export__ ведут себя как раньше. Автор сам подчёркивает, что это не модификатор доступа: ограничение обходится удалением __export__, правкой списка или обращением к __dict__ модуля. Смысл не в защите, а в том, чтобы автодополнение, документация и статический анализ видели границу библиотеки так же, как её видит автор. В обсуждении сразу поднялся вопрос производительности: эталонная реализация пока не оптимизирована и, вероятно, добавляет накладные расходы на обращение к атрибутам модуля. Открытым остаётся и то, как пакет должен добираться до приватных имён собственных подмодулей. Пока это черновик, и до 3.16 у предложения ещё есть время измениться. Обсуждение предложения @zen_of_python

Дэвид Бизли пишет с нуля живьём на сцене, за 46 минут проходя весь путь от простого сокета до собственного цикла событий. Слайдов почти нет, только редактор и терминал. Последовательность такая. Берётся заведомо тяжёлая функция — рекурсивные числа Фибоначчи — и простой сетевой сервис. Сначала он последовательный, и один клиент блокирует всех остальных. Дальше появляются потоки: они спасают там, где программа ждёт ввод-вывод, но на вычислениях упираются в глобальную блокировку интерпретатора. Затем процессный пул, который блокировку обходит, но платит за это сериализацией и передачей данных. Самая ценная часть в конце. Бизли показывает, что генератор с yield — это способ задачи добровольно приостановиться, и из этого прямо на глазах собирает планировщик с очередью задач, а потом цикл событий с select, ожиданием и пробуждением через пару сокетов. После этого asyncio перестаёт быть магией: видно, из каких частей он состоит и почему устроен именно так. @zen_of_python

Создаём программу, которая сама умеет выбирать модели в зависимости от задачи Чем дольше работаешь с ИИ, тем больше убеждаешься, что под разные задачи нужны разные модели. Дя простых задач не нужна дорогая модель, а со сложной дешевая может не справиться. А ещё, используя только одну модель, вы рискуете получить кирпич, если эта модель вдруг станет недоступна. Выход — разделить запросы по сложности и держать под рукой запасной вариант. Сначала ваш скрипт решает, насколько труден вопрос, потом отправляет простое к дешёвой модели, а сложное — к мощной. При сбое переключается на резервную модель. Туториал разбирает это на Python шаг за шагом. #python