Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
А вы говорили на devconf.ru: «Где 1.2?» А вот!!!
Эх, скорее бы уже Django для Python 3…
А есть смысл? Или просто ради художественной завершенности композиции? Ведь придется ждать обновления всех тех штук, которые есть для Джанго. И свои приложения адаптировать нужно будет.
А у меня нет ещё на Питоне своих приложений, которые надо адаптировать и какого бы то ни было опыта разработки на этом языке. Тем временем я всё больше и больше к нему присматриваюсь. А начинать что-то с нуля, ясное дело, хочется на свежайшей версии, т.к. отсутствие необходимости поддержки старого кода позволяет использовать современные фичи на всю катушку, а ориентация на будущее делает предпочтительным использовать свежайшие, «bleeding edge», что называется, технологии чтобы избежать скорого устаревания наработок. Python 2.6 сейчас, как я понимаю, на пике, и дальше ему дорога только вниз, в пользу 3-й ветки.
Вообще-то разница между Python 2.x и Python 3.x не такая же, как в случае с php4 и php5.
Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2. Не думаю, что Django все это требуется. А сопутствующий гемор, связанный с пересмотром многих алгоритмов — не совсем то, ради чего создавалась Django.
Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2. Не думаю, что Django все это требуется. А сопутствующий гемор, связанный с пересмотром многих алгоритмов — не совсем то, ради чего создавалась Django.
> Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2.
Так это же отлично! :-) Я как рас сейчас это подход наконец распробовал и более-менее понял, восторг еле сдерживаю…
Так это же отлично! :-) Я как рас сейчас это подход наконец распробовал и более-менее понял, восторг еле сдерживаю…
ну это всё доступно и питоне 2, в стандартных модулях типа itertools, functools и т.п.
джангу совсем не сложно сложно перевести на питон 3(заставить работать её и на 2-м и на 3-без разделения на 2 ветки — тожн рельно). Просто пока смысла в этом нет — для питона 3 ещё нет и питоновских модулей многих нужных, например, PIL
джангу совсем не сложно сложно перевести на питон 3(заставить работать её и на 2-м и на 3-без разделения на 2 ветки — тожн рельно). Просто пока смысла в этом нет — для питона 3 ещё нет и питоновских модулей многих нужных, например, PIL
>Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2.
Щито? Не курите больше, ок?
Щито? Не курите больше, ок?
Кстати, одно из самых приятных обновлений — это --failfast
Теперь и работа чуть быстрее будет.
Теперь и работа чуть быстрее будет.
Ну не знаю. На мой взгляд, польза этой фишки довольно сомнительна. Если какой-то тесткейс фейлится, не проще ли запустить именно его не дожидаясь, пока пройдут другие?
Так в том то и все дело. Запустились тесты гжде-нибудь на тестовом сервере, и как только сфейлилось — сразу останов тестов, и получаешь репорт о проблеме. А не ждёшь когда всё пройдёт, или следишь всё время…
У нас, видимо, разные подходы к разработке. Я стараюсь писать тесты и, соответственно, запускать по одному: написание теста, реализация, запуск. Когда итерация заканчивается, пишу следующий и так далее.
А после того, как написаны все тесты, можно запустить пачку целиком. Все тесты должны проходить в силу независимости тестов друг от друга. Если не проходят — то это уже человеческий фактор, где-то напутал с логикой. В любом случае, чаще одного-двух раз запускать все наборы не приходится.
А после того, как написаны все тесты, можно запустить пачку целиком. Все тесты должны проходить в силу независимости тестов друг от друга. Если не проходят — то это уже человеческий фактор, где-то напутал с логикой. В любом случае, чаще одного-двух раз запускать все наборы не приходится.
А чем круче писать на Django нежели например на C# или PHP?
Что концептуально нового?
Что концептуально нового?
Django стал языком программирования?
Или Вы просто «не в теме»?
Или Вы просто «не в теме»?
> Django стал языком программирования?
Django на сколько мне известно это каркас. А любой каркас как и язык программирования
предоставляет какие-то идею (например, MVC). Так вот мой вопрос собственно про то что
концептуально нового и интересного в Django? Из-за чего он лучше альтернатив на других
языках?
> Или Вы просто «не в теме»?
Наверное просто не знаю более одного каркаса для C#, а их много?
Ну с PHP еще можно сказать, что тройка-пятерка наберется…
P.S. За замечание насчет языков спасибо, но все таки что там такого? В чем изюминка?
Django на сколько мне известно это каркас. А любой каркас как и язык программирования
предоставляет какие-то идею (например, MVC). Так вот мой вопрос собственно про то что
концептуально нового и интересного в Django? Из-за чего он лучше альтернатив на других
языках?
> Или Вы просто «не в теме»?
Наверное просто не знаю более одного каркаса для C#, а их много?
Ну с PHP еще можно сказать, что тройка-пятерка наберется…
P.S. За замечание насчет языков спасибо, но все таки что там такого? В чем изюминка?
Если вы ипользуете PHP, то самое близкое сравнение — Симфония. В Джанго есть классные средства для быстрого написания чистых, удобных, расширяемых сайтов. Хороший встроенный урл-роутер, хорошая модульная система, хороший встроенный орм и система миграций (правда, не встроенная, но подключающаяся парой строчек). Изюминка выражена общим девизом фреймворка: «for perfectionsts with deadlines».
Проиллюстрирую.
пример из туториала symfony 1.4 (Doctrine):
как бы этот код был написан в django:
пример из туториала symfony 1.4 (Doctrine):
$this->job = Doctrine::getTable('JobeetJob')-> find($request->getParameter('id'));
$this->forward404Unless($this->job);
как бы этот код был написан в django:
job = get_object_or_404(Job, id)
jobs = JobeetJob.objects.filter(id=request.GET['id'])
вот так получают сет с результатами.
Фишка в том, что JobeetJob описан ранее в маппинге для ORM, поэтому к нему можно обращаться напрямую.
вот так получают сет с результатами.
Фишка в том, что JobeetJob описан ранее в маппинге для ORM, поэтому к нему можно обращаться напрямую.
пара моментов:
Во-первых, вполне можно делать модель Job вместо JobeetJob, т.к. в питоне есть удобные неймспейсы и дублировать их в наименованиях классов — как-то неправильно (в отличие от php, где, как я понял, это общепринятая практика и введение неймспейсов ничего не изменило, по большому счету).
Во-вторых, общепринятая практика id в таких случаях получать все-таки из url (/jobs/5/), а не из GET-параметров. Чище как-то, и проще. Поэтому будет что-то вроде def my_view(request, id) и request.GET['id'] писать не придется.
Т.е. имеем все-таки что-то вроде jobs = Job.objects.filter(id=id)
Так-то на такой случай вообще вьюху можно не писать, т.к. есть object_detail)
Во-первых, вполне можно делать модель Job вместо JobeetJob, т.к. в питоне есть удобные неймспейсы и дублировать их в наименованиях классов — как-то неправильно (в отличие от php, где, как я понял, это общепринятая практика и введение неймспейсов ничего не изменило, по большому счету).
Во-вторых, общепринятая практика id в таких случаях получать все-таки из url (/jobs/5/), а не из GET-параметров. Чище как-то, и проще. Поэтому будет что-то вроде def my_view(request, id) и request.GET['id'] писать не придется.
Т.е. имеем все-таки что-то вроде jobs = Job.objects.filter(id=id)
Так-то на такой случай вообще вьюху можно не писать, т.к. есть object_detail)
from django.http import Http404
#…
def detail(request, poll_id):
try:
p = Poll.objects.get(pk=poll_id)
except Poll.DoesNotExist:
raise Http404
return render_to_response('polls/detail.html', {'poll': p})
Это полностью работающий view.
Взято отсюда: docs.djangoproject.com/en/dev/intro/tutorial03/
Там же объяснения и еще несколько примеров кода.
#…
def detail(request, poll_id):
try:
p = Poll.objects.get(pk=poll_id)
except Poll.DoesNotExist:
raise Http404
return render_to_response('polls/detail.html', {'poll': p})
Это полностью работающий view.
Взято отсюда: docs.djangoproject.com/en/dev/intro/tutorial03/
Там же объяснения и еще несколько примеров кода.
Это туториал чтобы понять основы, в реальной жизни столько кода писать не нужно)
ну или object_detail
def detail(request, poll_id)
poll = get_object_or_404(Poll, poll_id)
return direct_to_template('polls/detail.html', {'poll': poll}
ну или object_detail
человеку, спрашивавшему «в чем изюминка» вызов get_object_or_404 ничего не скажет =) На пыхе такой метод тоже можно забацать, запихав в нутро всяких вызовов доктрин =)
Если уж поднимать тему удобных хелперов:
правда render_to уже не коробочное решение
@render_to('polls/detail.html')
def detail(request, poll_id)
return { 'poll' : get_object_or_404(Poll, poll_id) }
правда render_to уже не коробочное решение
Еще видел вариант:
Не знаю правда, насколько в нем много подводных граблей.
@render_to('polls/detail.html')
def detail(request, poll_id)
poll = get_object_or_404(Poll, poll_id)
return locals()
Не знаю правда, насколько в нем много подводных граблей.
откройте для себя generic_view, чтобы не писать двухстрочные вьюшки.
locals() — это PHP-стиль: «А давайте забабахаем все в template, авось что-нибудь, да пригодится»
Отсюда и дыры в безопасности и вообще гадливое впечатление от PHP. Посмотрите, сколько ненужной и потенциально опасной информации ваш locals передает в шаблон.
Отсюда и дыры в безопасности и вообще гадливое впечатление от PHP. Посмотрите, сколько ненужной и потенциально опасной информации ваш locals передает в шаблон.
Не все то, что «разжовывается» в туториале является конечным кодом, который стоит сравнивать с другими.
Тот кусок symfony-кода, что вы описали на практике почти всегда разбивается на правильный «DoctrineRoute» и однострочный контроллер, благодаря чему этот код Django:
является альтернативой этому коду symfony:
который автоматом будет кидать 404 в случае отсутствия объекта.
Идеология простая — если объект получается на основе роута, то почему бы его и не получать на основе этого роута? +)
Тот кусок symfony-кода, что вы описали на практике почти всегда разбивается на правильный «DoctrineRoute» и однострочный контроллер, благодаря чему этот код Django:
job = get_object_or_404(Job, id)
является альтернативой этому коду symfony:
$this->job = $this->getRoute()->getObject();
который автоматом будет кидать 404 в случае отсутствия объекта.
Идеология простая — если объект получается на основе роута, то почему бы его и не получать на основе этого роута? +)
Не в обиду c# будет сказано, но python — значительно более приятный и мощный язык, нежели php и c#, с богатой стандартной библиотекой, ясной идеологией и кучей готовых решений. C# еще понимаю — удобная IDE, выше производительность за счет статической типизации + для многих — легкий переход из десктопа в веб, но вот почему люди пишут серьезные вещи на php, а не на python/ruby — ничем кроме привычки объяснить не могу.
Смотрел как-то на хабре скринкаст о том, как делали приложение на ASP.NET — обертка над оберткой над оберткой, куча паттернов, IoC контейнеры и тд. Причем половину этих паттернов можно было бы выкинуть, если бы C# поддерживал динамическую типизацию, а еще четверть — исходя из принципа KISS. На питоне так никто не пишет — обычно там выходят просто небольшие независимые части, часто даже в процедурном стиле. Код, написанный в таком стиле, проще понимать и изменять.
Питон хорош тем, что устраняет необходимость думать по мелочам (обычно самый эффективный код — самый понятный и короткий), не приветствует трюкачество и архитектурную астронавтику, разгружает голову, и из-за этого оказывается проще взглянуть на свой код «свысока».
Смотрел как-то на хабре скринкаст о том, как делали приложение на ASP.NET — обертка над оберткой над оберткой, куча паттернов, IoC контейнеры и тд. Причем половину этих паттернов можно было бы выкинуть, если бы C# поддерживал динамическую типизацию, а еще четверть — исходя из принципа KISS. На питоне так никто не пишет — обычно там выходят просто небольшие независимые части, часто даже в процедурном стиле. Код, написанный в таком стиле, проще понимать и изменять.
Питон хорош тем, что устраняет необходимость думать по мелочам (обычно самый эффективный код — самый понятный и короткий), не приветствует трюкачество и архитектурную астронавтику, разгружает голову, и из-за этого оказывается проще взглянуть на свой код «свысока».
«Причем половину этих паттернов можно было бы выкинуть, если бы C# поддерживал динамическую типизацию»
Для некоторых целей лучше как раз иметь статический анализ. Не для сайтов, для groupware.
Для некоторых целей лучше как раз иметь статический анализ. Не для сайтов, для groupware.
> трюкачество и архитектурная астронавтика
Хорошо сказал! (:
Хорошо сказал! (:
Это цитата Джоэла Спольски. Как-то так:
«Иногда умные мыслители просто не знают, когда остановится, и создают весь этот абсурд, всеохватывающие высокоуровневые картины Вселенной, которые хороши и точны, но вообще ничего не значат. Этих людей я называю Архитектурными Астронавтами. Очень сложно убедить их написать код или спроектировать программу, потому что они не могут прекратить думать об Архитектуре.»
«Иногда, когда вы работаете в команде, и трахаетесь с кодом, и кто-то подходит прямо к твоему столу с кружкой кофе в руках, и начинает возбуждаться… И ваши глаза закатываются, и нет ни одной долбаной идеи, о чем говорит это аццки двинутый человек,… и он вот-вот и взорвется как сумасшедший, и вы уже готовы к тому, что вас позовут вечером прийти на какую-нибудь проклятую сходку, посвященную „паттернам проектирования“.
(скопипастал из своего перевода интервью с Гради Бучем вот отсюда: olegchir.livejournal.com/2779.html?nc=17(
«Иногда умные мыслители просто не знают, когда остановится, и создают весь этот абсурд, всеохватывающие высокоуровневые картины Вселенной, которые хороши и точны, но вообще ничего не значат. Этих людей я называю Архитектурными Астронавтами. Очень сложно убедить их написать код или спроектировать программу, потому что они не могут прекратить думать об Архитектуре.»
«Иногда, когда вы работаете в команде, и трахаетесь с кодом, и кто-то подходит прямо к твоему столу с кружкой кофе в руках, и начинает возбуждаться… И ваши глаза закатываются, и нет ни одной долбаной идеи, о чем говорит это аццки двинутый человек,… и он вот-вот и взорвется как сумасшедший, и вы уже готовы к тому, что вас позовут вечером прийти на какую-нибудь проклятую сходку, посвященную „паттернам проектирования“.
(скопипастал из своего перевода интервью с Гради Бучем вот отсюда: olegchir.livejournal.com/2779.html?nc=17(
Мне показалось, что многие предпосылки у Вас неверные, поэтому и выводы не в ту сторону идут.
И python, и ruby старше php. Для них написано больше хороших библиотек, чем для php (ну уж точно не меньше). Залезьте хотя бы на github. Активных, хорошо развивающихся и поддерживаемых проектов на python и ruby больше, чем на php. За ними стоят «большие» компании, для которых эти языки являются основополагающими — гугл уж явно не меньше, чем зенд. Эти языки уже давно тут, это давно уже промышленные языки, а не новомодные поветрия, они точно никуда не денутся в обозримом будущем. Во многих дистрибутивах linux python ставится по умолчанию (а php — не во многих).
Аргументы насчет «все развалится» скорее применим к php-фреймворкам. Вот начну я писать сейчас на Yii, все развалится. А у джанги с рельсами — пятилетняя+ история. Это огромный срок по нынешним меркам. На php все пытаются догнать-скопировать рельсы (и в меньшей степени — джангу), но все скопировать не выходит — ограничения языка неизбежно приводят к уродливому API, и того же легкого ощущения, как на джанге-рельсах, достигнуть не удается. Никто не переходит обратно с джанги/рельс на тот же симфони, хотя симфони — отличный фреймворк.
Насчет потребления памяти и монструозности — на vds за 20 баксов можно спокойно разместить пару десятоков джанго-сайтов, причем они будут чувствовать себя отлично. Тут, например, нет идиотской проблемы php-фреймворков — «собирать файлы в 1 или не собирать?», которая вызвана тем, что почему-то на php как-то принято все приложение перезагружать при каждом запросе — и, соответственно, делать все эти импорты. Да, и решают это костылями в виде опкод-кешеров вместо того, чтобы работать хотя бы по идеологии fastcgi. По крайней мере, так было, когда я бросил php пару лет назад, может сейчас что и поменялось.
Аргументы в духе «тормозит, жрет память, монстр» перед выбором технологии гораздо чаще имеют психологическую основу, а не реальную техническую. Я не имею точных данных по рельсам, т.к. на них не писал, но процесс довольно сложного сайта на джанге с кучей встроенных приложений занимает порядка 20мб. Это не является проблемой.
PHP стал так популярен из-за того, что начинать писать на нем просто. Человек делает сайт на html, потом думает — а как бы сделать так, чтобы вот новости обновлялись — а ему в ответ: очень просто, ставь mod_php и пиши <? php… ?>. Минимум телодвижений, не обязательно даже особо программировать уметь. И на этой волне потом пошел снежный ком, вот и все. Человек думает «хочу программировать веб». Если он до этого писал на C#, то ответ — ASP.NET. Если на чем-то другом — php (т.к. есть куча книг и тд, первое что слышишь — php).
Мой опыт: олимпиады, потом писал на C++ вейвлет-преобразования всякие и 3d-графику, немного геймдева, потом перешел в веб — и начал, конечно, с php (с чего еще-то), убил на него лет 5 (или сколько там), растеряв по пути половину своих навыков программиста (сам виноват, конечно), пока не прекратил это топтание на месте и не перешел на python+django (спасибо огромное «кризису» за то, что было больше свободного времени, чем обычно).
Т.е. техническая причина есть — легкость вхождения. Есть смысл использовать php для очень простых вещей, он очень хорошо для этого подходит — минимум усилий и готово. Но с чуть более сложными вещами, чем сайт-визитка, тот же python+django справляется значительно элегантнее.
Причина «сложнее найти работника», впрочем, разумная. Она не техническая, это просто нынешняя ситуация, но такая причина есть. Другое дело, что это все-таки преувеличение, и вообще все уходит в прошлое. На нормальную вакансию python-программиста в 2010 году откликаются десятки человек, и это не Москва, а Екатеринбург. Да и самим python-программстам вполне есть из чего выбирать. Даже у нас в городе есть несколько фирм, пишущих на python — а если где-то не так, то фриланс-удаленку-стартапствование никто не запрещал.
И python, и ruby старше php. Для них написано больше хороших библиотек, чем для php (ну уж точно не меньше). Залезьте хотя бы на github. Активных, хорошо развивающихся и поддерживаемых проектов на python и ruby больше, чем на php. За ними стоят «большие» компании, для которых эти языки являются основополагающими — гугл уж явно не меньше, чем зенд. Эти языки уже давно тут, это давно уже промышленные языки, а не новомодные поветрия, они точно никуда не денутся в обозримом будущем. Во многих дистрибутивах linux python ставится по умолчанию (а php — не во многих).
Аргументы насчет «все развалится» скорее применим к php-фреймворкам. Вот начну я писать сейчас на Yii, все развалится. А у джанги с рельсами — пятилетняя+ история. Это огромный срок по нынешним меркам. На php все пытаются догнать-скопировать рельсы (и в меньшей степени — джангу), но все скопировать не выходит — ограничения языка неизбежно приводят к уродливому API, и того же легкого ощущения, как на джанге-рельсах, достигнуть не удается. Никто не переходит обратно с джанги/рельс на тот же симфони, хотя симфони — отличный фреймворк.
Насчет потребления памяти и монструозности — на vds за 20 баксов можно спокойно разместить пару десятоков джанго-сайтов, причем они будут чувствовать себя отлично. Тут, например, нет идиотской проблемы php-фреймворков — «собирать файлы в 1 или не собирать?», которая вызвана тем, что почему-то на php как-то принято все приложение перезагружать при каждом запросе — и, соответственно, делать все эти импорты. Да, и решают это костылями в виде опкод-кешеров вместо того, чтобы работать хотя бы по идеологии fastcgi. По крайней мере, так было, когда я бросил php пару лет назад, может сейчас что и поменялось.
Аргументы в духе «тормозит, жрет память, монстр» перед выбором технологии гораздо чаще имеют психологическую основу, а не реальную техническую. Я не имею точных данных по рельсам, т.к. на них не писал, но процесс довольно сложного сайта на джанге с кучей встроенных приложений занимает порядка 20мб. Это не является проблемой.
PHP стал так популярен из-за того, что начинать писать на нем просто. Человек делает сайт на html, потом думает — а как бы сделать так, чтобы вот новости обновлялись — а ему в ответ: очень просто, ставь mod_php и пиши <? php… ?>. Минимум телодвижений, не обязательно даже особо программировать уметь. И на этой волне потом пошел снежный ком, вот и все. Человек думает «хочу программировать веб». Если он до этого писал на C#, то ответ — ASP.NET. Если на чем-то другом — php (т.к. есть куча книг и тд, первое что слышишь — php).
Мой опыт: олимпиады, потом писал на C++ вейвлет-преобразования всякие и 3d-графику, немного геймдева, потом перешел в веб — и начал, конечно, с php (с чего еще-то), убил на него лет 5 (или сколько там), растеряв по пути половину своих навыков программиста (сам виноват, конечно), пока не прекратил это топтание на месте и не перешел на python+django (спасибо огромное «кризису» за то, что было больше свободного времени, чем обычно).
Т.е. техническая причина есть — легкость вхождения. Есть смысл использовать php для очень простых вещей, он очень хорошо для этого подходит — минимум усилий и готово. Но с чуть более сложными вещами, чем сайт-визитка, тот же python+django справляется значительно элегантнее.
Причина «сложнее найти работника», впрочем, разумная. Она не техническая, это просто нынешняя ситуация, но такая причина есть. Другое дело, что это все-таки преувеличение, и вообще все уходит в прошлое. На нормальную вакансию python-программиста в 2010 году откликаются десятки человек, и это не Москва, а Екатеринбург. Да и самим python-программстам вполне есть из чего выбирать. Даже у нас в городе есть несколько фирм, пишущих на python — а если где-то не так, то фриланс-удаленку-стартапствование никто не запрещал.
Мне кажется, можно выбрать любой вариант и не прогадать. Разница в том, что для монстров (django, rails) будет куча информации, кода и устоявшиеся представления о best practices, а на штуках вроде werkzeug можно собирать свой конструктор как угодно. Это не вопрос гибкости (и на том, и на другом можно написать что угодно), это вопрос того, совпадает ли идеология фреймворка с представлениями конкретного программиста о том, как следует организовывать разработку. Если четких представлений нет, то imho лучше выбрать что-то большое, разобраться хорошенько, и только потом уже думать о «конструкторах» — в случае, если не понравится.
Насчет джанги — тут ситуация, по моему мнению, классическая для всех «больших» проектов: 5% недовольных (вероятно, имеющих на это свои причины) создают 95% шума, поэтому стороннему наблюдателю по обсуждениям будет казаться, что шаблоны и ORM — отстой и их обязательно нужно на что-то менять, хотя на самом деле это не так.
Мне, например, наоборот, джанговский ORM нравится тем, что он имеет простой API, не ставит целью повторно изобрести sql, а в особо сложных случаях поддерживает откат к голому sql и конструирование объектов из результатов выполнения «голых» запросов. Хотя за все время ни разу этим пользоваться так и не приходилось, всегда базовых возможностей хватало. Шаблоны тоже устраивают — как синтаксисом, так и скоростью. Скорость шаблонов, которая в 1.1 могла, в принципе, стать проблемой ну в 5% проектов, в 1.2 сильно выросла к тому же.
Проблемы с памятью и тормозами обычно вызваны неверными настройками сервера. Типичные проблемы при развертывании django, которые приводят к таким fail'ам: vds на OpenVZ/Virtuozzo, включенный в продакшне DEBUG или включенный mod_php одновременно с mod_wsgi. Насчет рельс, правда, не в курсе, ничего сказать не смогу, но openVZ должен быть проблемой и там.
Насчет джанги — тут ситуация, по моему мнению, классическая для всех «больших» проектов: 5% недовольных (вероятно, имеющих на это свои причины) создают 95% шума, поэтому стороннему наблюдателю по обсуждениям будет казаться, что шаблоны и ORM — отстой и их обязательно нужно на что-то менять, хотя на самом деле это не так.
Мне, например, наоборот, джанговский ORM нравится тем, что он имеет простой API, не ставит целью повторно изобрести sql, а в особо сложных случаях поддерживает откат к голому sql и конструирование объектов из результатов выполнения «голых» запросов. Хотя за все время ни разу этим пользоваться так и не приходилось, всегда базовых возможностей хватало. Шаблоны тоже устраивают — как синтаксисом, так и скоростью. Скорость шаблонов, которая в 1.1 могла, в принципе, стать проблемой ну в 5% проектов, в 1.2 сильно выросла к тому же.
Проблемы с памятью и тормозами обычно вызваны неверными настройками сервера. Типичные проблемы при развертывании django, которые приводят к таким fail'ам: vds на OpenVZ/Virtuozzo, включенный в продакшне DEBUG или включенный mod_php одновременно с mod_wsgi. Насчет рельс, правда, не в курсе, ничего сказать не смогу, но openVZ должен быть проблемой и там.
Честно говоря, на wiki хорошо описано для ознакомления в общих чертах. Если непонятно, то скорее всего, Вам не приходилось сталкиваться с подобными задачами.
Касательно PHP, внесу свою лепту в ответ немного с другой стороны — почти все джангисты, которых я знаю, перешли на Python+Django с PHP+что-то.
И я не слышал ни об одном джангисте, который перешел на PHP, более того, я уверен, что таких не существует.
В ощущениях это проявлется так, что PHP-прошлое вспоминается как страшный сон с сопутствующим впечатлением, что тебя все эти годы обманывали, скрывая прекрасный совершенный мир за стеной :-)
И я не слышал ни об одном джангисте, который перешел на PHP, более того, я уверен, что таких не существует.
В ощущениях это проявлется так, что PHP-прошлое вспоминается как страшный сон с сопутствующим впечатлением, что тебя все эти годы обманывали, скрывая прекрасный совершенный мир за стеной :-)
причем на пхп есть нормальные фреймворки, CI, Yii и др., но подавляющее большинство пхп-программеров о них не знают и по старинке пишут аццкие рид-онли портянки из смеси хтмл+пхп (как и я несколько лет назад)).
все встреченные мной перешедшии c php неслышали никогда про фрэймворки и занимались быдлокодингом :) неудивительно что им снятся страшные сны
соответствено использующии php фрэймворки программисты не ведутся на красивые проспекты и не бегают взад вперед :)
соответствено использующии php фрэймворки программисты не ведутся на красивые проспекты и не бегают взад вперед :)
почемуто никто не вспомнил о том что питон+джанго работает в разы быстрее чем пхп+симфони(или другие фреймворки). естественно если сравнивать на одинаковом железе. И еще все что написано на питоне намного проще интегрировать с ОС(nix)
Товарищи… Я разгневан шквалом ваших минусов…
Уважаемая минусующая часть хабра. Обоснуйте свои
минусы… Из-за чего в топике про Django и вопрос о
выходе новой джанги вы ставите минусы??? Обоснуйте
пожалуйста почему ваши шеловливые ручки это делают?
P.S. Что за херня простите за выражение…
Уважаемая минусующая часть хабра. Обоснуйте свои
минусы… Из-за чего в топике про Django и вопрос о
выходе новой джанги вы ставите минусы??? Обоснуйте
пожалуйста почему ваши шеловливые ручки это делают?
P.S. Что за херня простите за выражение…
«В админке ушли от JS-велосипедов и наконец-то стали использовать jQuery»
лично меня этот факт радует
лично меня этот факт радует
поддерживаю. конечно, много холиаров по поводу лучшего js-фреймворка, но пусть будет стандартный jquery в админке и нубы будут знать где о нем почитать и спросят у jq-адептов как он работает, чтобы что-то изменить. а кому больше нравится mootools, prototype, etc, и сами смогут прикрутить их вместо jquery, при желании.
я с некоторого времени сижу на транке, поэтому 1.2 наступил очень давно =) А за релизный статус неплохо распить шампанского. Как в том юмористическом рассказе, как программисты строили дом: «сегодня был день железнодорожника. Железнодорожников среди нас нет, так что праздник никто не портил.» Разработчиков Джанги среди нас нет, так что можно смело праздновать и не задумываться, чего им стоит поддерживать проект :)
«Шаблонный тег {% if %} научился понимать операторы сравнения»
почему это только сейчас сделали?
почему это только сейчас сделали?
Хорошая новость. *ушёл смотреть вкусняшки*
Шаблонный тег {% if %} научился понимать операторы сравнения (статья на Django Advent, перевод на Хабре) — вот это прекрастно просто ифеквал надоел.
Какой процент веб питонистов России использует Django?
Судя по активности сообществ, количеству появляющихся новых проектов Django лидирует.
Другие известные python-фреймворки: Zope2, Zope3, TurboGears, Pylons примерно так же распространены, в каком порядке перечислены.
Вот в процентах — стоит опрос на хабре сделать. Будет хоть какая то статистика.
Другие известные python-фреймворки: Zope2, Zope3, TurboGears, Pylons примерно так же распространены, в каком порядке перечислены.
Вот в процентах — стоит опрос на хабре сделать. Будет хоть какая то статистика.
В своё время на Хабре публиковалась некая статистика. Не совсем, конечно, то, однако качественно оценить популярность позволяет, по-моему.
«Не совсем то» это слишком мягко. Там сравнение количества разработчиков нескольких проектов: Django, PyPi, Linux Kernel и т.п., а не российских программистов, использующих Django. Хотя мировую популярность Django вполне наглядно иллюстрирует.
Можно ещё сравнивать по официальным провайдерам (российские тоже встречаются):
Zope http://www.zope.org/Resources/ZSP/
Django http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
TurboGears http://docs.turbogears.org/1.0/Hosting
Pylons http://pylonshq.com/project/pylonshq/wiki/Hosting
Можно ещё сравнивать по официальным провайдерам (российские тоже встречаются):
Zope http://www.zope.org/Resources/ZSP/
Django http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
TurboGears http://docs.turbogears.org/1.0/Hosting
Pylons http://pylonshq.com/project/pylonshq/wiki/Hosting
Народ, извините за некоторый оффтопик, но пользуясь случаем собрания питонистов, позвольте задать вопрос.
Пытался тут поднять (на винде) питоновский медиа-сервер Coherence (приличный свободный UPnP сервер очень нужен и уже срочно). Инсталляционные скрипты вылетают на середине с ошибкой «Connection Reset By Peer», инсталляции получаются незаконченные и ничего не работает.
Соединение с Интернет полноценное — быстрое и достаточно прямое (выделенка с постоянным IP через 1 soho-роутер 3COM), ни с одной не-питоновской программой проблемм нет.
В Гугле немало упоминаний этой проблемы, но практичнсконо решения для пользователя (дебажить исходники на этом языке я пока не готов) я так и не нашёл :-(
Пытался тут поднять (на винде) питоновский медиа-сервер Coherence (приличный свободный UPnP сервер очень нужен и уже срочно). Инсталляционные скрипты вылетают на середине с ошибкой «Connection Reset By Peer», инсталляции получаются незаконченные и ничего не работает.
Соединение с Интернет полноценное — быстрое и достаточно прямое (выделенка с постоянным IP через 1 soho-роутер 3COM), ни с одной не-питоновской программой проблемм нет.
В Гугле немало упоминаний этой проблемы, но практичнсконо решения для пользователя (дебажить исходники на этом языке я пока не готов) я так и не нашёл :-(
Вопрос: переход с предыдущей версии безболезненный?
Почти =) Есть несколько обратно несовместимых изменений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел релиз Django 1.2