Как стать автором
Обновить

Комментарии 34

Меня больше всего интересует в данном моменте создание или обертка вокруг ORM, для получения асинхронных обращений к БД. Ты пробовал уже что-нибудь подобное реализовать? Интересует, конечно же, работа в контексте psycopg2.
Ну в общем тема обсуждалась и обсуждается — сопрограммы у нас сейчас на пике моды конечно, а асинхронностью бредят все, и особенно в приложении к Django: )

Посмотри вот тут — code.google.com/p/coev/source/browse/#hg/examples/django/hwcoev, хотя как я понимаю код в альфе. Я бы попробовал на самом деле влезть джанге в душу, то есть в глубины кода, но сейчас захвачен идеей попробовать собрать свой фреймворк с jinja и с pyrant-models, поверх вот этой вот моей обертки.
есть готовый проект, схожий с тем, что ты пытаешься собрать. Никак не могу найти источник, там речь шла об обвязке werkzeug+jinja2+sqlalchemy+migrate+command (хотя побродив по просторам интернетов услышал много негатива в адрес jinja2 с планами по переходу на mako). Т.е. всё, что делает джанга, но не велосипедами её создателей, а готовыми питоньими модулями. На эту тему есть пост на pyobject.ru. Много еще пишет Александр Соловьев.
Svarga, только он, как я понял, тоже не затронут асинхронностью. Я его изучаю сейчас, думаю у Александра есть чему поучится.
В точку, спасибо за подсказку. Я на него еще не смотрел как следует. В общем-то меня пока еще пугают фреймворки с отсутствием внятного тестирования. UnitTest не справится с тестированием за пределами ядра приложения, особенно, когда нужны behavior-тесты. Смотрю, кстати, в сторону pycukes, но до работы cukes с джангой мне еще не достает тестового окружения.
Не, про асинхронность мы даже и не думали, sqlalchemy — синхронная, да и стиль написания асинхронных программ в питоне в большинстве случаев не радует абсолютно… Гринлеты еще туда-сюда, но твистед и торнадо — точно не радуют. :)
можно раскрыть тему негатива в адрес jinja2?
Присоединяюсь к вопросу.
тема негатива на самом деле наиграна, раз уж пошла речь об отрыве от стандартного (к слову, довольно медленного) шаблонизатора django — jinja — наиболее близка к нему по синтаксису, чего не скажешь о Mako, есть несколько примеров сравнения синтаксиса, и еще отдельно есть небольшой обзор, c которого я и начинал вспоминать о sarga. В последнем и всплыл этот момент.
Ну синтаксис как раз можно и сменить (хотя джинджа привлекает тем, что на неë с джанги перейти легко), а Jinja из поста Юры — это Jinja1, и она действительно была несколько странной. В общем и целом Jinja2 очень клëвая, на мой взгляд. :)
Jinja из поста Юры — это Jinja1, и она действительно была несколько странной. В общем и целом Jinja2 очень клëвая, на мой взгляд.

Всё так :) Jinja версий 0.X, 1.X и 2.X — три разные вещи. И Jinja2 хороша, особенно как покопаешься во внутренностях Django templates.
хорошо бы сделать обзор актуальных на сегодняшний день шаблонизаторов в мире python.
Ну, даже если вкратце перечислить просто, то по-моему актуальны всего три — Jinja2, Mako и Genshi. Ну и GHRML, если хочется поиграться с Haml-like синтаксисом. Больше ничего особенно интересного и нету…
В общем у многих идея витает асинхронность джанге привить, но я пока ни одной истории успеха не встречал.
И в итоге — я сейчас пробую перейти на pylons, уж очень он захватил меня своей модульной структурой, так что не спеши со svarga, хотя бы в том плане, что коммьюнити pylons всё-таки есть, и реактивность вопросов будет выше. Плюс — я же брежу production-ами. Так что svarga пока явно не мой выбор. А если с pylons всё получится, то очередной проект сделаю именно на нём и будет чем поделиться, в плане опыта.
Очень схожие аргументы и у меня насчет pylons.
Только куда там прививать асинхронность?
Для асинхронности во всех фреймворках фактически одно главное место, куда ее надо вкручивать — БД. Я сейчас не готов сказать, возможно ли куда то в pylons вкрутить асинхронность, не знакомился с этим фреймворком.
Прививать асинхронность Django — пустая затея. Более того, я не понимаю цели. Проще говоря, чего желаете добиться, прикрутив асинхронный I/O к веб-фреймворку?

Ну т.е. вы можете конечно использовать WSGI-интерфейс twisted или tornado, но только Django/Pylons то остаются синхронным и толку ноль от того, что http-сервер асинхронный.

Гораздо продуктивнее (во всех смыслах), IMHO, пытаться «облагородить» twisted или tornado, чтобы можно было писать проще.
они как-раз и хотят сделать Django/Pylons асинхронными.

чисто теоретически, оборачивая все блокирующие вызовы в tx_green.wait, можно делать их асинхронными, не меняя код который их использует.
Если быть точным, то wait оборачивает асинхронный код, позволяя мимикрировать коду высшего порядка под синхронный. Или по другому — код высшего порядка может быть написан в обычном синхронном стиле, если использует для обращений в БД и тп, код обернутый в wait, а сам вызов этой библиотеки обернут в наш декоратор.
согласен, но я о том, что в контексте «асинхронизации джанги» магия этого подхода в том, что его можно воткнуть в небольшом количестве мест в самом низу, почти не меняя сам фреймворк
Любопытно. В коде ничего не понял, но это, скорее всего, проблема чтеца. Особенно если учесть, что в репозитории не обучающий пример и не заранее продуманный проект, а потенциально полезный эксперимент (как и сами Pyrant и Models).

Вопрос: практическая польза оправдывает нелинейность кода и описанные вами потенциальные плавающие баги? Чем и как это можно измерить?
Как и чем измерить прирост продуктивности или же его падение, я, к сожалению, не в курсе — не имею таких навыков.

А баги — ну была мысль ломать модуль socket или что то в этом духе — поймаешь программу, которая socket пытается использовать, и сразу предупреждение. Хотя как я понимаю с драйвером mysql вот не сработает — он, наверное, питоновский сокет и не использует. В общем по хорошему как то надо универсально заблокировать сетевые операции, идущие мимо twisted, и тогда потенциальных проколов будет меньше.

С другой стороны подкладывание соломки это, как мне кажется, не python way. В питоне же нет приватных методов у классов и тп — рассчитано, что программист знает, что он делает.
помойму очень круто.

только как минимум декоратор не inlineCallbacks всё-же назвать стоит, чтобы не путать, и предупредить что внутри магия.

а сам подход очень интересный.
поправил, назвал make_it_green.
НЛО прилетело и опубликовало эту надпись здесь
А что за методы? Никакие гринлеты не помогут сделать синхронное асинхронным — гринлеты это средство скрыть асинхронность. Поэтому если блокирующие методы это какие то вычислительные задачи, то треды или мультипроцессинг, или что-нибудь готовое для этих целей.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Смотря какая БД. Если postgres, то есть pgasync для Twisted. Да, не для торнадо, но я в нем смысла не вижу. Вообще советую ознакомится именно с Twisted — он не заточен на HTTP only. Реализации mysql на твистед не встречал, но вообще стоит осмотреться — есть много чего готового.

А особенно меня просто убил параметр у функции callback в tornado: ) до такого уродства надо было додуматься.
НЛО прилетело и опубликовало эту надпись здесь
Возможно, что у торнадо меньше накладных расходов на абстракциях, так как он гораздо менее универсален, но на приложении не hello world эта разница быстро съедается реальными задачами.
Ну и есть ли у торнадо средства для работы с memcache и тп? Возможно ли на торнадо легко и просто реализовать какой то протокол?
В общем в этом вопросе я заодно с авторами twisted — торнадо это обделенный функциональностью велосипед. Я после вашего комментария специально пошел и посмотрел в его код — мон блин! Они даже в пул тредов не удосужились скинуть работу с БД!
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации