Как стать автором
Обновить

Комментарии 68

А вы говорили на devconf.ru: «Где 1.2?» А вот!!!
А есть смысл? Или просто ради художественной завершенности композиции? Ведь придется ждать обновления всех тех штук, которые есть для Джанго. И свои приложения адаптировать нужно будет.
А у меня нет ещё на Питоне своих приложений, которые надо адаптировать и какого бы то ни было опыта разработки на этом языке. Тем временем я всё больше и больше к нему присматриваюсь. А начинать что-то с нуля, ясное дело, хочется на свежайшей версии, т.к. отсутствие необходимости поддержки старого кода позволяет использовать современные фичи на всю катушку, а ориентация на будущее делает предпочтительным использовать свежайшие, «bleeding edge», что называется, технологии чтобы избежать скорого устаревания наработок. Python 2.6 сейчас, как я понимаю, на пике, и дальше ему дорога только вниз, в пользу 3-й ветки.
Вообще-то разница между Python 2.x и Python 3.x не такая же, как в случае с php4 и php5.

Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2. Не думаю, что Django все это требуется. А сопутствующий гемор, связанный с пересмотром многих алгоритмов — не совсем то, ради чего создавалась Django.
> Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2.

Так это же отлично! :-) Я как рас сейчас это подход наконец распробовал и более-менее понял, восторг еле сдерживаю…
ну это всё доступно и питоне 2, в стандартных модулях типа itertools, functools и т.п.
джангу совсем не сложно сложно перевести на питон 3(заставить работать её и на 2-м и на 3-без разделения на 2 ветки — тожн рельно). Просто пока смысла в этом нет — для питона 3 ещё нет и питоновских модулей многих нужных, например, PIL
>Python 3 больше нацелен на функциональную парадигму программирования, а не на императивную, как Python 2.

Щито? Не курите больше, ок?
Кстати, одно из самых приятных обновлений — это --failfast
Теперь и работа чуть быстрее будет.
Ну не знаю. На мой взгляд, польза этой фишки довольно сомнительна. Если какой-то тесткейс фейлится, не проще ли запустить именно его не дожидаясь, пока пройдут другие?
Так в том то и все дело. Запустились тесты гжде-нибудь на тестовом сервере, и как только сфейлилось — сразу останов тестов, и получаешь репорт о проблеме. А не ждёшь когда всё пройдёт, или следишь всё время…
У нас, видимо, разные подходы к разработке. Я стараюсь писать тесты и, соответственно, запускать по одному: написание теста, реализация, запуск. Когда итерация заканчивается, пишу следующий и так далее.

А после того, как написаны все тесты, можно запустить пачку целиком. Все тесты должны проходить в силу независимости тестов друг от друга. Если не проходят — то это уже человеческий фактор, где-то напутал с логикой. В любом случае, чаще одного-двух раз запускать все наборы не приходится.
А чем круче писать на Django нежели например на C# или PHP?
Что концептуально нового?
Django стал языком программирования?
Или Вы просто «не в теме»?
> Django стал языком программирования?

Django на сколько мне известно это каркас. А любой каркас как и язык программирования
предоставляет какие-то идею (например, MVC). Так вот мой вопрос собственно про то что
концептуально нового и интересного в Django? Из-за чего он лучше альтернатив на других
языках?

> Или Вы просто «не в теме»?

Наверное просто не знаю более одного каркаса для C#, а их много?
Ну с PHP еще можно сказать, что тройка-пятерка наберется…

P.S. За замечание насчет языков спасибо, но все таки что там такого? В чем изюминка?
Если вы ипользуете PHP, то самое близкое сравнение — Симфония. В Джанго есть классные средства для быстрого написания чистых, удобных, расширяемых сайтов. Хороший встроенный урл-роутер, хорошая модульная система, хороший встроенный орм и система миграций (правда, не встроенная, но подключающаяся парой строчек). Изюминка выражена общим девизом фреймворка: «for perfectionsts with deadlines».
Проиллюстрирую.

пример из туториала 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, поэтому к нему можно обращаться напрямую.

пара моментов:

Во-первых, вполне можно делать модель 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)
    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('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() не ради одного параметра пишут.
locals() — это PHP-стиль: «А давайте забабахаем все в template, авось что-нибудь, да пригодится»

Отсюда и дыры в безопасности и вообще гадливое впечатление от PHP. Посмотрите, сколько ненужной и потенциально опасной информации ваш locals передает в шаблон.
Ну и сколько?

request — который в шаблонах и так обычно есть
poll — то что требуется
poll_id == poll.id — не принципиально.

А пафоса-то, пафоса… PHP-стиль :)

p.s. Прочитайте мой комент вниательней. locals() — не мой, я только разместил объяву. Про потенциальные проблемы, тоже отмечено.
Не все то, что «разжовывается» в туториале является конечным кодом, который стоит сравнивать с другими.

Тот кусок 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. На питоне так никто не пишет — обычно там выходят просто небольшие независимые части, часто даже в процедурном стиле. Код, написанный в таком стиле, проще понимать и изменять.

Питон хорош тем, что устраняет необходимость думать по мелочам (обычно самый эффективный код — самый понятный и короткий), не приветствует трюкачество и архитектурную астронавтику, разгружает голову, и из-за этого оказывается проще взглянуть на свой код «свысока».
«Причем половину этих паттернов можно было бы выкинуть, если бы C# поддерживал динамическую типизацию»

Для некоторых целей лучше как раз иметь статический анализ. Не для сайтов, для groupware.
> трюкачество и архитектурная астронавтика
Хорошо сказал! (:
Это цитата Джоэла Спольски. Как-то так:

«Иногда умные мыслители просто не знают, когда остановится, и создают весь этот абсурд, всеохватывающие высокоуровневые картины Вселенной, которые хороши и точны, но вообще ничего не значат. Этих людей я называю Архитектурными Астронавтами. Очень сложно убедить их написать код или спроектировать программу, потому что они не могут прекратить думать об Архитектуре.»

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

(скопипастал из своего перевода интервью с Гради Бучем вот отсюда: 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 — а если где-то не так, то фриланс-удаленку-стартапствование никто не запрещал.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, можно выбрать любой вариант и не прогадать. Разница в том, что для монстров (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 должен быть проблемой и там.
Честно говоря, на wiki хорошо описано для ознакомления в общих чертах. Если непонятно, то скорее всего, Вам не приходилось сталкиваться с подобными задачами.
Касательно PHP, внесу свою лепту в ответ немного с другой стороны — почти все джангисты, которых я знаю, перешли на Python+Django с PHP+что-то.

И я не слышал ни об одном джангисте, который перешел на PHP, более того, я уверен, что таких не существует.

В ощущениях это проявлется так, что PHP-прошлое вспоминается как страшный сон с сопутствующим впечатлением, что тебя все эти годы обманывали, скрывая прекрасный совершенный мир за стеной :-)
причем на пхп есть нормальные фреймворки, CI, Yii и др., но подавляющее большинство пхп-программеров о них не знают и по старинке пишут аццкие рид-онли портянки из смеси хтмл+пхп (как и я несколько лет назад)).
НЛО прилетело и опубликовало эту надпись здесь
все встреченные мной перешедшии c php неслышали никогда про фрэймворки и занимались быдлокодингом :) неудивительно что им снятся страшные сны

соответствено использующии php фрэймворки программисты не ведутся на красивые проспекты и не бегают взад вперед :)

почемуто никто не вспомнил о том что питон+джанго работает в разы быстрее чем пхп+симфони(или другие фреймворки). естественно если сравнивать на одинаковом железе. И еще все что написано на питоне намного проще интегрировать с ОС(nix)
Товарищи… Я разгневан шквалом ваших минусов…
Уважаемая минусующая часть хабра. Обоснуйте свои
минусы… Из-за чего в топике про Django и вопрос о
выходе новой джанги вы ставите минусы??? Обоснуйте
пожалуйста почему ваши шеловливые ручки это делают?

P.S. Что за херня простите за выражение…
«В админке ушли от JS-велосипедов и наконец-то стали использовать jQuery»
лично меня этот факт радует
поддерживаю. конечно, много холиаров по поводу лучшего js-фреймворка, но пусть будет стандартный jquery в админке и нубы будут знать где о нем почитать и спросят у jq-адептов как он работает, чтобы что-то изменить. а кому больше нравится mootools, prototype, etc, и сами смогут прикрутить их вместо jquery, при желании.
ничего
Пройдет еще пару десятков лет, и джангисты постигнут ДАО, что unobtrusive js это хорошо.
И таки да, уважаемые пехепе кодеры, не читайте это, до вас это все равно не дойдет.
я с некоторого времени сижу на транке, поэтому 1.2 наступил очень давно =) А за релизный статус неплохо распить шампанского. Как в том юмористическом рассказе, как программисты строили дом: «сегодня был день железнодорожника. Железнодорожников среди нас нет, так что праздник никто не портил.» Разработчиков Джанги среди нас нет, так что можно смело праздновать и не задумываться, чего им стоит поддерживать проект :)
Я тоже на транке, где-то с января, наверное. Поэтому знаю, что полезные фичи там появляются не сразу. А иногда ещё и баги вылазят :(
«Шаблонный тег {% if %} научился понимать операторы сравнения»
почему это только сейчас сделали?
У них вообще очень строгий шаблонизатор. Перенос логики в шаблон не приветствуется — их философия.
Причины исключительно идеологические: излишняя логика в шаблонах — зло, и сложные операторы if считали излишней логикой, но к релизу 1.2 сдались и немного сместили баланс.
Может быть, они таки разуплотнятся и когда нибудь введут python expressions? Версии эдак к 2.2.
любите Вы потроллить джанго-фанов вроде меня)

Если начинать бесполезный поток аргументов, то включить по умолчанию в шаблонах свою версию тега if, если стандартная не устраивает — пара строк кода.
Хорошая новость. *ушёл смотреть вкусняшки*
Шаблонный тег {% if %} научился понимать операторы сравнения (статья на Django Advent, перевод на Хабре) — вот это прекрастно просто ифеквал надоел.
меня передергивает каждый раз как пишу {% endifnotequal %}
Какой процент веб питонистов России использует Django?
Судя по активности сообществ, количеству появляющихся новых проектов Django лидирует.
Другие известные 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
Народ, извините за некоторый оффтопик, но пользуясь случаем собрания питонистов, позвольте задать вопрос.

Пытался тут поднять (на винде) питоновский медиа-сервер Coherence (приличный свободный UPnP сервер очень нужен и уже срочно). Инсталляционные скрипты вылетают на середине с ошибкой «Connection Reset By Peer», инсталляции получаются незаконченные и ничего не работает.

Соединение с Интернет полноценное — быстрое и достаточно прямое (выделенка с постоянным IP через 1 soho-роутер 3COM), ни с одной не-питоновской программой проблемм нет.

В Гугле немало упоминаний этой проблемы, но практичнсконо решения для пользователя (дебажить исходники на этом языке я пока не готов) я так и не нашёл :-(
Вопрос: переход с предыдущей версии безболезненный?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации