Посмотрел на aiohttp, осталось странное такое впечатление.
Начнём с того, что асинхронный aiohttp в 2-5 раз медленнее синхронных топов на самой простой задаче - вернуть JSON. Окей, в реальной жизни засчёт однопоточности и ненужности кеш-серверов скорость сгладится.
Второе. Андрей Светлов говорил: "смотрите, у нас есть джынжа со с макой! Можно уже писать приложения!". Да.
aiohttp_jinja2 не проверяет в декораторе значение, которое ей передаётся. Вернули не словарь? Нате пятихатку!
Почему бы не проверять? Почему в шаблон не передаётся request по умолчанию, почему мне нужно будет вписывать его самостоятельно? Если бы мне хотелось многословия, я бы Django использовал.
Третье, про aiohttp.web. В pyramid, к примеру, есть чёткое разделение между роутом и вью-функцией, где роут - это URL с именем, а во вьюшке можно определить обработчик роута в зависимости от HTTP-метода и прочего. В результате можно строить URL в шаблоне, указывая имя роута и необходимые параметры; очень удобно. В отличие от pyramid, в aiohttp есть понятие роута, где сразу же указывается HTTP-метод, URL и обработчик. Что самое злое, метод тут - ТОЛЬКО СТРОКА. Не список/множество возможных методов типа method=('GET', 'POST'), а только строка. В результате необходимо придумывать разные name для роута для одного и того же URL, что добавляет неудобства для их построения. И чёртово отсутствие request в шаблоне, чёрт бы его подрал. Ну не хочу я вертать взад dict(request=request, user='Tark'), я хочу без реквеста, но чтобы оно в шаблон передавалось самим aiohttp. Аргх!
Что понравилось - aioauth-client. Ужасное название пакета, но какая прелесть внтурях. Осталось чуток дописать, чтобы не приходилось делать if 'twitter' elif 'github' elif 'google', добавить роутов и можно получить нормально работающий python-social-auth-light.
Но пока что всё это слишком не доработанное. Разработка идёт гигантскими шагами, но результат пока ещё использовать тяжело.
