Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
а когда будет переход на новую версию питона?
мой хрустальный шар подсказывает мне, что никак не раньше 1.5
Мне кажется, эта тема самая больная.
А по-моему наоборот, никого python 3 сейчас особо и не волнует. Его все равно пока использовать на практике трудно: какие-то подвисшие вопросы с wsgi + на порядки (раз в 50, глянул только что на pypi) меньше доступных пакетов. Это все при том, что каких-то супер-фич python 3 по сравнению с python 2 не имеет, просто язык немного «подчищен» (да и многие фичи портированы в 2.7). Разработчики «больших» библиотек — старые питонисты, со всеми шероховатостями 2го питона они знакомы и эти шероховатости особых неудобств не доставляют.
В дистрибутивах не то что 3й питон не стоит по умолчанию, там еще не все на 2.6 даже перешли. Месяц назад в RehHat был еще python 2.4 по умолчанию, в CentOS и сейчас 2.4. Это такая древность, и это гораздо более серьезная проблема. Даже в последней убунте — 2.6, а не 2.7. Так что спешить ни у кого мотивации просто нет сейчас. Вещи ведь не делаются сами, кто-то должен взять на себя этот труд, а перевод django на python 3 — задача
а) нетривиальная;
б) не имеющая сейчас практической выгоды.
Короче говоря, сложно найти мотивацию потратить кучу своего личного времени без какой-то практической выгоды, есть куча способов потратить свое время на полезные прямо сейчас вещи.
В дистрибутивах не то что 3й питон не стоит по умолчанию, там еще не все на 2.6 даже перешли. Месяц назад в RehHat был еще python 2.4 по умолчанию, в CentOS и сейчас 2.4. Это такая древность, и это гораздо более серьезная проблема. Даже в последней убунте — 2.6, а не 2.7. Так что спешить ни у кого мотивации просто нет сейчас. Вещи ведь не делаются сами, кто-то должен взять на себя этот труд, а перевод django на python 3 — задача
а) нетривиальная;
б) не имеющая сейчас практической выгоды.
Короче говоря, сложно найти мотивацию потратить кучу своего личного времени без какой-то практической выгоды, есть куча способов потратить свое время на полезные прямо сейчас вещи.
Таким же вопросом постоянно задаюсь, хотя понимаю что это просто обусловленность — если есть последняя версия языка, то надо чтобы на ней был фреймворк :).
На самом деле не могу придумать какие бы это дало преимущества, по сравнению с тем что сейчас.
Наверно больше было бы неудобства — в дистрибутивах 3 версия пока экзотика, полно модулей готовых на 2 ветке и т.д.
Но начать с чистого листа всегда здорово!
Вот принебрегал generic_view, а теперь этот механизм видоизменили к лучшему и теперь уже сразу по новому изучать и использовать буду.
И наверно переход на Питон 3 когда-нибудь также добавит свежих ощущений :)
На самом деле не могу придумать какие бы это дало преимущества, по сравнению с тем что сейчас.
Наверно больше было бы неудобства — в дистрибутивах 3 версия пока экзотика, полно модулей готовых на 2 ветке и т.д.
Но начать с чистого листа всегда здорово!
Вот принебрегал generic_view, а теперь этот механизм видоизменили к лучшему и теперь уже сразу по новому изучать и использовать буду.
И наверно переход на Питон 3 когда-нибудь также добавит свежих ощущений :)
Основанные на классах представления — это мощь!
дааа, это апофигей объектно-ориентированного подхода вообще и питонячести в частности :)
Интересные примеры можно найти на сайте проекта. В том числе, например, можно наследовать свои классы видов от встроенных django.views.generic
Вникнуть толком еще не успел, но мне кажется похожего эффекта можно с помощью декораторов добиться. Хотя честно говоря меня и самого немного смущало что вьюхи это функции
вьюхи как были функциями, так и остались
Так вопрос о том, что мы можем конфигурировать и расширять внешнюю функциональность…
Например, мы напишем какой-то view-класс, описывающий работу раздела сайта, а потом наследуя этот класс создадим view-классы других разделов с немного изменённой функциональностью
Например, мы напишем какой-то view-класс, описывающий работу раздела сайта, а потом наследуя этот класс создадим view-классы других разделов с немного изменённой функциональностью
Не понял… А о чем мы тогда говорим?
если я правильно все понял, то раньше был файлик my_app/views.py в котором были функции — вьюхи. Были Generic вьюхи. в urlconf оо записывалось как
а сейчас вместо функций в my_app/views.py будут классы (в т.ч. и наследующие generic_views) и используются как
если я правильно все понял, то раньше был файлик my_app/views.py в котором были функции — вьюхи. Были Generic вьюхи. в urlconf оо записывалось как
(r'url', my_app.views.my_view),
(r'url2', generic_view, {params})а сейчас вместо функций в my_app/views.py будут классы (в т.ч. и наследующие generic_views) и используются как
(r'url', my_app.views.as_view()),Deprecated — только generic views из джанги. Я вот их лично все равно не использовал, они были негибкие и неудобные. Их заменили на более гибкие generic views на основе классов.
Свои вьюхи можно (и imho в большинстве случаев будет проще, хотя не знаю, не пробовал) продолжать писать в виде функций. Этот способ никто не отменял и отменять не собирается, т.к. он простой и удобный.
CBV — мимикрируют под функции, реализуя метод __call__ (довольно хитрым способом, что связано с требованиями потокобезопасности).
Свои вьюхи можно (и imho в большинстве случаев будет проще, хотя не знаю, не пробовал) продолжать писать в виде функций. Этот способ никто не отменял и отменять не собирается, т.к. он простой и удобный.
CBV — мимикрируют под функции, реализуя метод __call__ (довольно хитрым способом, что связано с требованиями потокобезопасности).
CBV — мимикрируют под функции, реализуя метод __call__ (довольноК счастью от этого безобразия они отказались. В текущей реализации на каждый запрос создается отдельный объект, фабрикой .as_view().
хитрым способом, что связано с требованиями потокобезопасности).
Собственно, вся C-B-V магия заключена здесь:
class View(object):
@classonlymethod
def as_view(cls, **initkwargs):
# ...
def view(request, *args, **kwargs):
self = cls(**initkwargs)
return self.dispatch(request, *args, **kwargs)
# ...
return view
Т.е. с точки зрения urlconf, view как были функциями так и остались.
ps: любопытна, реализация метода dispatch. Здесь данные сначала икапсулируются в объект, а затем передаются его же методу через сигнатуру.
def dispatch(self, request, *args, **kwargs):
# ...
handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
# ...
self.request = request
self.args = args
self.kwargs = kwargs
return handler(request, *args, **kwargs)
вот такое суровое ООП. интересно это как-то связано с увеличением числа «core developers (людей, которые могут принимать решения и коммитить код)» в 2 раза? ))
я давно ждал что-то типа class views. здорово!
Не упомянута поддержка указания контекста для переводимых строк. Мне этого очень не хватало, т.к. в коде и шаблонах часто встречаются строки, которые нельзя перевести одинаково. Самый простой пример — слово «none», которое в зависимости от контекста надо переводить то как «нет», то как «ничего», и т.д.
В предыдущих версиях Django это можно было решить только костылями (например, вручную приписывать контекст к строке в каждом таком случае и не забывать убирать его в переводах).
В предыдущих версиях Django это можно было решить только костылями (например, вручную приписывать контекст к строке в каждом таком случае и не забывать убирать его в переводах).
Только вроде хотел разобраться с generic_view, чтобы код сократить и для простых случаев код во view совсем не писать, а их убирают.
Нельзя будет писать теперь (r'^publishers/$', list_detail.object_list, publisher_info)?
Или я неправильно понял?
Нельзя будет писать теперь (r'^publishers/$', list_detail.object_list, publisher_info)?
Или я неправильно понял?
Аа…
там похоже еще удобней сделали
теперь это будет так выглядеть:
urlpatterns = patterns('',
(r'^publishers/$', ListView.as_view(
model=Publisher,
)),
Мне лично так больше нравится — более красиво.
там похоже еще удобней сделали
теперь это будет так выглядеть:
urlpatterns = patterns('',
(r'^publishers/$', ListView.as_view(
model=Publisher,
)),
Мне лично так больше нравится — более красиво.
Я советую почитать документацию по ссылке к предпредыдущему комментарию. Писать конфигурации URL вы будете немного по-другому, но это вовсе не значит, что теперь код нельзя будет сократить. Да и вообще это ням :)
В одном из проектов использовали самописный аналог Class View. Но там немного другая схема была: класс предоставлял несколько методов-представлений для которых использовался декоратор. А при подключении в urlpatterns он вел себя как include. А Джанговая реализация больше напоминает Google App Engine
Есть ещё отличное нововведение в транке — on_delete для ForeignKey. Все решали проблему с тем, что django эмулировала ON DELETE CASCADE, по-разному. Я вот писал def delete() в каждой модели. И это очень раздражало. Теперь же пришло счастье в виде on_delete.
Относительно class based views: сделано неплохо (по крайней мере теперь можно пользоваться, старые generic views были целиком и полностью бесполезны), но продумано далеко не всё. Например, неясно, как быть, если сигнатуры методов get/post/put/delete различаются.
Со staticfiles молодцы — давно пора было разделить статику сайта и статику пользователя. Но опять перемудрили — сделали специальную manage.py команду для деплоя статики в расчёте на rsync. Но этот путь далеко не единственный.
Относительно class based views: сделано неплохо (по крайней мере теперь можно пользоваться, старые generic views были целиком и полностью бесполезны), но продумано далеко не всё. Например, неясно, как быть, если сигнатуры методов get/post/put/delete различаются.
Со staticfiles молодцы — давно пора было разделить статику сайта и статику пользователя. Но опять перемудрили — сделали специальную manage.py команду для деплоя статики в расчёте на rsync. Но этот путь далеко не единственный.
Насчет CBV — переопределить метод dispatch, видимо. Да и вообще, это только первая альфа, и если есть какие-то замечания или предложения по поводу новых фич, то сейчас самое время написать об этом сюда: groups.google.com/group/django-developers
Команда — не для деплоя статики в расчете на rsync. Команда — для сбора js и css файлов из джанго-приложений (втч сторонних) в одно место.
Это, по-моему, очень крутая команда, и она — суть этих staticfiles. Разделять статику и раньше можно было без проблем.
Теперь у авторов сторонних приложений есть надежный способ распространять медиа-файлы. Раньше нужно было писать в инструкциях «скачайте оттуда-то файлы, скопируйте их туда-то и пропишите такую-то настройку в settings.py». Если приложение обновлялось, то действия нужно было повторять. Сейчас все будет подхватываться полуавтоматически (если автор следует стандартам). И, более того, пользователи, насколько я понимаю, могут переопределять часть файлов без изменения исходных.
И staticfiles, и CBV — это штуки, которые потенциально могут дать очень много для экосистемы. django уже давал ответ на вопрос о том, как расширять и повторно использовать шаблоны (см., например, как это в админке сделано) и формы. Теперь можно расширять и повторно использовать вьюхи (yeah!) и медиа-файлы (+ упрощена их установка).
Так что эти штуки полезны не только сами по себе, главное — благодаря им сторонние приложения станут более гибкими и простыми в использовании.
Команда — не для деплоя статики в расчете на rsync. Команда — для сбора js и css файлов из джанго-приложений (втч сторонних) в одно место.
Это, по-моему, очень крутая команда, и она — суть этих staticfiles. Разделять статику и раньше можно было без проблем.
Теперь у авторов сторонних приложений есть надежный способ распространять медиа-файлы. Раньше нужно было писать в инструкциях «скачайте оттуда-то файлы, скопируйте их туда-то и пропишите такую-то настройку в settings.py». Если приложение обновлялось, то действия нужно было повторять. Сейчас все будет подхватываться полуавтоматически (если автор следует стандартам). И, более того, пользователи, насколько я понимаю, могут переопределять часть файлов без изменения исходных.
И staticfiles, и CBV — это штуки, которые потенциально могут дать очень много для экосистемы. django уже давал ответ на вопрос о том, как расширять и повторно использовать шаблоны (см., например, как это в админке сделано) и формы. Теперь можно расширять и повторно использовать вьюхи (yeah!) и медиа-файлы (+ упрощена их установка).
Так что эти штуки полезны не только сами по себе, главное — благодаря им сторонние приложения станут более гибкими и простыми в использовании.
Постойте-ка, а как сигнатуры методов get/post/put/update могут различаться?
Они все принимают request, *args и **kwargs, что тут менять-то может потребоваться?
Они все принимают request, *args и **kwargs, что тут менять-то может потребоваться?
Если кто-то пробовал писать патчи к джанге, то, наверное, знает, что можно было написать хороший нужный патч с тестами и документацией, который бы потом провисел в трекере года полтора-два — просто из-за того, что ни у кого так и не дошли руки закоммитить его или дать какую-то обратную связь.
Так вот, у django 1.3 есть еще одна фича, очень важная, но о которой, наверное, не напишут в release notes: число core developers (людей, которые могут принимать решения и коммитить код) увеличилось на 10 человек, в 2 раза (а активных — возможно, и больше, чем в 2 раза).
Так вот, у django 1.3 есть еще одна фича, очень важная, но о которой, наверное, не напишут в release notes: число core developers (людей, которые могут принимать решения и коммитить код) увеличилось на 10 человек, в 2 раза (а активных — возможно, и больше, чем в 2 раза).
А как у них обстоят дела с Python3? есть планы?
Мя че-то коробит от Class Based Views. Такое ощущение, что разработчики вытащили весь бардак из generic-views и AdminModel наружу. Не понимаю восторга… 31337' блин, перед php'шниками не стыдно?
Пока это безобразие находилось в contrib и особо не афишировалось, было пофик. А теперь оно стало частью фреймворчного API. API это серьёзная вещь, которая предопределяет судьбу проектов, построенных с его использованием, на долгое время. Поэтому его нужно проектировать, а не фигачить с похмелья в с состоянии аффекта.
Я давно не видел таких идиотских интерфейсов как у новых mixin. Если процедурную «лапшу» запихать в объявление class, она так и остается лапшой. Как сказал оратор выше: «это апофигей объектно-ориентированного подхода». :( А «Date-based Mixins» это вообще кульминация. Парсинг дат, как часть интерфейса view — зачем мешать все в одну кучу?
Лучше бы не страдали фигней, а смержили наработки из внешних проектов, где косяки django постепенно исправляются. Например, из django-piston. Здесь уже тыщу лет есть и нормальные абстракции для представлений ресурсов с помощью объектов, и правильная обработка http-запросов, и сериализация/десериализация контента сообщений по Content-type (а не только multipart/form-data как в джанге).
Пока это безобразие находилось в contrib и особо не афишировалось, было пофик. А теперь оно стало частью фреймворчного API. API это серьёзная вещь, которая предопределяет судьбу проектов, построенных с его использованием, на долгое время. Поэтому его нужно проектировать, а не фигачить с похмелья в с состоянии аффекта.
Я давно не видел таких идиотских интерфейсов как у новых mixin. Если процедурную «лапшу» запихать в объявление class, она так и остается лапшой. Как сказал оратор выше: «это апофигей объектно-ориентированного подхода». :( А «Date-based Mixins» это вообще кульминация. Парсинг дат, как часть интерфейса view — зачем мешать все в одну кучу?
Лучше бы не страдали фигней, а смержили наработки из внешних проектов, где косяки django постепенно исправляются. Например, из django-piston. Здесь уже тыщу лет есть и нормальные абстракции для представлений ресурсов с помощью объектов, и правильная обработка http-запросов, и сериализация/десериализация контента сообщений по Content-type (а не только multipart/form-data как в джанге).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django 1.3 alpha 1