Comments 12
Планируется ли какая-нибудь он-лайн трансляция (даже если она будет платная)? Было бы здорово поучаствовать в подобном мероприятии при невозможности реального посещения.
17 000 за курс об async в Python — это мощно. Интересно, чего там такого на 17к расскажут.
Я знаком с aiohttp не понаслышке.
Пытались пользоваться им, после постройки прототипа переписали все на привычном flask (поэтому картинка к посту доставила).
К сожалению, мир asyncio все ещё в зародыше. Пока не появится адекватных библиотек и ORM систем уровня алхимии, создавать что-то сложнее todo-листа на стэке aiohttp является крайне трудным.
А с учётом общей сложности написания кода с async/await, отсутствие адекватной работы с @property, я думаю что пройдут годы перед тем, как это наступит. Если наступит вообще. Люди выбирают Python из-за простоты, чем предлагаемый стэк разработки похвастаться не может.
Я знаком с aiohttp не понаслышке.
Пытались пользоваться им, после постройки прототипа переписали все на привычном flask (поэтому картинка к посту доставила).
К сожалению, мир asyncio все ещё в зародыше. Пока не появится адекватных библиотек и ORM систем уровня алхимии, создавать что-то сложнее todo-листа на стэке aiohttp является крайне трудным.
А с учётом общей сложности написания кода с async/await, отсутствие адекватной работы с @property, я думаю что пройдут годы перед тем, как это наступит. Если наступит вообще. Люди выбирают Python из-за простоты, чем предлагаемый стэк разработки похвастаться не может.
На заметку: кто-то считает как вы, а кто-то просто его использует. Там все просто. И достаточно эффективно.
создавать что-то сложнее todo-листа на стэке aiohttp является крайне трудным
Асинхронный* код не для всего подряд, и делать обычные сайты (большинство веб проектов) на нем не выгодно, к тому же результат может работать медленнее чем синхронный вариант.
Люди выбирают Python из-за простоты, чем предлагаемый стэк разработки похвастаться не может.Проблема не в стеке, асинхронный код везде вносит повышенную сложность.
Проблема не в стеке, асинхронный код везде вносит повышенную сложность.
Я бы так не сказал. Например, в Unity3D, асинхронный код здорово упрощает жизнь, потому что альтернатива там — это многопоточность, которая в разы сложнее.
С Unity3D не знаком, можете привести код для сравнения? Вообще, помимо многопоточности существуют корутины/горутины/файберы — шаг в правильном направлении, но мало кто движется в эу сторону.
Код, в целом, как в питоне до введения ключевых слов async/await.
Т.е. корутины, основанные на итераторах:
yield return StartCoroutine(MyCoroutine(var1, var2));
Вопрос не в форме написания кода, а в том, что в геймдеве это имеет гораздо больше смысла. Когда вся логика построена на обновлении состояния объектов каждый кадр, строить код на корутинах значительно проще, чем на чем-либо еще.
Но как только в игре нужно сделать обращения во внешний сервис, сделать http запрос в REST api, или в целом поработать с какими-то внешними асинхронными задачами, или, что еще хуже, построить цепочку из таких действий, которые зависят друг от друга, то начинается адовый ад. Частично это связано с тем, что корутины в Unity не поддерживают возвращение значения, приходится комбинировать коллбэки и корутины, и код превращается в callback hell. Исключения не выкинуть, половину языка не использовать, про адекватный ООП и паттерны можно забыть, итд.
Тоже самое с веб-девом. Возможно, если вы пишите простейшее, «плоское» приложение, где у вас весь проект — это набор методов-обработчиков роутингов, которые берут параметры запроса, совершают некие асинхронные действия с MongoDB, и отдают ответ, то да, наверное, aiohttp можно использовать.
А если вам нужно построить по-настоящему сложную и расширяемую систему (например, форумный движок), где необходимо по максимуму использовать ООП, где без ORM системы не выжить, потому что модели нужно наследовать друг от друга и они могут иметь связанную логику, где нужно кэшировать результаты запросов в БД через property, где нужно по-максимуму использовать те же паттерны — выбор aiohttp стэка для вас будет огромной ошибкой.
Если вам где-то в коде нужно совершить запрос в БД, то вам прийдется «протянуть» весь колл стэк от роутинга до запроса в БД через корутины. Соответственно, вы не можете пользоваться конструкторами (не будете же вы __init__ делать корутиной?), вы не можете пользоваться свойствами, итд.
Т.е. корутины, основанные на итераторах:
yield return StartCoroutine(MyCoroutine(var1, var2));
Вопрос не в форме написания кода, а в том, что в геймдеве это имеет гораздо больше смысла. Когда вся логика построена на обновлении состояния объектов каждый кадр, строить код на корутинах значительно проще, чем на чем-либо еще.
Но как только в игре нужно сделать обращения во внешний сервис, сделать http запрос в REST api, или в целом поработать с какими-то внешними асинхронными задачами, или, что еще хуже, построить цепочку из таких действий, которые зависят друг от друга, то начинается адовый ад. Частично это связано с тем, что корутины в Unity не поддерживают возвращение значения, приходится комбинировать коллбэки и корутины, и код превращается в callback hell. Исключения не выкинуть, половину языка не использовать, про адекватный ООП и паттерны можно забыть, итд.
Тоже самое с веб-девом. Возможно, если вы пишите простейшее, «плоское» приложение, где у вас весь проект — это набор методов-обработчиков роутингов, которые берут параметры запроса, совершают некие асинхронные действия с MongoDB, и отдают ответ, то да, наверное, aiohttp можно использовать.
А если вам нужно построить по-настоящему сложную и расширяемую систему (например, форумный движок), где необходимо по максимуму использовать ООП, где без ORM системы не выжить, потому что модели нужно наследовать друг от друга и они могут иметь связанную логику, где нужно кэшировать результаты запросов в БД через property, где нужно по-максимуму использовать те же паттерны — выбор aiohttp стэка для вас будет огромной ошибкой.
Если вам где-то в коде нужно совершить запрос в БД, то вам прийдется «протянуть» весь колл стэк от роутинга до запроса в БД через корутины. Соответственно, вы не можете пользоваться конструкторами (не будете же вы __init__ делать корутиной?), вы не можете пользоваться свойствами, итд.
А сколько часов в день будет проходить этот курс?
Ссылки внизу полезные.
Еще в качестве вводного материала могу порекомендовать свежее выступление хабраюзера xen, который разрабатывал и на Django, и на Flask, и в текущем проекте AskPapir.com использует aiohttp и делится своим практическим опытом.
Вначале очень понятное описание, что это и зачем нужно. Дальше проблемы асинхронной разработки, чего не хватает для счастья разработчика на текущий момент.
Еще в качестве вводного материала могу порекомендовать свежее выступление хабраюзера xen, который разрабатывал и на Django, и на Flask, и в текущем проекте AskPapir.com использует aiohttp и делится своим практическим опытом.
Вначале очень понятное описание, что это и зачем нужно. Дальше проблемы асинхронной разработки, чего не хватает для счастья разработчика на текущий момент.
С удовольствием оплатил бы онлайн трансляцию, если таковая возможна.
Sign up to leave a comment.
Учимся работать с asyncio+aiohttp: в Москве пройдет курс от Core-разработчика Python