Автор: Дмитрий Ходаков · PyCon Russia 2018

В 2015 году команда Авито выбрала Tornado по правильным причинам. Фреймворк был зрелым, выдерживал production-нагрузку и располагал библиотеками для нужных баз данных. На его основе собрали общий шаблон, от которого затем выросли десятки микросервисов.

Через три года сервисы продолжали работать, но изменился сам Python. Нативные async/await и стандартный asyncio сформировали другую модель асинхронного приложения. Tornado тоже развивался, однако за ним тянулись генераторы, глубокие стеки и собственные исторические абстракции. Когда рядом появился aiohttp, прежний разумный выбор начал обходиться дороже нового — хотя формально ничего не сломалось.

Доклад Дмитрия Ходакова полезен в 2026 году именно этой историей. У технологического решения нет вечного преимущества: оно принимается в конкретной экосистеме и может пережить причины, по которым его когда-то выбрали.

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

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

Автор: Юрий Селиванов · PyCon Russia 2018

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

В 2018 году Юрий Селиванов рассказывал не только о новых возможностях Python 3.7, но и о фундаментальном недостатке раннего asyncio: библиотека позволяла запускать задачи почти из любого места, не заставляя связывать их жизненные циклы. В результате задача могла пережить породивший её код, потерять исключение или оставить незакрытые ресурсы. Решение автор искал в идеях Trio: nursery, supervisors и управляемых областях отмены.

Смотреть этот доклад сейчас особенно интересно. Можно сравнить планы автора с тем, что действительно появилось в Python. Конкретные API изменились и пришли позже, но поставленная проблема оказалась точной: современному async-коду понадобились не новые способы запускать корутины, а структурированное управление ими.

Кому смотреть: Python-разработчикам, которые используют фоновые задачи, таймауты и конкурентные запросы, но ещё полагаются преимущественно на create_task() и gather().

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

Автор: Артём Малышев · Moscow Python Conf 2016

⚠️ Материал 2016 года, Django Channels 1.x. Концептуальный разбор «зачем это нужно» остаётся актуальным. Детали API и конкретные паттерны с тех пор существенно изменились (Channels 2.x переписал архитектуру Channel Layer). Сверяйтесь с актуальной документацией.

Классический Django построен на WSGI — стандарте, появившемся в 2003 году. Его базовый контракт прост: принять запрос, вернуть ответ. Никакой асинхронности, никаких долгоживущих соединений. Это сознательный дизайн для эпохи, когда веб состоял из страниц с новостями и гостевых книг.

Современный веб хочет другого: живой контент без перезагрузки страницы, WebSocket-соединения, уведомления в реальном времени — пользователи не хотят нажимать F5. Django Channels — это ответ на этот запрос: расширение, добавляющее поддержку асинхронных протоколов поверх синхронного фреймворка.

Кому смотреть: Django-разработчикам, которым нужны WebSocket или long-polling, и которые хотят понять как Channels вписывается в Django-архитектуру — особенно где заканчивается синхронный Django и начинается async.

Из этого можно взять в работу: если добавляете real-time функциональность в Django-проект — поймите границу между синхронным Django (models, ORM, middleware) и async Channel Layer до того как начнёте писать код. Смешивать их без понимания этой границы — источник трудноуловимых проблем.

Автор: Григорий Петров и Никита Соболев · MoscowPython

Python Day Special на Positive Hack Days 2025 — формат живой дискуссии за столом, который Moscow Python проводит как спецвыпуск между конференциями. Ведущие — Григорий Петров (евангелист MoscowPython) и Никита Соболев. Тема — асинхронность в Python: не туториал по asyncio, а честный разговор о том, что эта парадигма даёт и чего стоит.

Разговор идёт по структуре: сначала реальные преимущества (07:43), затем реальные недостатки (19:04), затем то о чём обычно не говорят — сложности асинхронного программирования в целом (22:10). Отдельный блок — несовместимость sync и async миров в библиотеках и фреймворках (28:22, 43:55): когда одна синхронная зависимость блокирует весь event loop.

Кому смотреть: Python-разработчикам, которые используют async на практике или только решают, нужен ли он их проекту — и хотят услышать взвешенную оценку, а не «async — это будущее».

Из этого можно взять в работу: проверить, нет ли в вашем async-коде синхронных вызовов в библиотеках без async-поддержки — это одна из самых частых причин, когда async не даёт ожидаемого прироста.

Автор: Алексей Фирсов (мейнтейнер aiopg, SoftPro) · MoscowPython

⚠️ Выпуск записан в 2019 году. Детали реализации aiopg и экосистема async-драйверов для PostgreSQL с тех пор изменились (появились asyncpg, sqlalchemy async, psycopg3). Архитектурные решения и вопросы дизайна — актуальны.

Первый выпуск Moscow Python Podcast (переименован из Python Junior Podcast) открылся «хардкором и сеньорностью». Гость: Алексей Фирсов, старший разработчик SoftPro и мейнтейнер библиотеки aiopg. Разговор ведут сооснователь MoscowPython Валентин Домбровский, тимлид NVIDIA Злата Обуховская и Григорий Петров. 44 минуты про то, как устроен асинхронный доступ к PostgreSQL из Python — и зачем вообще нужна отдельная библиотека для этого.

Центральный вопрос выпуска формулируется прямо: так ли уж нужна целая библиотека для взаимодействия асинхронного кода с PostgreSQL (05:32)? Ответ разворачивается через архитектурные детали: aiopg работает поверх psycopg2, который работает поверх написанной на C библиотеки libpq — и при этом сам написан на Python, а не на C. Почему — отдельный разговор (12:36).

Кому смотреть: Python-разработчикам, которые используют или планируют использовать async с PostgreSQL и хотят понять что происходит «под капотом», а не просто вызывать await conn.execute().

Из этого можно взять в работу: проверить в своём async-коде — есть ли места, где coroutine вызывается без await. Python это разрешает, и это источник трудноуловимых багов. Вопрос поднимается в выпуске явно (35:14) как вопрос дизайна языка.

Автор: Артём Шумейко · YouTube

Артём Шумейко — Python-разработчик и преподаватель, специализируется на backend. В коротком видео показывает на живом примере и с реальными цифрами, как FastAPI обрабатывает больше тысячи запросов в секунду.

Асинхронность часто объясняют через «это быстро» — и это неточная формулировка, которая потом мешает. FastAPI не делает CPU-код быстрее. Он устраняет простой: пока один запрос ждёт ответа от базы данных или внешнего сервиса, event loop берёт следующий. При I/O-bound нагрузке это даёт кратный прирост пропускной способности без дополнительных потоков и без накладных расходов на переключение контекста. Видео полезно тем, что показывает разницу измеримо, а не концептуально.

Кому смотреть: Python-разработчикам, которые пишут async/await по инерции или «потому что так принято в FastAPI», но не могут объяснить, почему это работает и когда это не поможет.

Из этого можно взять в работу: найди в своём коде async-функцию, которая делает блокирующий вызов — requests.get() вместо httpx, time.sleep() вместо asyncio.sleep(). Одна такая точка блокирует весь event loop.