Собрали в одном месте самые важные ссылкии сделали Тренажер IT-инцидентов для DevOps/SRE
За последнее время я прочитал множество репозиториев, где в Pyhton пользуются типизацией и почти везде синтаксис не новее 3.11: Optional, TypeVar на уровне модуля, Generic[T], кавычки вокруг опережающих ссылок. При этом у Python 3.10 поддержка закончилась, и разработчики языка дали нам новых удобных инструментов и чтобы ими пользоваться не всегда нужно обновляться до последней версии. В этой статье расскажу, какие основные фишки появились за последние несколько лет и как ими пользоваться даже в проектах на старых версиях.
ㅤ
Мощный web-фреймворк. Скачать можно по ссылке: https://pypi.python.org/pypi/Django/
Клиентский поток неоднороден. Он зависит от дня недели, месяца, праздников, времени суток, расположения и формата отделения, а также от локального расписания. Среднее значение за месяц для кадрового планирования почти бесполезно: два отделения с одинаковым месячным объёмом могут иметь совершенно разные утренние пики, продолжительность рабочего дня и долю вечерних посещений.Поэтому банку критически важен прогноз клиентопотока для сбалансированного операционного планирования: нехватка сотрудников ведёт к росту очередей и риску нарушения целевых сроков обслуживания,
Модель «упрощает» валидацию. Линтер молчит, тесты проходят, ревьюер видит аккуратный дифф в одну строку и жмёт Approve. Через неделю выясняется, что функция скидки начала принимать отрицательный процент.Тесты в таком PR почти всегда написала та же модель, что и код. Они подтверждают, что модель сделала задуманное, и ничего не говорят о том, ведёт ли себя код так же, как раньше. Я сделал инструмент, который проверяет именно это
AMQP-клиент. Скачать можно по ссылке: https://pypi.python.org/pypi/amqp/
http клиент/сервер для asyncio. Скачать можно по ссылке: https://pypi.python.org/pypi/aiohttp
Сценарий знакомый: открываешь в pandas файл побольше, ноутбук задумывается, и через минуту всё падает с MemoryError. Следом обычно звучит совет: для больших данных есть Spark. Я решил проверить его цифрами, но не на кластере, а на слабой машине с двумя ядрами и 5,8 ГБ памяти.Сравнил шесть вариантов: pandas, pandas с pyarrow, Polars, Polars в потоковом режиме, DuckDB и PySpark. Пять типовых операций, объёмы от 6 до 180 млн строк, контроль памяти и автоматическая сверка результатов между библиотеками. Эта сверка по дороге нашла баг, из-за которого Spark терял целый день данных.Кто сдался первым, кто удивил и почему переход на Spark часто не лучший выход, рассказываю под катом.
Недавно я гонял бенчмарки на свежей сборке CPython (ветка с tail-call интерпретатором, PGO + LTO, GCC) и снял флеймграф стандартного бенчмарка async_generators из набора pyperformance (рекурсивный обход дерева на 100 000 нод с глубиной вложенности ~17).Картина на профиле оказалась фееричной: почти треть всего процессорного времени (29%) сжиралась кодом, который вообще не делал никакой полезной работы.Рантайм создавал, настраивал, а затем тут же уничтожал объекты исключений StopIteration, о существовании которых Python-код даже не догадывался.Ниже о том, откуда растут ноги у этой проблемы в Си-коде CPython и как пара правок в genobject.c дали ускорение в 1.33x — 1.53x.