Какие-то совершенно надуманные проблемы. Установка django-приложений совсем не сложная, места их поиска разведаны, вплоть до cms все есть, зависимости простейшие, пишешь все в requirements-файл для pip'a и готово.
В symfony при генерации админки создаюся разные файлы, пишутся настройки всякие, а потом это предлагают править. Так?
В django при генерации создаются классы, необходимые для админки. Не статичные файлы с кодом да диске. В php это принципиально не возможно, т.к. в php нет метаклассов.
Т.е. в django мы имеем не автоматизированный и параметризованный копи-пейст, как обычно это бывает. От созданных джангой классов можно наследоваться, ну и как угодно расширять их функционал.
Ну первый публичный релиз в 2005м — это 8825й внутренний коммит. А делать django начали в 2003. В январе 2004го уже 1000+ коммитов было, по крайней мере. В августе 2004 — 4000+ коммитов. После этого влияние RoR, конечно, было. RoR вообще положительно повлиял на всю веб-разработку. Но насчет следов обольщаться не стоит)
В качестве затравки на очередной холивар: сейчас вот наоборот говорят, что RoR в сторону Django движется)
1) А по-моему так с дебаггингом все отлично. Откройте для себя pdb или ipdb, это проще, чем кажется. Пишете «import ipdb;ipdb.set_trace()» и в консоли, в которой runserver запущен, в точке останова появится дебаггер.
2) Ну с if'ами в 1.2, думаю, разберутся. В 1.х ничто не мешает пользоваться сторинними template-tag'ами: www.djangosnippets.org/snippets/1350/. Если хотите, чтоб он был по умолчанию, напишите
from django.template.loader import add_to_builtins
add_to_builtins('smart_tags.templatetags.smart_if')
Худший случай — вся-вся памяти, которую занимает процесс апача, состоит исключительно из одних указателей.
В этом худшем случае при переходе с 32 бит на 64 потребление памяти увеличится в 2 раза, т.е. процесс апача станет занимать 40 мегабайт, так?
А у Вас, говорите, все 50 мегабайт. Логический вывод: дело не в длине указателей?
Несмотря на то, что астероид был сравнительно небольшим и, по мнению ученых в случае падения на Землю, он бы сгорел в атмосфере, ситуация выглядит тревожной. У американского космического ведомства нет денег на отслеживание угрожающих планете небесных тел. В то же время эксперты НАСА утверждают, что существует порядка 20 тысяч потенциально опасных для Земли астероидов, диаметр которых превышает 140 метров. На то, чтобы их обнаружить до падения на Землю, необходим миллиард долларов. Эти средства пойдут на создание нового наземного телескопа или выведение на орбиту специальной обсерватории. Но Белый дом отказался увеличить бюджет НАСА, предназначенный на отслеживание астероидов в космосе.
Ну так читайте UML-диаграммы, раз хотите. Вопрос генерации кода из них — это совсем другой вопрос, который ведет к другому способу разработки, имеющему (на мой взгляд) значительные недостатки.
Кстати, не совсем по делу, но картинки, чтоб посмотреть структуру моделей, можно сгенерить из этих самых моделей:
Типовые повторяющиеся куски кода можно устранять средствами языка программирования. То же самое и с легкостью модернизации, хороший код легко модернизировать. Ну и хороший код легко читается. Питон достаточно высокоуровневый язык, чтоб писать на нем простой и читаемый код.
А тут мы имеем какую-то сгенерированную жуть.
Наверное, это все какие-то стандартные и ожидаемые доводы против таких штук) В любом случае, для себя лично практической пользы не увидел.
Вместо func_name и func_doc лучше использовать __name__ и __doc__, т.к. эти атрибуты работают со встроенными функциями (что в данном примере не важно), и всем своим видом показывают, что атрибуты это специальные (что в данном примере важно).
Функции help() уделено слишком много внимания) Докстринги — сильно гораздо более полезная, чем просто необходимый минимум для функции help. Например, можно вспомнить доктесты и автогенерацию документации с с помощью sphinx или pydoc. Ну и подсказки в IDE.
> (Этот материал — для начинающих пользователей.)
Начинающие в итоге будут пользоваться чем-то сторонним вместо встроенных в стандартную библиотеку средств, думать, что докстринги — какая-то маловажная ерунда для тех, кто пишет только в консоли, и что имя функции нужно узнавать через func_name.
Но это я так, придираюсь, за то, что тему эту подняли: + )
В другом топике было написано, зачем: чтоб была возможность пускать куда-то только пользователей хабра (достоверно определять, является ли человек пользователем хабра).
Про джоины ерунду пишете. Ну да, джоины — нагрузка на базу, но дергать все по pk отдельными запросами — гораздо большая нагрузка на базу.
Вот когда столкнетесь с реальными проблемами с джоинами (запросы с join'ами будут узким местом при правильно расставленных индексах), а не выдуманными (с чьих-то слов «не рекомендуется»), то уже стоит думать дальше — могут помочь in-запросы со списками id, денормализация или какие-нибудь нереляционные СУБД вроде redis или couchdb. Но в 99% не столкнетесь.
Сейчас же Вы просто свалили на ни в чем не повинный Propel все проблемы, вызванные неправильным использованием реляционной СУБД.
Сразу предупреждаю, с Propel не работал, и мысли тут будут общего плана.
1. Кеширование — важная проблема, но задачи «есть у нас, например, в выборке 20 фоток – получи 20 запросов в базу, чтобы узнать логин автора фотки» решаются join'ами (+ in-запросами), а никак не кешированием. Propel не умеет делать join'ы? Ну если не умеет, тогда его и правда не стоит использовать.
2. Проблемы с различными open-source инструментами лучше всего обсуждать в баг-трекере соответствующих проектов (если есть конкретные замечания) и в списках рассылки (если не знаешь, как сделать правильно). Если инструмент известный, популярный и хорошо написанный, очень часто выясняется, что человек просто как-то неправильно использует инструмент.
3. ORM — не зло. Из того, что что-то неочевидно в каком-то конкретном ORM не следует, что все ORM-зло. У меня, например, очень положительный впечатления от джанговского ORM (который, правда, не совсем и ORM). По поводу Propel опасения из-за жутковатого синтаксиса есть, это да.
4. А вот патчить исходники библиотек, ломая обновлябельность — действительно зло)
В django при генерации создаются классы, необходимые для админки. Не статичные файлы с кодом да диске. В php это принципиально не возможно, т.к. в php нет метаклассов.
Т.е. в django мы имеем не автоматизированный и параметризованный копи-пейст, как обычно это бывает. От созданных джангой классов можно наследоваться, ну и как угодно расширять их функционал.
В качестве затравки на очередной холивар: сейчас вот наоборот говорят, что RoR в сторону Django движется)
2) Ну с if'ами в 1.2, думаю, разберутся. В 1.х ничто не мешает пользоваться сторинними template-tag'ами: www.djangosnippets.org/snippets/1350/. Если хотите, чтоб он был по умолчанию, напишите
from django.template.loader import add_to_builtins
add_to_builtins('smart_tags.templatetags.smart_if')
5) нет
Худший случай — вся-вся памяти, которую занимает процесс апача, состоит исключительно из одних указателей.
В этом худшем случае при переходе с 32 бит на 64 потребление памяти увеличится в 2 раза, т.е. процесс апача станет занимать 40 мегабайт, так?
А у Вас, говорите, все 50 мегабайт. Логический вывод: дело не в длине указателей?
Российская газета
Кстати, не совсем по делу, но картинки, чтоб посмотреть структуру моделей, можно сгенерить из этих самых моделей:
code.google.com/p/django-command-extensions/wiki/GraphModels
code.djangoproject.com/wiki/DjangoGraphviz
Типовые повторяющиеся куски кода можно устранять средствами языка программирования. То же самое и с легкостью модернизации, хороший код легко модернизировать. Ну и хороший код легко читается. Питон достаточно высокоуровневый язык, чтоб писать на нем простой и читаемый код.
А тут мы имеем какую-то сгенерированную жуть.
Наверное, это все какие-то стандартные и ожидаемые доводы против таких штук) В любом случае, для себя лично практической пользы не увидел.
docs.python.org/library/functools.html#functools.wraps
Вместо func_name и func_doc лучше использовать __name__ и __doc__, т.к. эти атрибуты работают со встроенными функциями (что в данном примере не важно), и всем своим видом показывают, что атрибуты это специальные (что в данном примере важно).
Функции help() уделено слишком много внимания) Докстринги — сильно гораздо более полезная, чем просто необходимый минимум для функции help. Например, можно вспомнить доктесты и автогенерацию документации с с помощью sphinx или pydoc. Ну и подсказки в IDE.
> (Этот материал — для начинающих пользователей.)
Начинающие в итоге будут пользоваться чем-то сторонним вместо встроенных в стандартную библиотеку средств, думать, что докстринги — какая-то маловажная ерунда для тех, кто пишет только в консоли, и что имя функции нужно узнавать через func_name.
Но это я так, придираюсь, за то, что тему эту подняли: + )
Вот когда столкнетесь с реальными проблемами с джоинами (запросы с join'ами будут узким местом при правильно расставленных индексах), а не выдуманными (с чьих-то слов «не рекомендуется»), то уже стоит думать дальше — могут помочь in-запросы со списками id, денормализация или какие-нибудь нереляционные СУБД вроде redis или couchdb. Но в 99% не столкнетесь.
Сейчас же Вы просто свалили на ни в чем не повинный Propel все проблемы, вызванные неправильным использованием реляционной СУБД.
1. Кеширование — важная проблема, но задачи «есть у нас, например, в выборке 20 фоток – получи 20 запросов в базу, чтобы узнать логин автора фотки» решаются join'ами (+ in-запросами), а никак не кешированием. Propel не умеет делать join'ы? Ну если не умеет, тогда его и правда не стоит использовать.
2. Проблемы с различными open-source инструментами лучше всего обсуждать в баг-трекере соответствующих проектов (если есть конкретные замечания) и в списках рассылки (если не знаешь, как сделать правильно). Если инструмент известный, популярный и хорошо написанный, очень часто выясняется, что человек просто как-то неправильно использует инструмент.
3. ORM — не зло. Из того, что что-то неочевидно в каком-то конкретном ORM не следует, что все ORM-зло. У меня, например, очень положительный впечатления от джанговского ORM (который, правда, не совсем и ORM). По поводу Propel опасения из-за жутковатого синтаксиса есть, это да.
4. А вот патчить исходники библиотек, ломая обновлябельность — действительно зло)