Zen of Python

24 August 2026 17:05

Правила типизации Python рассыпаны по десяткам PEP и страницам документации, а два разных проверяющих на одном коде дают разные ответы. Андрей Наку и Дорел Лукану попробовали собрать это в одну модель.

Отправная точка: каждый тип в Python представлен классом, класс задаёт абстрактный тип данных, а такой тип описывается в терминах экзистенциальных типов. Дальше авторы разводят три отношения, которые в разговорах обычно смешивают: быть подклассом, быть экземпляром объекта и быть экземпляром типа.

По дороге разбираются вещи, полезные и без формализма:

🔘 почему объединение типов и классов в Python 2.2 и переход к порядку разрешения методов C3 в 2.3 определили нынешнее поведение множественного наследования;
🔘 чем Protocol отличается от абстрактного базового класса и где проходит граница между проверкой во время выполнения и статической;
🔘 как устроен слой метаклассов, где класс одновременно и шаблон для экземпляров, и обычное значение;
🔘 чем расходятся mypy и Pyright: первый сильнее опирается на аннотации и знание стандартной библиотеки, второй заточен под быстрый статический анализ.

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

@zen_of_python

Zen of Python

23 August 2026 17:05

Ромен Моротти разобрал профилировщиком, куда уходит время pip install, и довёл установку до двукратного ускорения, а скачивание — до семикратного. На картинке тот самый профиль в SnakeViz.

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

Поучительна и судьба правок: исправление двойного сброса на диск, а это 7 процентов, не приняли из-за разного поведения файловых систем.

@zen_of_python

Zen of Python

22 August 2026 17:05

Дескрипторы — та часть объектной модели Python, которую большинство использует каждый день, не зная названия. Официальное руководство Раймонда Хеттингера объясняет её по шагам и остаётся живой документацией, а не архивом.

Протокол состоит из трёх методов: __get__, __set__ и __delete__. Класс, реализующий их, перехватывает доступ к атрибуту. Из этого собрано больше, чем кажется:

🔘 property, staticmethod, classmethod и super() — всё это дескрипторы, и в руководстве показаны их упрощённые реализации на Python;
🔘 обычная функция становится связанным методом ровно потому, что функция — тоже дескриптор;
🔘 __set_name__ позволяет дескриптору узнать имя атрибута, под которым его объявили;
🔘 разница между дескрипторами с записью и без определяет, кто победит: дескриптор или словарь экземпляра;
🔘 на этом же построены __slots__ и модели в ORM.

Практическая часть — готовый класс Validator и валидаторы OneOf, Number и String: проверка типов и диапазонов при присваивании, без единой строчки проверок в коде, который этими полями пользуется.

@zen_of_python

Zen of Python

22 August 2026 08:05

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

Zen of Python

21 August 2026 14:28

Создаём программу, которая сама умеет выбирать модели в зависимости от задачи

Чем дольше работаешь с ИИ, тем больше убеждаешься, что под разные задачи нужны разные модели. Дя простых задач не нужна дорогая модель, а со сложной дешевая может не справиться. А ещё, используя только одну модель, вы рискуете получить кирпич, если эта модель вдруг станет недоступна.

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

#python

Zen of Python

21 August 2026 08:05

PyPI перестал принимать новые файлы в релизы старше четырнадцати дней

Сет Ларсон описал это изменение 22 июля. Правило простое: если версия пакета опубликована больше двух недель назад, добавить в неё новый файл больше нельзя. Цель — закрыть сценарий, при котором давно стабильную версию тихо дополняют после угона токена или доступа к сборочному процессу. Подтверждённых злоупотреблений на момент публикации не было.

🔘 обсуждение началось ещё вокруг PEP 740 в январе 2024 года и вернулось в марте 2026-го после компрометации двух проектов;
🔘 исправление влили 8 июля 2026 года;
🔘 главное возражение бытовое: проекты иногда докладывают колёса для новой версии Python в уже выпущенный релиз;
🔘 масштаб возражения измерили: среди 15 тысяч самых популярных пакетов так поступили только 56 проектов, добавив совместимое с CPython 3.14 колесо позже чем через две недели;
🔘 на профильной встрече в рамках PyCon US 2026 сочли приемлемым требование выпускать под новый Python новую версию пакета;
🔘 автор просит пока не закладываться на это правило как на гарантию: семантика закрытого релиза и соответствующий интерфейс ещё не определены.

Окончательная модель должна приехать вместе с новым протоколом загрузки и предварительными релизами, после стандартизации PEP 694. Так что практический вывод для авторов пакетов такой: план поддержки нового CPython теперь придётся строить через выпуск новой версии, а не через дозагрузку колеса в старую.

@zen_of_python

Zen of Python

20 August 2026 17:05

Двадцать пять минут, которые снимают половину вопросов новичка: доклад Неда Бэтчелдера «Facts and Myths about Python names and values» с PyCon US 2015.

Весь доклад отвечает на один вопрос: что происходит, когда вы пишете x = 23. Ответ — не «в переменную кладётся значение», а «имя привязывается к объекту». Из этого простого сдвига вырастает объяснение почти всех классических непоняток:

🔘 почему Python нельзя описать ни как передачу по значению, ни как передачу по ссылке;
🔘 почему два имени могут указывать на один объект и менять его вместе;
🔘 почему присваивание никогда не копирует объект;
🔘 почему += для списка и для числа ведут себя по-разному;
🔘 почему изменяемый аргумент по умолчанию живёт между вызовами;
🔘 почему аргументы функции, атрибуты объекта и переменная цикла — это всё одна и та же операция связывания имени.

Бэтчелдер разбирает это на диаграммах с коробочками и стрелками, без единой строчки про внутренности интерпретатора. Именно поэтому доклад одиннадцатилетней давности не устарел ни на строчку: семантика имён и объектов с тех пор не менялась.

@zen_of_python

Zen of Python

20 August 2026 08:05

Cython научился подсказывать компилятору C, какая ветка вероятнее

14 августа вышла бета 3.3.0b1. Релиз для тех, кто собирает расширения: в нём несколько вещей, которые раньше приходилось обходить руками.

🔘 появились cython.likely() и cython.unlikely() — подсказки оптимизатору компилятора C о том, какая ветка условия ожидается чаще;
🔘 реализована конструкция except * для групп исключений по PEP 654 на Python 3.11 и новее;
🔘 аннотации типов у глобальных переменных теперь участвуют в выводе типов, а не игнорируются;
🔘 у сеттеров свойств, объявленных на C, появилась возможность явно пробрасывать исключение вместо безусловной проверки PyErr_Occurred() после каждого вызова;
🔘 поддержан синтаксис однородных кортежей вида tuple[atype, ...];
🔘 набор возможностей общего модуля теперь настраивается при сборке: команда cython generate-shared принимает --only и --exclude, так что в модуль попадает только нужное.

Последний пункт стоит читать вместе с предупреждением авторов: возможность экспериментальная, и если при сборке выключить то, что реально используется, импорт упадёт уже во время работы. Отдельно поменялась схема имён при экспорте и импорте слитых функций на C, но старые имена оставлены для совместимости.

Есть и просто ускорения: форматирование чисел в f-строках, extend у bytearray байтами, проверки одиночного символа, размер асинхронных генераторов и перевод модулей с большим числом строк. Численных замеров в списке изменений нет, только слова «быстрее» и «меньше», так что судить о выигрыше на своём проекте придётся самому.

@zen_of_python

Zen of Python

19 August 2026 14:07

Почему str.lower() иногда ломает проверку имён доменов

Регистр символа в Python зависит от версии Unicode интерпретатора. Сейчас unicodedata.unidata_version — 17.0.0, а протокол подготовки строк stringprep, который лежит в основе международных доменных имён, зафиксирован на Unicode 3.2.

Поэтому str.lower() и str.encode('idna') в разных версиях Python могут считать разные строки одинаковыми. В обычном коде это проходит незамеченным, а в проверке доменов или авторизации получается обход валидации.

В контексте безопасности не зовите str.lower() напрямую. Берите пакет idna: он реализует стандарт IDNA 2008 и не использует встроенные таблицы Unicode.

Seth Larson разбирает уязвимость и показывает, как это выглядит на практике.

Zen of Python

19 August 2026 08:05

У Uvicorn появился разбор HTTP на Zig

Версия 0.52.0 вышла 29 июля и принесла экспериментальную реализацию HTTP/1.1. Работает она на библиотеке zttp: разбор там устроен без собственного ввода-вывода, ядро написано на Zig, а к Python приделаны привязки. Включается новый разборщик параметром --http zttp, схема запуска при этом не меняется.

🔘 сам разборщик перед публикацией несколько недель гоняли под фаззингом и провели несколько раундов проверки безопасности;
🔘 авторы прямо называют его экспериментальным и не советуют пускать через него боевой трафик;
🔘 сравнительных замеров задержки и пропускной способности в заметках нет вообще, так что выигрыш придётся мерить самому;
🔘 отдельно починена обработка заголовков WebSocket с символами вне ASCII в связке с библиотекой websockets версии 17.0;
🔘 в той же версии websockets кодирование таких заголовков переведено на ISO-8859-1, и это как раз причина расхождения;
🔘 обратную связь авторы просят присылать в трекер, то есть релиз рассчитан на тех, кто готов проверять на своей нагрузке.

Замеров ускорения авторы не приводят. Сам приём такой: разбор протокола вынесен в отдельную библиотеку без ввода-вывода, написанную на другом языке, а Python остаётся клеем и сокетным слоем. Проверить новый путь можно на тестовом стенде, ничего не меняя в боевом запуске: старая реализация остаётся на месте и остаётся выбором по умолчанию.

@zen_of_python

Zen of Python

18 August 2026 11:05

Пять игр на Python, которые интересно почитать: они лежат в репозитории с настройками рабочего окружения Arch, и четыре из пяти обходятся стандартной библиотекой, а две самые большие рисуют интерфейс на curses.

🔘 tetris.py, 766 строк: все повороты фигур считаются заранее в build_rotations, при повороте у стены пробуются сдвиги, есть удержание фигуры и превью следующих, а когда разом уходят четыре линии, по экрану летят частицы;
🔘 snake.py, 423 строки: поле подгоняется под размер терминала, интервал тика уменьшается с каждым уровнем, голова заворачивается через край;
🔘 обе игры печатают через safe_addstr: он глотает curses.error, а в змейке ещё и обрезает строку по краю окна — иначе запись в последнюю ячейку роняет игру;
🔘 рекорды пишутся в общий game_high_scores.json так, чтобы не затирать записи соседних игр;
🔘 tetris_pygame.py — та же игра на pygame и dataclass, удобно сравнить два подхода к одной механике.

@zen_of_python

Zen of Python

17 August 2026 17:05

@zen_of_python

Zen of Python

16 August 2026 08:05

Django научился превращать классический N+1 в два запроса без единой правки в коде цикла

Django 6.1 вышел 5 августа. Главное изменение в релизе — режимы дозагрузки полей, то есть настройка того, что происходит в момент обращения к полю, которое из базы не приехало.

Раньше поведение было одно: подтягиваем недостающее поле для этого объекта. Теперь оно называется FETCH_ONE и остаётся по умолчанию, а рядом появились ещё два. FETCH_PEERS подтягивает поле сразу для всех объектов, приехавших из того же запроса, то есть работает как prefetch_related по требованию. FETCH_RAISE запрещает неявные обращения к базе вовсе.

🔘 режим ставится методом QuerySet.fetch_mode(), и цикл, который в каждой итерации трогает внешний ключ, начинает укладываться в два запроса вместо N+1;
🔘 FETCH_RAISE полезен в критичных по скорости участках: любой незамеченный поход в базу превращается в ошибку, а не в тихий лишний запрос;
🔘 у ForeignKey.on_delete появились варианты на стороне базы: DB_CASCADE, DB_SET_NULL и DB_SET_DEFAULT работают через SQL ON DELETE, и объекты для удаления загружать не нужно;
🔘 плата за это честно описана: DB_CASCADE не вызывает сигналы pre_delete и post_delete, потому что Python в удалении не участвует;
🔘 настройка MAILERS позволяет описать несколько почтовых движков с разными параметрами, как это давно сделано для кэшей и баз; в Django 7.0 она заменит EMAIL_BACKEND, пока старая настройка работает с предупреждением;
🔘 число итераций в хешировании паролей PBKDF2 поднято с 1 200 000 до 1 500 000.

По мелочи: добавлены функции UUID4 и UUID7, вычисляемые поля получили виртуальные колонки на PostgreSQL 18 и выше, RedirectView с сохранением метода запроса теперь отвечает кодами 307 и 308 вместо 302 и 301, а OpenLayers в админке обновлён с 7.2.2 до 10.9.0.

Поддерживаются Python 3.12, 3.13 и 3.14. Обычная поддержка релиза продлится примерно до апреля 2027 года, расширенная до декабря. В заметках отдельно перечислены несовместимости, так что перед обновлением их стоит прочитать: смена семантики сигналов при каскадном удалении на стороне базы как раз тот случай, когда код продолжает работать, а побочные действия молча исчезают.

@zen_of_python

Zen of Python

13 August 2026 19:46

Новые модели выходят быстрее, чем все успевают их внедрять, а прогнозы про ИИ устаревают ещё быстрее, поэтому на кафедре техпреда МФТИ запустили «Точку сборки».

Это серия открытых вебинаров, на которых спикеры делятся опытом внедрения агентов, быстрой сборки MVP и конкретными кейсами своих команд.

Больше о «Точке сборки», о первом вебинаре и о том, как попасть на следующие читайте в новом материале на Tproger: https://tproger.ru/articles/pochemu-opyt-razrabotchikov-luchwe-prognozov-pro-ii

Zen of Python

12 August 2026 08:05

Проверка одной группы объектов стоит времени, пропорционального размеру группы, а полный проход сборщика — всему содержимому процесса

28 июля на discuss.python.org появилось предложение научить сборщик мусора принимать подсказки: разработчик или анализатор кода говорит, что вот эта группа объектов, скорее всего, больше никому не нужна, а сборщик проверяет и освобождает её, не запуская полный обход поколения.

Смысл в том, как в CPython устроено освобождение памяти. Основную работу делает подсчёт ссылок, он мгновенный и точный. Но объекты, ссылающиеся друг на друга по кругу, счётчиками не убираются: у запроса лежит ссылка на его статус, у статуса обратная ссылка на запрос, оба недостижимы снаружи, а счётчики у обоих равны единице. За такие случаи отвечает отдельный сборщик циклов, и он останавливает все потоки, чтобы обойти память.

🔘 предлагаемая проверка простая: просуммировать счётчики ссылок объектов группы и посчитать, сколько ссылок на них идёт изнутри самой группы. Совпало — снаружи на группу никто не смотрит, можно освобождать;
🔘 в примере с запросом и статусом обе суммы равны двум, поэтому пара удаляется без обхода кучи;
🔘 подсказка ничего не гарантирует и всегда проверяется, а если из какой-то категории приходит слишком много ложных подсказок, её можно перестать слушать;
🔘 автор ссылается на известный случай Instagram, где сборщик отключали и просто перезапускали машины по мере роста памяти, и на статистику, по которой сборка мусора съедает от 5 до 30 процентов процессорного времени;
🔘 в обсуждении сразу возразили: Терри Ридди спрашивает, насколько часто цикл нельзя просто разорвать руками, а Грег Юинг — есть ли алгоритм, который окажется дешевле честной сборки;
🔘 ещё одно возражение практическое: подсказки придётся обновлять при каждой правке структур данных и как-то проверять тестами, а если уж писать такой тест, проще искать сами циклы и разрывать их.

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

Обсуждение: https://discuss.python.org/t/improving-python-garbage-collection-performance-by-providing-unreachable-cycles-hints/108307

@zen_of_python

Zen of Python

24 August 2026 08:05

Тесты бэкенда 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

Zen of Python

23 August 2026 08:05

Почему 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

Zen of Python

22 August 2026 12:05

Марк Шеннон и Даниэле Пармеджани опубликовали 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

Zen of Python

21 August 2026 17:05

Дэвид Бизли пишет с нуля живьём на сцене, за 46 минут проходя весь путь от простого сокета до собственного цикла событий. Слайдов почти нет, только редактор и терминал.

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

Самая ценная часть в конце. Бизли показывает, что генератор с yield — это способ задачи добровольно приостановиться, и из этого прямо на глазах собирает планировщик с очередью задач, а потом цикл событий с select, ожиданием и пробуждением через пару сокетов.

После этого asyncio перестаёт быть магией: видно, из каких частей он состоит и почему устроен именно так.

@zen_of_python

Zen of Python

21 August 2026 12:05

uv 0.12.5 поменял правило выбора интерпретатора: при одинаковом приоритете теперь предпочитается более новая версия и стандартный вариант Python. Если в конфигурации несколько интерпретаторов с равным приоритетом, окружение может собраться уже не тем Python, что вчера.

🔘 подтянуты CPython 3.10.21, 3.11.16 и 3.12.14;
🔘 в preview у --index и --default-index появился выбор настроенного индекса по имени;
🔘 экспорт SBOM в CycloneDX по умолчанию содержит URL и хеши артефактов;
🔘 cache-physical-space откатывается к логическому размеру файла там, где физический размер файловая система не отдаёт;
🔘 в скриптах по PEP 723 относительные пути к индексам разрешаются относительно каталога скрипта, а не текущего каталога.

Выбор индекса по имени авторы помечают как preview. Численных бенчмарков в заметках к релизу нет.

@zen_of_python

Zen of Python

20 August 2026 19:05

Numba 0.67.0 научилась работать с NumPy 2.5 и собирает пакеты для Python 3.14 и Windows ARM64.

🔘 у np.sum и np.cumsum появился динамический axis, ось теперь можно вычислять во время выполнения;
🔘 добавлена JIT-поддержка np.insert, пока без аргумента axis;
🔘 np.random.binomial в RandomState переключается с BINV на BTPE, когда n * min(p, 1 - p) > 30, поток случайных чисел при этом сохраняется;
🔘 анализ живости переменных перевели на топологический порядок, а проверка принадлежности стеку в _find_back_edges стала за O(1);
🔘 сборки через pycc теперь могут быть побайтно воспроизводимыми на Linux и macOS.

Из ломающего: np.row_stack и двумерное векторное произведение убраны вслед за NumPy 2.5, cross2d остаётся только для старых версий. Пакеты под Windows ARM64 на старте ограничены Python 3.14, часть тестов там пропущена из-за проблемы в LLVM 22.

Отдельно починили тихую ошибку компиляции при повторном присваивании нелокальной переменной во вложенной функции: раньше генерировался неверный код, теперь вылетает UnsupportedError. Численного бенчмарка ускорения BTPE авторы не приводят.

@zen_of_python

Zen of Python

20 August 2026 13:01

⚡️ О!Хакатон возвращается — на кону миллион

Приглашаем Go- и Python-разработчиков, аналитиков и продакт-менеджеров на тревел-тех хакатон от Островка.

Вам предстоит решить одну из двух AI-задач в сфере тревел-теха и побороться за главный приз — 1 000 000 ₽.
Присоединиться к хакатону можно из любой точки мира. Участвуйте командой до пяти человек и выбирайте один из двух треков:

✔️ «О!дин запрос». Цель для junior-специалистов — создать AI-агента для путешествий и отелей.
✔️ «О!дин шаг до идеального отеля». Задача для специалистов уровней middle и senior — «переизобрести» опыт бронирования пользователя с помощью AI и новых интерфейсных механик.

📎 Регистрация открыта до 16 октября 2026 года. Стартуем 23 октября.

Скорее присоединяйтесь по ссылке!

Zen of Python

19 August 2026 17:05

Django переходит на один релиз в год. Steering Council принял DEP 20: с января 2028-го выходит один feature-релиз в год, версии называются по году — Django 2028, Django 2029.

🔘 каждый релиз получает три года поддержки: год обычных исправлений и два года security и data-loss fixes; отдельная метка LTS уходит, потому что каждая версия теперь LTS;
🔘 версия поддерживает три последних Python на момент выхода и подхватывает новый Python в первый год; поддержка Django заканчивается вместе с самым старым из них;
🔘 в любой момент поддерживаются три версии, и обновляться можно по одной в год без прыжка через два года изменений;
🔘 политика депрекаций не меняется, в календарных днях сроки только удлиняются.

Переход: Django 6.1 вышел в августе, 6.2 LTS выйдет в апреле 2027-го, Django 2028 — в январе 2028-го. Обязательства по 5.2 LTS и 6.2 LTS остаются как объявлены.

@zen_of_python

Zen of Python

19 August 2026 12:05

Разрешение зависимостей предложили считать задачей для решателя, а не перебором. SMTpip переводит ограничения пакетов и Requires-Python в формулу и отдаёт её weighted Max-SMT, который за один заход выбирает и версии библиотек, и версию интерпретатора. pip вместо этого перебирает кандидатов с откатами.

Что получилось на замерах авторов:

🔘 в среднем по всем наборам ускорение в 6,9 раза против pip, в 9,6 против классического решателя Conda, в 3,2 против smartPip и в 4 против PyEGo;
🔘 на наборе HG2.9K те же 1668 случаев: 433,68 секунды против 2165,20 у pip, ускорение в 4,9 раза;
🔘 доля проектов, которые после установки реально запустились: 87,1% против 75,4% у pip, а на 3081 ноутбуке 39,92% против 20%.

Оговорки авторы приводят сами. Это препринт первой версии; время меряли только для разрешения зависимостей, без скачивания и установки пакетов; из конкурентов брали классический solver Conda, libmamba оставили за рамками. Успешный запуск здесь означает, что программа стартовала, а не что она работает правильно.

@zen_of_python

Zen of Python

18 August 2026 17:05

12 августа вышли security-релизы Python 3.12.14, 3.11.16 и 3.10.21. Список исправлений длинный, и почти всё в нём про стандартную библиотеку:

🔘 tarfile: несколько обходов фильтра data_filter(), через которые архив мог положить symlink за пределы каталога назначения; один из них — обход прошлогоднего CVE-2025-4330;
🔘 webbrowser.open() отклоняет URL с ведущим дефисом, чтобы аргумент не читался браузером как флаг; закрыт и обход этой проверки через префикс %action;
🔘 HTTPConnection.set_tunnel() больше не пропускает CR/LF в заголовках, wsgiref — управляющие символы в статусе, http.cookies — в Morsel (CVE-2026-3644);
🔘 SourcelessFileLoader открывает .pyc через io.open_code() (CVE-2026-2297), в xml.parsers.expat починен крэш от глубокой вложенности (CVE-2026-4224);
🔘 квадратичное и экспоненциальное поведение убрано из unicodedata.normalize(), html.parser, configparser, ElementTree и csv.Sniffer;
🔘 http.client ограничил число trailer-строк и промежуточных ответов 1xx сотней, чтобы сервер не мог держать клиента вечно.

Все три ветки в стадии security-only: релизы только исходниками, без установщиков. 3.10 получает исправления до октября этого года, 3.12 — до октября 2028-го.

@zen_of_python

Zen of Python

18 August 2026 08:05

Ruff включил по умолчанию 413 правил вместо 59

Версия 0.16.0 вышла 23 июля. Заодно 18 самых спорных правил групп pycodestyle и pyflakes из набора по умолчанию убрали.

🔘 форматирование блоков Python внутри Markdown включено по умолчанию — документация в репозитории теперь тоже под форматтером;
🔘 подавляющий комментарий ruff: ignore можно ставить в конце строки, как noqa, или на строке перед диагностикой;
🔘 исправления показываются прямо в выводе check и format --check, вместе с кусочком диффа;
🔘 format --check получил форматы вывода линтера, включая github и gitlab для аннотаций в сборке;
🔘 в JSON-выводе поля filename, location и end_location теперь могут быть null — разборщики придётся проверить;
🔘 стабилизированы двенадцать правил.

Обновление стоит планировать отдельной задачей: на первом прогоне вылезет то, что раньше молчало, и часть находок потребует решения — включать правило, исключать или править код.

@zen_of_python

Zen of Python

17 August 2026 08:05

У библиотеки websockets появилась реализация на Trio

Версия 17.0 вышла 29 июля. Раньше выбора не было: под капотом всегда asyncio либо потоки. Теперь третий вариант — Trio, для тех, кто уже строит на нём приложение.

Релиз ломающий, и вот что придётся проверить перед обновлением:

🔘 минимальная версия Python поднята до 3.11, последней с поддержкой 3.10 остаётся ветка 16.1;
🔘 удалены псевдонимы модулей, которые перенесли ещё в девятой версии;
🔘 несколько логических аргументов у send(), ping() и broadcast() стали передаваться только по имени;
🔘 не-ASCII заголовки рукопожатия теперь кодируются в ISO-8859-1; прежнее поведение было недокументированным и не совпадало со спецификацией HTTP;
🔘 в реализации на потоках аргумент socket переименован в sock;
🔘 process_request теперь получает и запросы с методом, отличным от GET, и запросы по HTTP/1.0, вместо того чтобы соединение просто закрывалось.

Из добавленного: broadcast() и Server.connections в реализации на потоках, аккуратное закрытие соединений при остановке, reconnect_delays для настройки пауз между попытками переподключения, а на некорректное рукопожатие сервер теперь отвечает кодами 405 и 505 вместо тишины.

@zen_of_python

Zen of Python

14 August 2026 17:09

Технически всё верно...

Zen of Python

13 August 2026 08:05

Бинарный поиск ускорили в 8 раз, не меняя ни алгоритм, ни язык: 16,6 процента промахов предсказателя ветвлений превратились в ноль

Итамар Тёрнер-Трауринг разобрал шаг из градиентного бустинга в scikit-learn: миллион чисел с плавающей точкой нужно разложить по 255 корзинам, для чего по массиву границ гоняется бинарный поиск. Код уже скомпилированный и уже параллелится по ядрам, алгоритм оптимальный. Статья опубликована 11 июля и обновлена 18-го, работа сделана в рамках Quansight.

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

🔘 исходная версия: 45 200,4 микросекунды, 16,6 процента неверных предсказаний, 0,7 инструкции за такт, около 27 инструкций ветвления на одно значение;
🔘 первая переделка убирает ветвление, заменяя его условным присваиванием через select_unpredictable: 9 685,2 мкс, промахов ноль, 3,2 инструкции за такт, ветвлений 19 на значение;
🔘 предвычисление половины диапазона и доступ без проверки границ дают 7 280,4 мкс и обрушивают число инструкций ветвления до 6 020 571 на весь прогон;
🔘 финальная версия обрабатывает значения кусками по 16 штук с внешним циклом по шагам поиска: 5 453,4 мкс и 4,9 инструкции за такт;
🔘 любопытно, что она выполняет больше инструкций, чем предыдущая, но идёт быстрее: независимые куски работы позволяют процессору выполнять их одновременно;
🔘 итог — примерно восьмикратное ускорение на том же алгоритме, том же языке и одном ядре.

Автор оговаривает, что это упрощённый пример, а не полная реализация из scikit-learn, и что статья не заменяет учебник по устройству процессора. В обновлении он честно пишет, что раньше ошибся со сравнением чисел с плавающей точкой, и после исправления SIMD перестал давать выигрыш, хотя код от этого стал только быстрее. Дальнейший запас автор видит в параллелизме по ядрам.

Польза для питониста прямая: когда расчёт уже переписан на расширение и всё равно кажется медленным, следующий уровень — не алгоритм, а поведение процессора на этом коде.

Полная статья: https://pythonspeed.com/articles/branchless-binary-search/

@zen_of_python

Zen of Python

11 August 2026 08:05

Процесс дорос до 57 гигабайт памяти и был убит ядром, потому что к каждой задаче прикреплялся живой стек вызовов

Хорхе Эскобар описал 27 июля в трекере playwright-python редкий вид утечки, где виноваты сразу две стороны. Синхронная обёртка библиотеки на каждый вызов создаёт задачу asyncio и вешает на неё атрибут со значением inspect.stack(0). Это не строки, а объекты FrameInfo, внутри которых лежат живые кадры стека вместе со всеми локальными переменными вызывающего кода.

Сама по себе такая привязка живёт ровно до конца вызова. Но на Python с 3.14.0 по 3.14.6 была регрессия: asyncio.wait с FIRST_COMPLETED навсегда оставлял вызывающую задачу в множестве ожидающих у того будущего, которое так и не завершилось. Playwright задевает это на каждом обращении к браузеру, потому что гонит ответ на команду наперегонки с долгоживущим будущим ошибки транспорта. В итоге каждая завершённая операция утаскивала за собой задачу, кадры и всё их содержимое.

🔘 нагрузка простая: скриншот на каждый кадр, PNG 3840×2160 декодируется через PIL прямо в той функции, которая вызывает page.screenshot();
🔘 на итерацию оставалось около 40 МБ: примерно 33 МБ распакованного изображения и ещё около 8 МБ уменьшенной копии, обе как локальные переменные удержанного кадра;
🔘 после примерно 1900 итераций процесс занял около 57 ГБ и получил SIGKILL;
🔘 gc.collect() не помогает вообще: запись в множестве ожидающих является сильным корнем, а не циклической ссылкой;
🔘 цепочка ссылок читается целиком: изображение, кадр вызывающей функции, FrameInfo, завершённая задача скриншота, множество ожидающих у будущего ошибки транспорта, которое живёт всю сессию браузера;
🔘 перестройка своего кода так, чтобы во время вызова в кадрах не было больших локальных переменных, снизила утечку с 40 МБ до 0,94 МБ на итерацию.

Обе стороны уже починены: регрессию в CPython закрыли 2 июля, а в playwright-python убрали хранение живых кадров, и 30 июля обсуждение закрыли. Автор замерял на конкретной нагрузке и на macOS с Python 3.14.6, но структурно то же поведение видел и на 3.12.

Вывод из этой истории шире одной библиотеки: пока задача жива, живо и всё, на что смотрят её кадры. Прикреплять inspect.stack() к объектам, время жизни которых вы не контролируете, означает подписаться на удержание чужих локальных переменных.

Обсуждение целиком: https://github.com/microsoft/playwright-python/issues/3157

@zen_of_python