В Python 3.15 open() без encoding читает и пишет UTF-8 независимо от локали (PEP 686). На русской Windows и серверах с ru_RU.CP1251 это значит падения на выгрузках из 1С и, что хуже, тихие кракозябры в файлах для соседних систем. Воспроизводим на 3.14 и 3.15, находим такие места через EncodingWarning и ruff и чиним так, чтобы код одинаково работал на всех версиях.

20 октября раскрыли слабо сгенерированные ключи промежуточных УЦ eMudhra. Браузеры и системное хранилище уже починили, но официальный pip по-прежнему доверяет встроенному бандлу certifi: одного обновления ОС недостаточно. На стенде сравниваю пакетный pip из Debian 13, Python 3.15.1 и 3.15.2, certifi 2026.10.19 и 2026.10.23 и проверяю, есть ли в интерпретаторе блоклист ssl из CVE-2026-115557. Весь вывод — с локальной машины.

Задача в crontab ещё не закончилась, а следующий запуск уже стартовал: два START, два конкурирующих UPDATE. Воспроизводим на Linux, закрываем гонку через flock из util-linux, сравниваем «пропустить» и «подождать», и показываем тот же приём из Python через fcntl.flock. Весь вывод — с локального стенда.

Обработчик увеличил баланс, но ответ потерялся. Отправитель повторил вебхук — и баланс вырос ещё раз. Разбираем защиту на Python и SQLite: уникальный ключ, общая транзакция и воспроизводимые тесты повторной и параллельной доставки. Заодно проверим падение посередине обработки и одинаковый ключ с разным содержимым.

По умолчанию у requests таймаута нет: клиент может висеть часами. Разбираем, чем connect отличается от read, почему одно число в timeout — не «длина всего запроса», как настроить urllib3.Retry без шторма и POST-дублей, и как ограничить всю операцию бюджетом времени. Код прогнан на Python 3.13 и requests 2.34 / urllib3 2.8; цифры — с локального стенда.

На этой неделе в топе снова всплыла старая история: свежий VPS, ufw default deny incoming, наружу только 22, 80 и 443, а потом в compose-файле появляется ports: - "5432:5432" — и через пару дней в базе лежит записка с биткойн-кошельком. Почему так происходит, уже разобрали подробно. Я хочу про другое: как сделать так, чтобы такой compose-файл вообще не доехал до сервера.

Ниже — два небольших скрипта на Python. Первый проверяет compose-файлы до деплоя и падает с ненулевым кодом, если порт опубликован на все интерфейсы. Второй смотрит, что реально слушает на машине, без ss и netstat, прямо из /proc. Весь код я запускал на Python 3.13 и PyYAML 6.0.3, вывод в статье — настоящий.

На этой неделе в топ Хабра попала история о том, как Telegram Desktop при запуске рекурсивно чистил чужую папку C:\custom и унёс около 800 ГБ проектов и программ. Комментарии предсказуемо разделились на «как такое вообще можно выпустить» и «у нас в проекте есть такой же скрипт, просто ему пока везло».

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

Ниже — разбор типичных способов выстрелить себе в ногу и рабочий код на Bash и Python, который эти способы закрывает. Весь код я прогнал на Python 3.13 и GNU coreutils 9.7.

Страница со списком из 100 постов на проде тормозит, а в профайлере — сотня одинаковых лёгких запросов. Это N+1: разбираем, как Eloquent создаёт его через ленивую загрузку, как лечить через with() и withCount() и как запретить на уровне фреймворка через preventLazyLoading().

Когда в Laravel нужно обработать большую таблицу, обычно советуют «не делать all(), использовать chunk()». Совет верный, но неполный: у chunk() есть ловушка, из-за которой фоновая задача тихо обрабатывает только часть строк. Ниже замеры пяти способов обхода таблицы на 100 000 строк, разбор потери строк и правила выбора метода.

Про N+1 в Laravel обычно пишут три строки про with() и расходятся. Я собрал небольшой стенд на Laravel 13 и SQLite, воспроизвёл проблему, посчитал запросы для каждого способа лечения и проверил, что «не ловится» режимом запрета ленивой загрузки. Отдельно разобрал места, где eager loading не помогает или сам создаёт нагрузку. Все числа в статье получены на этом стенде на искусственных данных.