Robot Framework — фреймворк тестовой автоматизации на Python с keyword-driven синтаксисом. Первая бета версии 7.5 вышла 17 июля и открывает новый feature-цикл.

🔘 Libdoc понимает Markdown, а аргументы, возвращаемые значения и исключения можно документировать в Google Style — результат конвертируется в HTML;
🔘 тесты и tasks можно встраивать в Markdown-файлы через fenced-блоки robotframework, файлы .robot.md распознаются автоматически;
🔘 пользовательские console loggers регистрируются через --console и используют API listeners, Rebot поддерживает тот же механизм;
🔘 TimeoutExceeded теперь наследуется от BaseException — случайный except Exception: его больше не проглотит;
🔘 объявлены устаревшими встроенный Testdoc и неоднозначные tag patterns вроде XORY.

Пишете автотесты на Robot Framework или в вашей команде победил чистый pytest?

@zen_of_python

18 июля вышла последняя запланированная бета Python 3.15: около 298 исправлений, сборок и правок документации с прошлой беты. Дальше по плану релиз-кандидат 4 августа.

Что приедет в 3.15:

🔘 PEP 810 — явные ленивые импорты ради быстрого старта;
🔘 PEP 814 добавляет встроенный тип frozendict, а PEP 661 — тип sentinel;
🔘 PEP 799 приносит отдельный пакет для профилирования и Tachyon, семплирующий профилировщик высокой частоты;
🔘 PEP 686 делает UTF-8 кодировкой по умолчанию;
🔘 PEP 831 включает фреймовые указатели по умолчанию, чтобы системные профилировщики видели стек Python;
🔘 JIT заметно подтянули: 8–9% среднего геометрического прироста на x86-64 Linux против обычного интерпретатора и 12–13% на AArch64 macOS против интерпретатора с хвостовыми вызовами;
🔘 официальные 64-битные сборки под Windows перешли на интерпретатор с хвостовыми вызовами, а сборки под macOS теперь ставят поддержку свободной от GIL версии по умолчанию.

Команда просит библиотеки протестироваться на бете и выложить пререлизные колёса, но обычные прод-релизы советует придержать до 3.15.0rc1: ABI после четвёртой беты меняться не должен, гарантий до кандидата всё же нет.

Уже гоняли свои проекты на 3.15 или ждёте финального релиза 1 октября?

@zen_of_python

FastAPI выпустил три релиза за четыре дня, и все про одно: сколько памяти съедает система зависимостей.

Началось с разбора от пользователя, который собрал приложение с цепочкой из ста вложенных Depends и эндпоинтами на десятки параметров. Реальные проекты с большими графами зависимостей выглядят похоже, только менее наглядно.

🔘 в 0.140.0 от 24 июля класс Dependant разгрузили: вспомогательные функции с кешами вынесли наружу, объект теперь просто хранит данные. Бенчмарк памяти на графе зависимостей упал с 17,5 МБ до 1,1 МБ;
🔘 в 0.140.1 от 27 июля предел lru_cache для классификации вызываемых объектов подняли с 1024 до 4096: нашлись приложения, где зависимостей заметно больше тысячи, а на переполненном кеше выигрыш терялся;
🔘 в 0.140.2 в тот же день перестали удерживать плоские деревья зависимостей: бенчмарк графа маршрута ужался с 575 до 110,7 КБ.

Заодно в CI добавили замер памяти, так что рост потребления теперь виден прямо в пул-реквесте, а не в проде через полгода.

Замеряете память своих сервисов в CI или ловите такое уже на боевых машинах?

@zen_of_python

Донхи На и Никита Соболев предложили PEP 841: запись f{1, 2, 3} создаёт frozenset, f{'a': 1} создаёт frozendict, f{} даёт пустой frozendict. Черновик написан 16 июля, обсуждение открыли 20 июля, целятся в Python 3.16.

Сейчас frozenset({1, 2, 3}) сначала собирает обычное множество, потом копирует его в неизменяемое, и на каждом выполнении ищет имя frozenset в области видимости. Соптимизировать это компилятор не может: имя могут переопределить, а у вызова могут быть побочные эффекты. Один частный случай CPython уже спрямляет, но только справа от in. Присвойте тот же литерал переменной, и оптимизация исчезает.

Что предлагает PEP:

🔘 неизменяемость гарантирует сама грамматика, поэтому её не приходится выводить из того, как значение используется дальше;
🔘 константный f{...} сворачивается в один LOAD_CONST и попадает в .pyc, так что на каждом следующем выполнении конструирование бесплатно;
🔘 добавляются токен FLBRACE, четыре узла AST и две инструкции байткода: BUILD_FROZENSET и BUILD_FROZENMAP;
🔘 работают и генераторные выражения: f{x for x in xs}, f{k: v for k, v in items}, а также распаковка f{*xs} и f{**d};
🔘 f{ сегодня синтаксическая ошибка, поэтому старый код ничего не теряет. Запись f {1} с пробелом ошибкой и останется, путаницы с f-строками нет;
🔘 в стандартной библиотеке авторы насчитали около 105 вызовов frozenset и 65 вызовов frozendict, из них 46 и 22 можно переписать новой записью.

Большая цель за синтаксисом — подтолкнуть людей к неизменяемым контейнерам перед эпохой сборок без GIL и субинтерпретаторов: субинтерпретаторы уже делят между собой frozenset, на очереди frozendict. Про JIT авторы намеренно ничего не обещают, потому что руководящий совет в июне запретил новую разработку JIT в main до принятия отдельного PEP.

Читается ли f{1, 2, 3} лучше, чем frozenset({1, 2, 3}), или лишний префикс только запутает?

@zen_of_python