Комментарии 7
Опять забыт любимый мной curio. A ведь это реально интересная альтернатива asyncio!
Автору спасибо. Я вспомнил, почему я не читаю инфоцыганский SFP: У них много абзацев повторяющих сами себя.
Интересный инструмент, почитал.
Единственное, что смущает:
Q: Is Curio meant to be a clone of asyncio?
A: No. Although Curio provides a significant amount of overlapping functionality, the API is different. Compatibility with other libaries is not a goal. (Совместимость с другими библиотеками не является целью.)
Как он себя покажет если мы начнём строить большую систему, где за основу возьмём curio? Придётся ли нам переизобретать велосипеды из-за того что curio не поддерживает интеграцию с текущими библиотеками?
P.S. в статье и правда есть, лишнее, что-то незначительное убрал, но в целом это перевод другой статьи, если совсем причёсывать, то это будет не перевод, а пересказ:)
я фанат David Beazley, автора curio. Потому использую его с начальных версий (rc1). Соответственно - весь код у меня ориентирован на curio. Работает без сбоев, утверждается, что curio быстрее, чем... Но, если я захочу библиотеку поменять на asyncio - то код придется переписывать. Просто импорт иcправить не прокатит. Наоборот, соответственно тоже. И, конечно, dependencies, что в проекте используют asyncio - будут ее и дальше использовать, от этого не уйти. Я думаю, именно это имеется ввиду.
В конце главы "Шаг 3: пулы или исполнители" прикреплен не тот рисунок.
Автор красиво расписал теорию (оно и понятно, не зря же он в скилбоксе преподает), но на практике все обычно сводиться к асинхронным i/o (fastapi, aiohttp), если сервис пишется свежий или django и flask, если уже на них многое реализовано(они тоже едут к асинхронщине). Если нужно чего-то посчитать тяжёлое - добавляют к асинхронщине ProcessPoolExecutor, с парой тройкой воркеров (тут главное правильно натыкать async/await и завернуть в нужный event loop и при этом поднять их при запуске сервиса, а не при запросе в него, иначе время на запуск процессов сожрёт весь профит). Но тут начинаются проблемы: если сервис крутится в кубере - нужно прописать правильные настроечки, чтобы ваш сервис не сожрал все свободные ядра.
Вообще, для меня, выглядит так, что потоки в питоне - это что-то ненужное и в промышленных решениях очень малоиспользуемое. Асинхронщина и многопроцессность - this is the way.
Потоки/процессы появились в Python за долго до asyncio. Я согласен, что переключением между потоками Python делает не оптимально, разработчик лучше понимает, где нужно переключиться на другую задачу и это можно реализовать с помощью asyncio. Но как вы правильно заметили, есть множество проектов написанных на синхронном Python, и не всегда удаётся переехать на асинхронную версию движка, поэтому про потоки в Python тоже не стоит забывать.
Возможно в каком-то будущем мы избавимся от них полностью, но не сейчас.
Как выбрать в Python подходящий конкурентный API