Search
Write a publication
Pull to refresh

Comments 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 всё-же назвать стоит, чтобы не путать, и предупредить что внутри магия.

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

А особенно меня просто убил параметр у функции callback в tornado: ) до такого уродства надо было додуматься.
UFO landed and left these words here
Возможно, что у торнадо меньше накладных расходов на абстракциях, так как он гораздо менее универсален, но на приложении не hello world эта разница быстро съедается реальными задачами.
Ну и есть ли у торнадо средства для работы с memcache и тп? Возможно ли на торнадо легко и просто реализовать какой то протокол?
В общем в этом вопросе я заодно с авторами twisted — торнадо это обделенный функциональностью велосипед. Я после вашего комментария специально пошел и посмотрел в его код — мон блин! Они даже в пул тредов не удосужились скинуть работу с БД!
UFO landed and left these words here
UFO landed and left these words here
Sign up to leave a comment.

Articles