Ruff 0.16.5 отримав category selectors і точніші правила для async-коду

Ruff 0.16.5 розширив спосіб, у який команди керують правилами лінтера: у preview-режимі з’явилися category selectors і правила без традиційних кодів, а кілька перевірок стали точнішими для асинхронного коду, дат і побічних ефектів. Оновлення корисне насамперед великим Python-проєктам, де конфігурація лінтингу вже перетворилася на окрему політику якості. Водночас нові механізми ще експериментальні та можуть змінюватися.

Категорії замість довгих списків кодів

Category selectors дозволяють обирати логічні групи перевірок, не перелічуючи кожний код окремо. Це спрощує стартову конфігурацію й робить намір зрозумілішим: команда описує потрібний клас проблем, а не копіює десятки ідентифікаторів. Разом із цим preview-модель допускає правила без звичних кодів і оновлює категорії та набір правил за замовчуванням.

Зручність має ціну. Категорія може поповнюватися в нових версіях, тому той самий конфіг після upgrade здатний знайти більше порушень. Для CI, де будь-яке попередження блокує merge, варто зафіксувати версію Ruff, переглядати changelog і спершу запускати новий набір правил у режимі звіту. Після стабілізації політики критичні винятки краще документувати поруч із конфігурацією.

Точніша перевірка async-коду

Правило ASYNC210 тепер виявляє блокувальні generic HTTP requests в асинхронному контексті. Такий виклик може зайняти event loop і збільшити затримку для всіх інших корутин, хоча локальний тест часто проходить без видимих проблем. Попередження підштовхує перейти на асинхронний клієнт, винести синхронну операцію в окремий потік або чітко ізолювати її від основного циклу.

Лінтер не знає всіх властивостей мережі та бібліотеки. Автоматична заміна API може змінити таймаути, повтори, пул з’єднань і спосіб обробки винятків. Тому спрацювання ASYNC210 слід трактувати як точку для інженерного аналізу, а не як наказ механічно змінити один рядок.

Менше хибних спрацювань у датах і lambdas

Перевірка DTZ007 тепер дозволяє безпечні ланцюжки після strptime, якщо код явно додає часову зону. Це важливо для застосунків, що приймають текстову дату й одразу нормалізують її до timezone-aware значення. Раніше коректний ланцюжок міг виглядати для статичного аналізатора як робота з «наївним» datetime.

Правило SIM401 почало враховувати побічні ефекти в стандартних значеннях параметрів lambda. Оптимізація синтаксису небезпечна, якщо змінює момент виконання функції або кількість її викликів. Нове поводження зменшує ризик, що автоматичне виправлення зробить код коротшим, але семантично іншим.

Практичний висновок: Ruff цінний не кількістю ввімкнених правил, а прогнозованістю їх застосування. Нову категорію краще додавати окремим pull request, щоб команда бачила всі зміни й могла обговорити винятки.

Безпечний сценарій переходу

• Зафіксувати Ruff 0.16.5 у dev dependencies або CI-образі.
• Запустити preview і category selectors без автоматичного виправлення та зберегти звіт як артефакт.
• Розділити результати на реальні дефекти, питання стилю та помилкові спрацювання.
• Для async-попереджень додати тест під навантаженням, бо статичний аналіз не вимірює фактичну затримку.
• Виконувати unsafe fixes лише після перегляду diff і запуску повного набору тестів.

У документації релізу також уточнено правила приймання нових перевірок і опис категорій. Це сигнал, що команда Ruff формалізує не лише реалізацію, а й модель керування великим каталогом правил. Для користувачів результатом має стати більш послідовна конфігурація, однак preview-функції ще не слід сприймати як остаточний контракт.

Джерело та права

Матеріал є самостійним українським перекладом-переказом release notes Ruff 0.16.5, опублікованих 27 серпня 2026 року командою Astral. Код, документація та release notes офіційного репозиторію поширюються за MIT License. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.