Django 1.3 вышел в свет

* должны склеиваться Pylons и Pyramid

> И главное - Django ~ 30 000 строк кода, Pylons ~2000 строк кода. Вы посчитали, только код pylons, забывая сколько пилоны тянут зависимостей, с учетом их я думаю счет сравняется

Ну вот, пришёл и испортил мне всю коммерцию. А откуда мне тогда будет брать благодарных школьников на завтрак, обед и ужин. :-)

>Пример красивого php-кода, пожалуйста.

Yii, Symfony, Zend Framework, Drupal.

У меня уже за много лет выработался такой метод изучения чужого кода: смотрю в браузере нужную страничку, смотрю ее урл иду в urls.py и во одном месте определяю какая вьюха занимается отображением этой странички. Потом уже иду во вьюху и изучаю код, а дальше правлю, если надо. Как-то мне кажеться, что в вашем случае мне придется бегать по всему проекту в поисках нужного мне контроллера. urls.py удобен тем, что все урлы в одном месте и никак не привязанны к именам апликаций, модулей или вьюх. Что, на мой взгляд, снижает связность и значительно повышает переносимость джанговских апликаций.

Не мелите ерунды. У меня на одном самом дешовом пакета шаред хостинга привязано три домена и крутится соответственно 3 сайта на джанге. И так уже больше 2 лет - полет нормальный. Проекты, конечно, не супер нагруженные, но никакой дэдик для джанги в обязательном порядке не нужен.

>который я не люблю... BFG как и Zope

А можно подробнее?

>Эээ, а стандарт WSGI уже утвердили для python 3? Я всё проспал?
Стандарт стандартом, а реализации великолепно работают на Python3.

>Только ты забыл добавить ) большинство нужных библиотек, которые по сути должны склеивать Pylons и Pyramid - пока не работают в Python 3. Если с шаблонизатором не все так страшно: Jinja2 уже давно спокойно работает на обоих ветках, то тот с ORM пока проблемы )

Да ну? Из чего состоит Pylons:
Mako - великолепно работает.
WebOb - тоже хорошо
Beaker - аналогично хорошо
SQLAlchemy - тоже нету проблем с работой. Были траблы с psycopg но это даже не часть алхимии, всегда можно было использовать pg8000 для подключения к PostgreSQL. К слову теперь и psycopg работает в Python3 https://github.com/dvarrazzo/psycopg .

Так что никаких проблем - дерзайте!

>У меня уже за много лет выработался такой метод изучения чужого кода: смотрю в браузере нужную страничку, смотрю ее урл иду в urls.py и во одном месте определяю какая вьюха занимается отображением этой странички. Потом уже иду во вьюху и изучаю код, а дальше правлю, если надо. Как-то мне кажеться, что в вашем случае мне придется бегать по всему проекту в поисках нужного мне контроллера. urls.py удобен тем, что все урлы в одном месте и никак не привязанны к именам апликаций, модулей или вьюх. Что, на мой взгляд, снижает связность и значительно повышает переносимость джанговских апликаций.

А вы попробуйте. :) Все контроллеры лежат в одном месте, правила вызова экшенов явно прописаны, вам никуда даже смотреть не надо, что бы понять какая функция работает.

>>который я не люблю... BFG как и Zope

А можно подробнее?

Zope за то, что старый и жирный.
BFG - нету контролеров, я люблю ООП (хотя ИМХО BFG гораздо лучше Django). Ну и роутинга нету любимого. :)

Но это уже скорее личный вкус... BFG если надо можно легко перебрать в отличии от Django.

> Он офигенен by design

соглашусь, если добавите «для достаточно узкого круга задач». получить максимум отдачи от использования django можно только используя то, что он предлагает. любые попытки оторвать одно и приделать что-то другое заканчиваются плачевно - от django остаются обломки, которые судорожно пытаются оставаться одним целым. то же самое справедливо и в отношении использования django за пределами этого узкого круга задач - любые попытки выхода из него оборачиваются чрезмерными затратами, которые перевешивают достоинства от использования этого инструмента. особенно ярко и болезненно это проявляется в долгосрочной перспективе, когда из небольшого приложения, которое было легко и красиво реализовано в прошлом, пытаются вырастить нечто большее и сразу же натыкаются на ограничения, накладываемые дизайном django.

> соглашусь, если добавите «для достаточно узкого круга задач»

Если «достаточно узкий круг задач» это «веб» — то да, добавлю.

любые попытки выхода из него оборачиваются чрезмерными затратами

Куда выхода? Из веба? Сломать можно только если ломать MTV, а пока мы в вебе — этого делать нет необходимости. Даже не представляю чего нужно наворотить, чтобы оно вылезло боком.

> Если «достаточно узкий круг задач» это «веб» — то да, добавлю.

если web, для вас, ограничивается cms - то не трудитесь.

Сломать можно только если ломать MTV

если вы используете django, вы не хуже меня знаете, что замена, к примеру, встроенный orm или template engine на что-то другое приводит к превращению MTV django в набор полуработающих компонентов, заставить которые работать вместе как прежде стоит усилий, несопоставимых с выигрышем, полученным от использования django.

> если web, для вас, ограничивается cms - то не трудитесь.

С чего такие выводы?

превращению MTV django в набор полуработающих компонентов

Как замена orm или шаблонизатора может повлиять на MTV? КАК?

> С чего такие выводы?

да «с» того, что django не позволяет, к примеру, написать новый web-интерфейс к существующей базе данных. новаю база, построенная с использованием встроенного orm - пожалуйста, а прицепляться orm django к существующей базе такой гемморой, что ой. а если еще вы используете, скажем, informix, то об этом можно сразу забыть.

Как замена orm или шаблонизатора может повлиять на MTV? КАК?

мы же говорим о MTV в реализации django? тогда покажите мне хоть один пример живого, а не proof of concept, сайта, сделанного на django, но с использованием sqlalchemy в качестве orm. их нет, поскольку подобное, хотя и возможно в принципе, практически нецелесообразно.

> что django не позволяет, к примеру, написать новый web-интерфейс к существующей базе данных

Что значит «не позволяет»? Говорит «не делайте этого, я вам запрещаю»?

использованием sqlalchemy

Могу показать даже сайт сделанный с mongodb в качестве бекенда. На всевозможных конфах докладчики докладывают как сделаны живые сайты на связках django+twisted+rabbitmq+все_что_угодно.

Немного перефразирую вопрос: какая MTV разница от кого наследуются ваши модели, и вообще что они из себя представляют, и какие у них есть методы и т д?

>Zope за то, что старый и жирный.

Вы про Z2? Я все пытаюсь запрыгнуть на Z3. Вот он не жирен. Насчет БФГ у него прямо 2 типа маршрутизации роутинг и траверз. Вот туториал по траверзу: http://docs.repoze.org/bfg/current/tutorials/bfgwiki/index.html Вот туториал по роутингу: http://docs.repoze.org/bfg/current/narr/urldispatch.html

Мне БФГ не нравится, что он почти Zope3. Только открутили кучу всего. В Z3 не нравится билдаут. Иногда зависимости пакетов могут привести к умопомешательству. Но это на больших проектах. Да и не знаю я paste достаточно хорошо чтоб разрулить это все.

Тут кто, то хотел CMS или бложик. Яб подключился на Z3 или BFG

> Что значит «не позволяет»? Говорит «не делайте этого, я вам запрещаю»?

да то и значит, что использовать django orm с уже существующей базой крайне проблематично, а порой, и просто невозможно.

Могу показать даже сайт сделанный с mongodb в качестве бекенда. На всевозможных конфах докладчики докладывают как сделаны живые сайты на связках django+twisted+rabbitmq+все_что_угодно.

я же просил sqlalchemy, а вы мне mongodb, twisted и пр. а вот http://groups.google.com/group/django-sqlalchemy говорит, что это находится в состоянии беты и активность проекта близка к нулю, несмотря на огромный интерес к этому со стороны разработчиков. догадайтесь с трех раз, почему.

> да то и значит, что использовать django orm с уже существующей базой крайне проблематично, а порой, и просто невозможно.

Существующая схема БД конечно может быть весьма своеобразной, но это разве проблема джанги? Есть другие волшебные фреймверки с волшебным ORM который натягивается на любую схему?

что это находится в состоянии беты и активность проекта близка к нулю

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

> так еще и бесполезно.

Точнее, как любят говорить на лоре, не нужно.

> Существующая схема БД конечно может быть весьма своеобразной, но это разве проблема джанги? Есть другие волшебные фреймверки с волшебным ORM который натягивается на любую схему?

не нужно никакой особой «своеобразной» схемы базы, для того, чтобы django orm оказалась бессильной ее отобразить.

Есть другие волшебные фреймверки с волшебным ORM который натягивается на любую схему?

я не берусь утверждать, что любую, но если бы не было более гибких orm, не было бы и потребности в замене django orm на что-либо другое, не правда ли?

вообще, спор с вами меня несколько утомил. думаю, тот, кто хотел, тот меня услышал и понял. а вы склонны прибегать к технике защиты известной как «изнуряй противника бегством».

> не нужно никакой особой «своеобразной» схемы базы, для того, чтобы django orm оказалась бессильной ее отобразить.

Тоесть как это не нужно? Это както толстовато для Анонимуса.

в замене django orm на что-либо другое

Мы говорим не о ORM а о MTV. Джанговское ORM обычно решает на ранних стадиях разработки, либо в enterprise среде. В случае роста нагрузки всё переводится на ту же mongodb например, и с этим нет никаких проблем. Так делают большие дядьки, и не только с джангой. А как делаете Вы?

вообще, спор с вами меня несколько утомил

Ога, ога.

> Да ну? Из чего состоит Pylons: ... Ну из мако и алхимии он точно не состоит, ну ладно. это уже в сторону пустого холивара. Видимо таки давно я не смотрел на их поддержку. Спасибо за инфу. Осталось дождать перехода Werkzeug и Flask на третий Python.

> Могу показать даже сайт сделанный с mongodb в качестве бекенда. На всевозможных конфах докладчики докладывают как сделаны живые сайты на связках django+twisted+rabbitmq+все_что_угодно. Джанга с MongoDB не нужна. Если идти через MongoEngine, или подобное дерьмо притягивающее монгу за уши к SQL - авторам этого софта надо отрывать руки. Если использовать тот же MongoKit, мы остаемся с кучей нерабочих батареек джанги - ни формы не работают с моделями, ни админка, ни пагинация, ни авторизация, список продолжать? Если нужен MongoDB, то тут Django в большом пролете из-за своей как раз таки завязки на компоненты, и гораздо лучше использовать Flask, или Pylons/Pyramid.

> остаемся с кучей нерабочих батареек джанги

И тогда по трудоемкости разработка на джанге становится такой же как и на Flask или PylonsPyramid ок

>И тогда по трудоемкости разработка на джанге становится такой же как и на Flask или PylonsPyramid ок

Вот тут то вы и не правы - Pylons как минимум разрабатывался изначально, что могут быть такие вот серьёзные перестановки в компонентах. Вы видели сколько нужно кода, что бы заменить шаблонизатор в django и сколько в Pylons? Это даже не смешно - это печально.
Аналогично с ORM. В Pylons все компоненты максимально независимы друг от друга и по этому не отваливаются если вы, что то поменяли. Так же тут исповедуется следующая идеология: Мы не пытаемся сделать систему и плагины к ней делающие всё, мы делаем инструмент при помощи которого удобно и быстро можно написать всё, что нам нужно.

По этому трудоёмкость на этих фреймворках и будет ниже по сравнению с Django.

ЗЫ ещё в джанговской ORM не очень удобно сделан коннект сразу к нескольким СУБД и одновременная работа с ними (там это есть, но пользоваться не особо удобно).

А я тут недавно для своего проекта вообще одну фичу написал на gevent. И оказалось крайне удобно. (Основная часть проекта это Pylons)

> Pylons как минимум разрабатывался изначально

Никто не мешает думать о будущем при разработке на django. Мы ж не первый день кодим, думать и предусматривать вроде как умеем. Или нет?

сколько нужно кода, что бы заменить шаблонизатор в django

Вас ввели в заблуждение. Все решается буквально парой строчек. Да и не нужно это, джанговский шаблонизатор весьма шустр и удобен.

> django+twisted+rabbitmq+все_что_угодно.

А какой клиент к раббитmq?

> А какой клиент к раббитmq?

Не припомню я, это на конфе рассказывали.

> Все решается буквально парой строчек. Да и не нужно это, джанговский шаблонизатор весьма шустр и удобен.

вопрос не в том, как просто выдрать стандартный компонент django и подставить другой, а в том, что после этого от django остается только название, т.к. все придется делать вручную. именно об этом я и говорил, и именно от такого вывода вы пытались всячески увиливать.

кстати, вы так и не ответили по-поводу mongodb. это правда, что сказал товарищ, после того, как вы заменили django orm на mongodb, у вас поотвалилось все, включая интеграцию форм с моделью и прочие «сладости» django, без которых он превращается в жалкое подобие pylons?

все придется делать вручную

Ну не то чтобы все, но да, в плане трудоемкости разработки, джанга станет ничем не лучше этих ваших пирамид. Но и не хуже, что вызывает у Анонимуса butthurt который мы здесь наблюдаем.

без которых он превращается в жалкое подобие pylons?

Я бы сказал «в подобие жалкого pylons».

> интеграцию форм с моделью и прочие

Кстати это можно сохранить. Как это сделать — будет Вам домашнее задание))

> Кстати это можно сохранить

закат солнца вручную

> закат солнца вручную

Все равно это менее вручную чем на пилонсах))

> Все равно это менее вручную чем на пилонсах))

а вот это неправда. pylons, как минимум, не делает никаких предположений о том, какие компоненты используются, в отличие от django. соответственно, при использовании pylons, не придется постоянно спотыкаться об обломки того, что было сломано, как в случае с django.

> pylons, как минимум, не делает никаких предположений о том, какие компоненты используются, в отличие от django

Кхм. Это в каком месте джнага делает предположения? Бред какойто.

спотыкаться об обломки того, что было сломано

А не пробовали думать прежде чем ломать?))

А примеры есть? А то одни абстракции. В каком круге задач порекомендуете держаться?