Думаю, ни для кого не секрет то, что основная реализация языка программирования Python фактически не поддерживает многопоточности. Есть модули которые позволяют эмулировать потоки посредствам процессов, но подобный путь крайне требователен к ресурсам и поэтому его применимость крайне ограниченна, особенно для большого количества операций ввода/вывода. При этом, в подавляющем большинстве случаев, распараллеливание задач не несет какого-то серьезного практического смысла и просто является одним из возможных архитектурных решений. В качестве альтернативы потокам могут выступать асинхронные операции, а с учетом ограничений интерпретатора, подобный подход должен бы был быть родным подходом в Python уже много лет как. Тем не менее, появился долгожданный модуль asyncio только в Python 3.4, но это в любом случае лучше чем никогда.

Говорить о asyncio в чистом виде не очень интересно, т.к. в отличие от того же Twisted, это низкоуровневое API позволяющее работать с потоками ввода/вывода и блокировками. К счастью, прогресс не стоит на месте и уже имеется как минимум одна интересная библиотека для неблокирующей работы с протоколом HTTP – aiohttp, доступная через pip.

Работа с asyncio особо не отличается от работы с библиотеками асинхронного IO на любом другом языке программирования за исключением встроенной поддержки coroutine. Конечно, возможности предоставляемы coroutine можно и не использовать, но на мой взгляд они сильно облегчают написание и поддержку не сложных асинхронных приложений, хотя и не подходят, с архитектурной точки зрения, для чего-то большого, требующего полного контроля над операциями ввода/вывода.

Ядром любой асинхронной IO библиотеки является обработчик сообщений, и asyncio тут не исключение. Так метод asyncio.get_event_loop() возвращает 7 объект реализующий интерфейс AbstractEventLoopPolicy. Само собой, на каждой из поддерживаемых платформ реализация обработчика сообщений будет разнится, где-то это будет kqueue(), где-то epoll() и т.д.

Библиотека asyncio поддерживает большое количество различных способов обработки событий на все случаи жизни. А в моем примере я просто ограничился функцией wait() 9, создающей объект Future по средствам которого можно дождаться завершения цепочки асинхронных операций 10.

Принцип работы функций являющихся coroutine 1, 5 хорошо проиллюстрирован в документации к библиотеке asyncio и в сочетании с yield from формой вызова дает отличные возможности для написания асинхронного приложения. Как видно из примера 346, результирующий код выглядит “синхронным” и не требует дополнительных обработчиков функций обратного вызова, что характерно для классических асинхронных приложений.

В качестве небольшого дополнения к примеру был добавлен семафор 8 для ограничения числа параллельных IO операций. Без подобного ограничения 2 вся тысяча запросов была бы отправлена одновременно, а это мало того что совершенно бессмысленно с точки зрения обработки данных, так еще и создаст лишнюю нагрузку на сетевую подсистему ОС.

Уверен, что количество библиотек содержащих реализации новых сетевых протоколов поверх asyncio в скором времени будет стремительно расти. Хотя я, в первую очередь, надеюсь что это событие послужит толчком, который ускорит портирование Twisted на Python3.