Вопрос по Django...

from django.shortcuts import render_to_response
import MySQLdb

def book_list(request):
    db = MySQLdb.connect(user='me', db='mydb', passwd='secret', host='localhost')
    cursor = db.cursor()
    cursor.execute('SELECT name FROM books ORDER BY name')
    names = [row[0] for row in cursor.fetchall()]
    db.close()
    return render_to_response('book_list.html', {'names': names})

А еще можно использовать уже существующие БД: http://www.djangoproject.com/documentation/legacy_databases/ .

Спасибо!

А как вообще, стоит переходить на Django?

Какие у тебя задачи, какие приложения пишешь?

Смотря с чего и для чего. Если с PHP или, о ужас, Perl - то стоит, однозначно, даже думать нечего. И неважно Django, TurboGears, Pylons или кто там ещё. Если тяжёлая артиллерия - ASP.NET или Java компания (JSF, Struts, Spring) - то, понятно, масштаб разный и сравнивать их нельзя. Да и не думаю, что может возникнуть такой вопрос. По мне Python, даже как просто язык, в отрыве от web - очень интересная вещь. И Django - просто сказка какая-то. А всё вместе - лучшее, что случилось со мной за последнее время.

> Смотря с чего и для чего > Какие у тебя задачи, какие приложения пишешь?

С Perl, PHP. Задачи/приложения типа интернет магазина с 10 посетителями в секунду.

> 10 посетителями в секунду.

http://www.alrond.com/ru/2007/jan/25/rezultaty-testirovanija-6-frameworks/

Ни в коем разе. На редкость глюкавое, убогое и замысловатое уёжище.

В этом тесте слишком занижены результаты RoR. Смотрите тут http://www.alrond.com/ru/2007/feb/04/dopolnenie-k-test-mvc-frameworks/

+ неизвестно, включал ли автор тестирования production режим. В другом режиме при каждом запросе полностью регенирируется конечный html.

>+ неизвестно, включал ли автор тестирования production режим. В другом режиме при каждом запросе полностью регенирируется конечный html.

http://www.alrond.com/ru/2007/jan/25/rezultaty-testirovanija-6-frameworks/
>>Если фреймворком предусматриваются development и production режимы, то я работал с production.

Хм... тык стоит ли переходить с Perl (Catalyst) на Django (Python)?
Catalyst и Django сейчас активно развиваются...

>Ни в коем разе. На редкость глюкавое, убогое и замысловатое уёжище.
Можно поподробнее?

Спасибо, не углядел про production. Вообщем вот результат изменений в RoR для тех, у кого времени хватает только на просмотр графиков: http://static.alrond.com/results_2test.gif

>Хм... тык стоит ли переходить с Perl (Catalyst) на Django (Python)? Catalyst и Django сейчас активно развиваются...

По ссылке на сайте в комментариях пишут, что выбор инструмента не должен зависеть от какого-то теста на производительность хелловорлда. На реальном коде картина была бы совсем иной, если учитывать характер работы перечисленных фреймворков с БД и прочим.

>>Ни в коем разе. На редкость глюкавое, убогое и замысловатое уёжище.

>Можно поподробнее?

Не обращай внимания - bugmaker пьян :-)

>> Ни в коем разе. На редкость глюкавое, убогое и замысловатое уёжище.

> Можно поподробнее?

Несомненно можно. Что именно интересует?

>>> Ни в коем разе. На редкость глюкавое, убогое и замысловатое уёжище.

>> Можно поподробнее?

> Не обращай внимания - bugmaker пьян :-)

товарищ, Вы неверно расставили акценты и поэтому Ваше сообщение может быть истолковано не совсем правильно теми, кто пока ещё не овладел искуством читать между строк. Для последних расшифрую. Между строк написано: bugmaker не настолько пьян чтобы связыаться с питоном и тем более советовать это другим, особенно учитывая тот факт, что он сам не так давно выбрался из его пасти.

> Можно поподробнее?

Конечно. Глюкодел имеет в виду, что Питон - это не Лисп, и потому сосет. А Django Глюкоделу не нравится по причинам, которые он пока что не хочет излагать.

:D

Всё правильно, кроме одной небольшой детали. Питон даже ещё намного хуже чем нелисп.

Ну во всяком случае чем большинство нелиспов.

> Всё правильно

Дык ёлы-палы, я же старался.

Может, совершишь общественно полезное деяние и изложишь косяки Django, с которыми столкнулся?

Там их слишком много, да я многие уже озвучивал в разных тредах вроде. А разве могут кому-нибудь быть интересны косеки веб-тулкита, в котором нету даже continuations?

> да я многие уже озвучивал в разных тредах вроде.

Я не видел :(

> разве могут кому-нибудь быть интересны косеки веб-тулкита, в котором нету даже continuations?

Ты, наверное, мне не поверишь, но - да, могут 8) Вот анонимному брату интересно, да и мне тоже. Так что - просим!

>> да я многие уже озвучивал в разных тредах вроде.

> Я не видел :(

ИМХО видел, и заметил что это косяки не питона вообще а джанги в частности насколько я помню.

>> разве могут кому-нибудь быть интересны косеки веб-тулкита, в котором нету даже continuations?

> Ты, наверное, мне не поверишь, но - да, могут 8) Вот анонимному брату интересно, да и мне тоже. Так что - просим!

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

> ИМХО видел, и заметил что это косяки не питона вообще а джанги

Дык это было на linux-talks

> Анонимный брат пока не высказался

Он просил подробностей - любых встреченных на практике косяков, я так думаю.

> Самый большой касяк, делающий довольно бессмысленным перечисление остальных оных - это то, что в жданге нету даже continuations.

ОК, зайдем с другой стороны - а в каких фреймворках continuations есть? (кроме лисповых фреймворков, конечно).

>> ИМХО видел, и заметил что это косяки не питона вообще а джанги

> Дык это было на linux-talks

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

>> Анонимный брат пока не высказался

> Он просил подробностей - любых встреченных на практике косяков, я так думаю.

Подробностей много, и, во избежание замусоривания никому не нужной инфой, подождём его мнения о том, какой именно аспект его интересует.

>> Самый большой касяк, делающий довольно бессмысленным перечисление остальных оных - это то, что в жданге нету даже continuations.

> ОК, зайдем с другой стороны - а в каких фреймворках continuations есть? (кроме лисповых фреймворков, конечно).

Почему конечно? Я не пользовался другими и посему не могу знать про это. Достоверно знаю только что в джанге и пилонсе их нету, а в ucw наоборот есть.

> ОК, зайдем с другой стороны - а в каких фреймворках continuations есть? (кроме лисповых фреймворков, конечно).

Сontinuations также есть в смолтолковском Seaside. Но смотри какая штука, вот что пишет о них автор движка: "One thing I’d like to do is reduce the dependence of Seaside on continuations - they drove a lot of the initial interest in the framework but they’re becoming (or seeming) much less important over time, and the use cases to which they’re best suited are these days often addressed with AJAX instead. Right now they’re creating an artificial barrier which stops Seaside from being ported to some dialects (like Strongtalk, Smalltalk/X and VAST) which don’t support continuations but would still benefit from a continuation-less Seaside.”

Так что ценность этой фичи несколько сомнительна. Но даже не принимая это во внимание, ты совершенно напрасно пытаешься говорить с насекомым (bugmaker) на человеческом языке: он ординарный тролль, проследив его ответы в этой ветке, бросается в глаза характерное для опытных троллей пренебрежение к законам формальной логики. Предлагаю оставить его жужжать в одиночестве - ему быстро наскучит унылый и однообразный мотив собственных причитаний, он окуклится и не будет больше постить на лор никогда.

>Анонимный брат пока не высказался, а для тебя отвечу. Самый большой касяк, делающий довольно бессмысленным перечисление остальных оных - это то, что в жданге нету даже continuations.

Правильно, поэтому надо пользоваться ruby on rails :-)

Чудышко анонимное, покажи хоть одно нарушение мной законов формальной логики здесь, или уж закрой дверцу быдлореактора изнутри.

> ты совершенно напрасно пытаешься говорить с насекомым (bugmaker) на человеческом языке: он ординарный тролль

Ты совершенно не прав, анонмный брат. Просто у Глюкодела плохой характер и. похоже, плохое настроение. А человек он явно квалифицированный.

Насчет continuations - то есть в RoR они есть, я правильно понял?

>Насчет continuations - то есть в RoR они есть, я правильно понял?

В ruby есть, называется callcc. Сам сейчас читаю, что за зверь такой.

Я тот Anonymous, который начал thread (не тот, который отвечал до этого).

> Подробностей много, и, во избежание замусоривания никому не нужной инфой, подождём его мнения о том, какой именно аспект его интересует.

Меня в первую очередь интересует стоит ли переходить с Perl на Python в отношении с MVC framewrorks. Я видел много высказываний о том, что у Perl нет будующего и т.п. Однако если верить тому, что обещают в Perl 6, то будующее очень неплохое. И врятли когда-либо Perl окончательно уйдет из MVC (Catalyst сейчас весьма активно развивается).

Python же сейчас быстро набирает обороты, поэтому смотрю в его сторону... Интересует он меня в большой степени применительно к MVC framewrorks. Django показывает очень хорошую эффективность, однако полагаю если граматно настроить кеширование внутри, то особой разницы между Catalyst/Django не будет.

В сторону других языков смотреть не хочется, т.к. Perl как язык меня вполне устраивает.

Я хоть и не специалист по Web MVC-фреймворкам, а всё же отвечу :)

> если верить тому, что обещают в Perl 6, то будующее очень неплохое.

Сколько лет они это обещают? (много) И что реально сделано? (мало)

> Catalyst сейчас весьма активно развивается

> Perl как язык меня вполне устраивает

Тогда не вижу смысла в миграции.

>Тогда не вижу смысла в миграции

Не хочется через пару лет мигрировать по причине того, что Perl не актуален...

> Меня в первую очередь интересует стоит ли переходить с Perl на Python в отношении с MVC framewrorks.

Вопрос перехода очень деликатный и каждый должен решить сам. Потому что много pro&contra завязаны на конкретные условия. Например, если для многих пыпых-кодеров решающим является широкое распространение пыпыха у хостеров, в том числе бесплатных, для многих, в том числе и для мненя это ничегошеньки не решает. Это только один из примеров такого рода факторов. Спектр решаемых задач тоже многое определяет.

> Я видел много высказываний о том, что у Perl нет будующего и т.п.

А у кого оно есть? Мы все умрём, а Лора Палмер так уже, и кому это интересно?

> Однако если верить тому, что обещают в Perl 6, то будующее очень неплохое. И врятли когда-либо Perl окончательно уйдет из MVC (Catalyst сейчас весьма активно развивается).

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

> Python же сейчас быстро набирает обороты, поэтому смотрю в его сторону...

Питон вролне уместно сравнить с бейсиком, он очень похож во многих чертах. Было время, когда на многих персональных компах бейсик был прошит прямо в биос и был самым распространённым наречием. Но из-за присущих недостатов никогда не использовался в сколько-нибудь серьёзных задачах и со временем тихо помер. Так что "набирать обороты" можно по всякому. Это опять таки зависит от решаемых задач.

> Интересует он меня в большой степени применительно к MVC framewrorks. Django показывает очень хорошую эффективность, однако полагаю если граматно настроить кеширование внутри, то особой разницы между Catalyst/Django не будет.

Джанго обладает рядом нелепостей и несуразиц и очень ненадёжен. Многие недостатки происходят от лежащего в основе его питона. Как пример, можно опечататься и использовать где-то в выражении несуществующее свойство объекта. Ошибки это не вызовет но результат работы скрита будет весьма странным и весьма тяжко будет найти эту ашыпку. При изменении модели БД нет (хотя может я не нашёл?) способа применить изменения инкрементально, нужно сностить таблицы и генерить их структуру заново. Для шаблонов страниц используется свой йазыг, такой же нелогичный, скудный и запутанный как сам питон. ИМХО эффективность будет хорошей только на совсем уж незамысловатой логике, а при росте сложности эффективность падёт очень резко. Сколько-нибудь сложную логику на питоне выразить вообще немыслимо, даже ся во всех отношениях (кроме распределения памяти вручную конечно) было бы лучше. Вобщем, о проблемах с питоном вообще и джангой в частности можно рассказывать часами...

> В сторону других языков смотреть не хочется, т.к. Perl как язык меня вполне устраивает.

Ну как хочеш, тебе решать. Многие вообще на висуалвасике работают, и ничего. Перла я не знаю, но думаю что он всё-таки получе висуалвасика будет...

хехе, спасибо на добром слове :) Я был пьян и свиреп, а сейчас я просто свиреп, но харатер у меня просто замечательный. Вы ещё Луговского не видели :P

> Как пример, можно опечататься и использовать где-то в выражении несуществующее свойство объекта. Ошибки это не вызовет но результат работы скрита будет весьма странным и весьма тяжко будет найти эту ашыпку.

Нииипоняааал... Если ты пытаешься читать несуществующее поле - будет тебе исключение. Пытаешься записать несуществующее поле - оно будет создано или (на new-style классе со __slots__) будет тебе исключение. Понятно, что все настоящие мужчины используют new-style классы с тщательно продуманным __slots__ :D

> Сколько-нибудь сложную логику на питоне выразить вообще немыслимо

На этом месте я всегда, всегда плАчу :)

> Питон вролне уместно сравнить с бейсиком... Очень опасное заблуждение..., но достаточно распространённое среди начинающих программировать на Python. Как правило в дальнейшем оно рассеивается.

> Джанго обладает рядом нелепостей и несуразиц... Следствие быстрого роста. Проблема не в надёжности, а в быстром изменении и перекраивании, можно сказать, находу. Т.е., допустим, возможность появилась версию назад, в следующей версии её вдруг не оказалось, а потом появилась вновь с полностью изменённым API. Обещают стандартизировать с версии 1.0...

> Как пример, можно опечататься и использовать где-то в выражении несуществующее свойство объекта. Ну и назови мне скриптовый язык, где это не так? Сравнивать с Java фреймворками - идиотизм. Масштаб не тот. Django рассчитан на разработку быструю, динамичную, небольшой командой или даже одним человеком, а не толпой программистов по формальным методологиям. Плюс эта проблема в значительной степени нивелируется, можно сказать сводится на нет, обязательным модульным тестированием. Что является очень полезной вещью в любом случае.

> ...способа применить изменения инкрементально, нужно сностить таблицы и генерить их структуру заново... И как ты это себе представляешь? Я с трудом...

> Для шаблонов страниц используется свой йазыг... А чей язык там должен быть? Там минимум возможностей поскольку это ШАБЛОН! В идеале-то там кода вообще быть не должно.

> В сторону других языков смотреть не хочется, т.к. Perl как язык меня вполне устраивает. Perl меня тоже вполне устраивал. До тех пор пока я не понял, что код на Python я могу не только писать, но и читать.

> Если ты пытаешься читать несуществующее поле - будет тебе исключение.

нет, не в джанге. Я сам натыкался на такой случай и уже упоминал его при тебе в л-т-т@. Кстати, на этом же канале один из участников однажды жутко матерился из-за того что в питоньей проге (не джанге но тут я думаю роли не играет) по какой-то надобности "if a != False:" и "if a:" работали по разному! Достоверно известно что в переменной a сидело значение логического False. К счастью, с этим чюдесом я работал достаточно мало и настолько немыслимых глюков лично мне наблюдать не доводилось.

> Понятно, что все настоящие мужчины используют new-style классы с тщательно продуманным __slots__ :D

Точно, я давно хотел это сказать но стеснялся. Я тоже подозревал что в написании джанги активно поучаствовали какие-то пассивные ахтунки.

>> Сколько-нибудь сложную логику на питоне выразить вообще немыслимо

> На этом месте я всегда, всегда плАчу :)

да, увы, там есть над чем. Даже элементарную операцию, которая в сях записывается a?b:c, в питоне умудрились сделать чережжёпно.

> Очень опасное заблуждение..., но достаточно распространённое среди начинающих программировать на Python. Как правило в дальнейшем оно рассеивается.

В чём опасное и что его может рассеять?

> Следствие быстрого роста. Проблема не в надёжности, а в быстром изменении и перекраивании, можно сказать, находу. Т.е., допустим, возможность появилась версию назад, в следующей версии её вдруг не оказалось, а потом появилась вновь с полностью изменённым API. Обещают стандартизировать с версии 1.0...

Согласен, но независимо от причин, экстрим слишком велик.

> Ну и назови мне скриптовый язык, где это не так?

Навскидку не скажу. Может и правильно. Но _зачем_ юзать скриптовый язык нескриптовым образом?

> Сравнивать с Java фреймворками - идиотизм. Масштаб не тот.

Согласен.

> Django рассчитан на разработку быструю, динамичную, небольшой командой или даже одним человеком, а не толпой программистов по формальным методологиям.

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

> Плюс эта проблема в значительной степени нивелируется, можно сказать сводится на нет, обязательным модульным тестированием. Что является очень полезной вещью в любом случае.

Тестирование - отнюдь не панацея и заменой грамотного дизайна быть не может. Потому что всех состояний проги по любому не протестируеш и глюки при неправильном цикле разработки будут потом вываливаться самые неожиданные. А проведённое тестирование даст чуство _ложной_ безопасности и ничего более.

> И как ты это себе представляешь? Я с трудом...

Что именно? При добавлении поля в таблицу сделать ALTER TABLE вместо?

> А чей язык там должен быть? Там минимум возможностей поскольку это ШАБЛОН! В идеале-то там кода вообще быть не должно.

Речь не о том, что в шаблон нужно пихать код, а о том что для описания шаблона нужен другой йазыг. Почему нельзя обойтись одним? Зачем два йазыга? По аналогии с количеством йайтс? Их два и йазыга пусть два будет? Другой причины углядеть не могу.

> в питоньей проге (не джанге но тут я думаю роли не играет) по какой-то надобности "if a != False:" и "if a:" работали по разному!

ХЗ, только что проверил - всё работает одинаково.

Дык это же глюк. Когда глючит, а когда и усыпляет бдительность, делает вид что работает. А потом, когда никто не видит...

>Даже элементарную операцию, которая в сях записывается a?b:c, в питоне умудрились сделать чережжёпно.

Дальше можешь не продолжать. всё ясно.

Дык я и не продолжаю. С питоном давно всё ясно.

> В чём опасное и что его может рассеять?

А то что большинство так и остаётся на этом уровне.

> Согласен, но независимо от причин, экстрим слишком велик.

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

> Навскидку не скажу. Может и правильно. Но _зачем_ юзать скриптовый язык нескриптовым образом?

А как надо юзать скриптовый язык? Кстати вполне компилируемый в байт-код. Или есть какие-нибудь детские комплексы по отношению к языкам с динамической типизацией? Боюсь огорчить, если скажу что это будущее всех языков программирования.

> Если задача - хоумпага с парой десятков строк...

Надо сказать, вполне так неплохие хомпаги - http://code.djangoproject.com/wiki/DjangoPoweredSites... прямо ах**ть, какие хомпаги...

> Тестирование - отнюдь не панацея и заменой грамотного дизайна...

Ну а кто тут о дизайне говорил? Ты сказал, что при описке ошибка обнаружится только во время исполнения. Я опровергнул это, заявив что для таких случаев существует модульное тестирование. При таком тестировании тестируются ВСЕ состояния объекта (для этого оно и предназначено) и для выявления ошибок при вызове метода такого тестирования более чем достаточно. Более того, и для компилируемых языков оно будет совсем не лишним... даже обязательным, надо сказать. При чём тут дизайн - я так и не понял. Или "грамотный дизайн" и "правильный цикл разработки" - к таким языкам не относятся никак?

> Что именно? При добавлении поля в таблицу сделать ALTER TABLE вместо?

Усё, кстати говоря, есть - http://code.djangoproject.com/wiki/SchemaEvolution.

> Речь не о том, что в шаблон нужно пихать код, а о том что для описания шаблона нужен другой йазыг. Почему нельзя обойтись одним? Зачем два йазыга? По аналогии с количеством йайтс? Их два и йазыга пусть два будет? Другой причины углядеть не могу.

Зачем? Чтобы получился аналог PHP (блюющий смайлик)? Язык шаблонов был специально сделан с ограничением функциональности. Это сохраняет шаблоны простыми для не программистов (допустим, дизайнеров) и предохраняет программистов от включения бизнес-логики в слой представления. Это очень и очень правильно.

Кстати говоря, вопрос был о том - стоит-ли переходить с Perl - Catalyst на Python + Django. И заметь - большинство претензий, выдвинутых против Python распространяются на все скриптовые языки и на 200% относятся к Perl. Я честно скажу, не видел Catalyst, но достаточно работал с Perl и я очень люблю Perl (как-никак он есть мой первый язык программирования), но Python лучше. Чем лучше? Чем Perl, разумеется!...

>> В чём опасное и что его может рассеять?

> А то что большинство так и остаётся на этом уровне.

кто не хочет - выбирает другой язык, только и всего

>> Согласен, но независимо от причин, экстрим слишком велик.

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

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

>> Навскидку не скажу. Может и правильно. Но _зачем_ юзать скриптовый язык нескриптовым образом?

> А как надо юзать скриптовый язык?

Для скриптов. Сценариев. Баш скрипты видел?

> Кстати вполне компилируемый в байт-код.

Зачем вообще скриптовый язык компилить куда-то?

> Или есть какие-нибудь детские комплексы по отношению к языкам с динамической типизацией?

А причём тут типизация?

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

Машина времени у тебя, тебе видней.

>> Если задача - хоумпага с парой десятков строк...

> Надо сказать, вполне так неплохие хомпаги

И что? Это доказывает что на чём-то другом было бы сделано медленнее и хуже?

>> Тестирование - отнюдь не панацея и заменой грамотного дизайна...

> Ну а кто тут о дизайне говорил? Ты сказал, что при описке ошибка обнаружится только во время исполнения.

Нет, наоборот. Я указал на ошибку, которая может быть пропущена даже во время исполнения. В определённых ситуациях обращение к несуществующему не вызывает ексепшна, если ты забыл о чём там была речь. А дизайн обязан обеспечивать должные средства для выявления нештатных ситуаций.

> Я опровергнул это, заявив что для таких случаев существует модульное тестирование. При таком тестировании тестируются ВСЕ состояния объекта (для этого оно и предназначено) и для выявления ошибок при вызове метода такого тестирования более чем достаточно.

При определённой сложности (не объёме!) кода трудозатраты на такого рода тестирование будут значительно превышать трудозатраты на саму разработку. Оно нам надо?

>> Что именно? При добавлении поля в таблицу сделать ALTER TABLE вместо?

> Усё, кстати говоря, есть - http://code.djangoproject.com/wiki/SchemaEvolution.

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

>> Речь не о том, что в шаблон нужно пихать код, а о том что для описания шаблона нужен другой йазыг. Почему нельзя обойтись одним? Зачем два йазыга? По аналогии с количеством йайтс? Их два и йазыга пусть два будет? Другой причины углядеть не могу.

> Зачем? Чтобы получился аналог PHP (блюющий смайлик)? Язык шаблонов был специально сделан с ограничением функциональности.

Как ты наверное знаеш, в пхп-разработке используются тоже два языка единовременно: html и сам язык php. Вот и получился фактически аналог пхп (блюющий смайлик).

> Это сохраняет шаблоны простыми для не программистов (допустим, дизайнеров)

Зачем дизайнерам шаблоны ваще? Или дизайнеров, не ведающих что дизайнить нужно при помощи css, ещё не всех отстреляли?

> и предохраняет программистов от включения бизнес-логики в cлой представления.

Почему же не наложить в определённых местах ограничения на существующий язык, а изобретать обязательно новый?

> Это очень и очень правильно.

Совсем не это правильно. Определённая часть логики неразрывно связана с "представлением", ибо непосредственно участвует в валидации полей ввода, реакции на конкретные кнопки тырфейса итд. Если пытаться тупо отделить например кнопку или поле ввода от кода, обрабатывающего их значения или события, затем появляется связующий код, всякая дополнительная фигня в urls.py и протчая и протчая, раскиданное по куче файлов. Компонентная модель как минимум локализует отдельную ссущность в конкретном месте, и описывает одним языком, а не размазывает по куче файлов, записаных стмя разными наречиями.

> Кстати говоря, вопрос был о том - стоит-ли переходить с Perl - Catalyst на Python + Django.

Я не знаю ни перла ни каталиста, но нечто более скверное чем питоноджанга, могу представить с большим трудом. Так что в _лучем_ случае ИМХО переход с откудато на джангу, как гласит народная мудрость "хер на хер менять - только время терять"

> И заметь - большинство претензий, выдвинутых против Python распространяются на все скриптовые языки

Дык если задача такова, что скриптового языка для её решения вполне достаточно, что тут обсуждать? Скриптовые для того и придуманы чтобы ради примитивных дел не напрягать чё не нужно и самому лишний раз не напрягаться. Беспокоит одно. Почему-то зачастую делается вывод, что если например скриптовый язык хшё справляется со своей задачей, то и с более сложной, для которой предназначен совсем не он, справится не хуже. Как бы не получилось засилье питона на хостингах, подобное теперешней ситуации с пхп.

bugmaker, вопрос к тебе. Ты писал на python/django что-нибудь?

> При определённой сложности (не объёме!) кода трудозатраты на такого рода тестирование будут значительно превышать трудозатраты на саму разработку. Оно нам надо?

А ты вообще с методологиями разработки знаком немного? Ну хоть чуть-чуть? Прям совсем маленько? Сочувствую...

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

Аха, у ананимуса кончились аргументы и ананимус решил прибегнуть к древнему как мир приёму, задрать нос и гордо удалиться с бормотанием "да что вы понимаете млин..." :D