Примечания к выпуску Django 1.5¶

Поддержка Python 3¶

В Django 1.5 появилась поддержка Python 3 - в частности, Python 3.2 и выше. Это поставляется в виде единой кодовой базы; вам не нужно устанавливать другую версию Django на Python 3. Это означает, что вы можете писать приложения, предназначенные только для Python 2, только для Python 3, или отдельные приложения, поддерживающие обе платформы.

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

Некоторые функции Django недоступны, потому что они зависят от стороннего программного обеспечения, которое еще не перенесено на Python 3, в том числе:

• бэкенд базы данных MySQL (зависит от MySQLdb)
• ImageField (зависит от PIL)
• LiveServerTestCase (зависит от Selenium WebDriver)

Кроме того, Django - это не просто веб-фреймворк, это экосистема подключаемых компонентов. На данный момент очень мало сторонних приложений было перенесено на Python 3, поэтому маловероятно, что реальное приложение будет иметь все свои зависимости под Python 3.

Таким образом, мы рекомендуем не использовать Django 1.5 в производстве под Python 3. Вместо этого используйте эту возможность, чтобы начать перенос приложений на Python 3. Если вы являетесь автором подключаемого компонента, мы призываем вас начать перенос уже сейчас.

Мы планируем предложить первоклассную, готовую к производству поддержку Python 3 в нашем следующем релизе Django 1.6.

Настраиваемая модель пользователя¶

В Django 1.5 вы теперь можете использовать свою собственную модель в качестве хранилища данных, связанных с пользователями. Если вашему проекту нужно имя пользователя с более чем 30 символами, или если вы хотите хранить имена пользователей в формате, отличном от имени/фамилии, или если вы хотите поместить пользовательскую информацию о профиле в ваш объект User, теперь вы можете это сделать.

Если у вас есть стороннее приложение многократного использования, которое ссылается на модель User, вам может потребоваться внести некоторые изменения в то, как вы ссылаетесь на экземпляры User. Вам также следует задокументировать все специфические особенности модели User, на которые опирается ваше приложение.

Более подробную информацию см. в documentation on custom user models.

Поддержка сохранения подмножества полей модели¶

В методе Model.save() появился новый ключевой аргумент update_fields. С помощью этого аргумента можно сохранить только выборочный список полей модели. Это может быть полезно для повышения производительности или для того, чтобы избежать перезаписи одновременных изменений.

Отложенные экземпляры (загруженные по .only() или .defer()) будут автоматически сохранять только загруженные поля. Если какое-либо поле было установлено вручную после загрузки, оно также будет обновлено при сохранении.

Более подробную информацию см. в документации Model.save().

Кэширование связанных экземпляров модели¶

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

>>> first_poll = Poll.objects.all()[0]
>>> first_choice = first_poll.choice_set.all()[0]
>>> first_choice.poll is first_poll
True

В Django 1.5 третья строка больше не вызывает новый SQL-запрос для получения first_choice.poll; он был задан второй строкой.

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

Явная поддержка потоковых ответов¶

До версии Django 1.5 можно было создать потоковый ответ, передав итератор в HttpResponse. Но это было ненадежно: любое промежуточное ПО, которое обращалось к атрибуту content, преждевременно расходовало итератор.

Теперь вы можете явно генерировать потоковый ответ с помощью нового класса StreamingHttpResponse. Этот класс раскрывает атрибут streaming_content, который является итератором.

Поскольку StreamingHttpResponse не имеет атрибута content, промежуточное ПО, которому нужен доступ к содержимому ответа, должно проверить наличие потоковых ответов и вести себя соответствующим образом.

{% verbatim %} тег шаблона¶

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

Извлечение ContentType экземпляров, связанных с прокси-моделями¶

Методы ContentTypeManager.get_for_model() и ContentTypeManager.get_for_models() имеют новый аргумент ключевое слово - соответственно for_concrete_model и for_concrete_models. Передавая False с помощью этого аргумента, теперь можно получить ContentType, связанные с прокси-моделями.

Новая переменная view в контексте представлений на основе классов¶

Во всех generic class-based views (или любом представлении, основанном на классе и наследующем от ContextMixin) контекстный словарь содержит переменную view, которая указывает на экземпляр View.

GeoDjango¶

• <<< Объекты LineString и MultiLineString GEOS теперь поддерживают методы interpolate() и project() (так называемая линейная привязка).
• Свойства wkb и hex объектов GEOSGeometry сохраняют размерность Z.
• Была добавлена поддержка PostGIS 2.0 и прекращена поддержка GDAL < 1.5.

Новые учебники¶

Дополнения к документации включают обновленный Tutorial 3 и новый tutorial on testing. Новый раздел «Продвинутые учебники» предлагает How to write reusable apps, а также пошаговое руководство для новых участников Writing your first patch for Django.

Незначительные особенности¶

Django 1.5 также включает несколько более мелких улучшений, на которые стоит обратить внимание:

• Теперь шаблонизатор интерпретирует True, False и None как соответствующие объекты Python.

• django.utils.timezone предоставляет помощника для преобразования известных дат между часовыми поясами. См. localtime().

• Общие представления поддерживают запросы OPTIONS.

• Команды управления больше не вызывают SystemExit при вызове кодом из call_command(). Любое исключение, вызванное командой (в основном CommandError), распространяется.

  Более того, при выводе ошибок или сообщений в пользовательских командах теперь следует использовать self.stdout.write('message') и self.stderr.write('error') (см. примечание о management commands output).

• Команда управления dumpdata выводит по одной строке за раз, предотвращая ошибки выхода за пределы памяти при сбросе больших наборов данных.

• В местном колорите Канады к допустимым кодам для Квебека был добавлен «pq». Это старая аббревиатура.

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

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

• QuerySet.bulk_create() теперь имеет аргумент batch_size. По умолчанию размер партии неограничен, за исключением SQLite, где размер одной партии ограничен, чтобы не превысить 999 параметров на запрос.

• Настройки LOGIN_URL и LOGIN_REDIRECT_URL теперь также принимают имена функций представления и named URL patterns. Это позволяет сократить дублирование конфигурации. Более подробную информацию можно найти в документации login_required().

• Django теперь предоставляет mod_wsgi auth handler.

• QuerySet.delete() и Model.delete() теперь могут принимать быстрый путь в некоторых случаях. Быстрый путь позволяет использовать меньше запросов и меньше объектов, загружаемых в память. Подробности смотрите в QuerySet.delete().

• Экземпляр ResolverMatch хранится в запросе как resolver_match.

• По умолчанию все сообщения журнала, достигающие регистратора django, когда DEBUG становится True, отправляются на консоль (если вы не переопределите регистратор в настройках LOGGING).

• При использовании RequestContext теперь можно искать разрешения с помощью {% if 'someapp.someperm' in perms %} в шаблонах.

• Больше не требуется иметь шаблоны 404.html и 500.html в корневом каталоге шаблонов. Django будет выводить некоторые базовые сообщения об ошибках для обеих ситуаций, когда эти шаблоны не найдены. Тем не менее, рекомендуется в качестве хорошей практики предоставлять эти шаблоны для того, чтобы представить пользователю красивые страницы ошибок.

• django.contrib.auth предоставляет новый сигнал, который выдается всякий раз, когда пользователь не может успешно войти в систему. См. user_login_failed

• Новая опция loaddata --ignorenonexistent игнорирует данные для полей, которые больше не существуют.

• Новые утверждения assertXMLEqual() и assertXMLNotEqual() позволяют проверять равенство для содержимого XML на семантическом уровне, не обращая внимания на синтаксические различия (пробелы, порядок атрибутов и т.д.).

• RemoteUserMiddleware теперь заставляет выйти из системы, когда заголовок REMOTE_USER исчезает во время одной и той же сессии браузера.

• cache-based session backend может хранить данные сессии в кэше не по умолчанию.

• Теперь на моделях можно создавать многоколоночные индексы. Для получения дополнительной информации ознакомьтесь с документацией index_together.

• В конфигурации логирования Django включена функция verbose Deprecation warnings, и предупреждения записываются в систему логирования. Зафиксированные предупреждения направляются через обработчик логирования console, который по умолчанию требует, чтобы DEBUG был равен True для вывода. В результате DeprecationWarnings должны выводиться на консоль в средах разработки так, как они выводились в Python версий < 2.7.

• API для метода django.contrib.admin.ModelAdmin.message_user() был модифицирован, чтобы принимать дополнительные аргументы, добавляя возможности, аналогичные django.contrib.messages.add_message(). Это полезно для генерации сообщений об ошибках при выполнении действий администратора.

• Фильтры списка администратора теперь могут быть настроены на каждый запрос благодаря новому методу django.contrib.admin.ModelAdmin.get_list_filter().

ALLOWED_HOSTS требуется в производстве¶

Новая настройка ALLOWED_HOSTS проверяет заголовок запроса Host и защищает от атак с отравлением хоста. Эта настройка теперь требуется всякий раз, когда DEBUG является False, иначе django.http.HttpRequest.get_host() вызовет SuspiciousOperation. Подробнее о новой настройке см. в full documentation.

Менеджеры по абстрактным моделям¶

Абстрактные модели могут определять пользовательский менеджер, и этот менеджер will be inherited by any concrete models extending the abstract model. Однако, если вы попытаетесь использовать абстрактную модель для вызова метода менеджера, то теперь будет вызвано исключение. Ранее вызов был разрешен, но при попытке выполнить любую операцию с базой данных (обычно с ошибкой «таблица не существует» от базы данных) вызов был бы неудачным.

Если у вас есть функциональность на менеджере, которую вы вызывали с помощью абстрактного класса, вам следует перенести эту логику в Python staticmethod или classmethod на абстрактный класс.

Контекст в годовом архиве на основе классных представлений¶

Для согласованности с другими общими представлениями, основанными на дате, YearArchiveView теперь передает year в контексте как datetime.date, а не как строку. Если вы используете {{ year }} в своих шаблонах, вы должны заменить его на {{ year|date:"Y" }}.

next_year и previous_year также были добавлены в контекст. Они вычисляются в соответствии с allow_empty и allow_future.

Контекст в архиве года и месяца на основе классных представлений¶

YearArchiveView и MonthArchiveView были документированы для предоставления date_list, отсортированного в порядке возрастания в контексте, как и их предшественники на основе функций, но на самом деле он был в порядке убывания. В версии 1.5 документированный порядок был восстановлен. Вы можете добавить (или убрать) ключевое слово reversed, когда вы итерируете date_list в шаблоне:

{% for date in date_list reversed %}

ArchiveIndexView по-прежнему обеспечивает date_list в порядке убывания.

Контекст в TemplateView¶

Для согласованности с дизайном других общих представлений TemplateView больше не передает словарь params в контекст, а передает переменные из URLconf непосредственно в контекст.

Неформализованные данные в HTTP-запросах¶

request.POST больше не будет включать в заголовок данные, размещенные через HTTP-запросы с неспецифическими для формы типами содержимого. В предыдущих версиях данные, отправленные с типами содержимого, отличными от multipart/form-data или application/x-www-form-urlencoded, по-прежнему были представлены в атрибуте request.POST. Разработчики, желающие получить доступ к необработанным данным POST в таких случаях, должны использовать атрибут request.body.

request_finished сигнал¶

Раньше Django посылал сигнал request_finished, как только функция представления возвращала ответ. Это плохо взаимодействовало с streaming responses, которые задерживали генерацию контента.

Теперь этот сигнал отправляется после того, как содержимое полностью потреблено шлюзом WSGI. Это может быть обратно несовместимо, если вы полагаетесь на то, что сигнал будет отправлен до отправки содержимого ответа клиенту. В этом случае вместо него следует использовать middleware.

OPTIONS, PUT и DELETE запросы в тестовом клиенте¶

В отличие от GET и POST, эти методы HTTP не реализуются веб-браузерами. Скорее, они используются в API, которые передают данные в различных форматах, таких как JSON или XML. Поскольку такие запросы могут содержать произвольные данные, Django не пытается декодировать их тело.

Однако тестовый клиент использовал для запросов OPTIONS и DELETE строку запроса, как для GET, а для запросов PUT - тело запроса, как для POST. Такая кодировка была произвольной и не соответствовала поведению Django при получении запросов, поэтому в Django 1.5 она была удалена.

Если вы использовали параметр data в запросе OPTIONS или DELETE, вы должны преобразовать его в строку запроса и добавить к параметру path.

Если вы использовали параметр data в запросе PUT без аргумента content_type, вы должны закодировать свои данные перед передачей их тестовому клиенту и установить аргумент content_type.

Системная версия simplejson больше не используется¶

As explained below, Django 1.5 устаревает django.utils.simplejson в пользу встроенного в Python 2.6 модуля json. Теоретически, это изменение безвредно. К сожалению, из-за несовместимости версий simplejson, в некоторых обстоятельствах оно может вызвать ошибки.

Функции, связанные с JSON, в Django 1.4 всегда использовали django.utils.simplejson. Этот модуль был на самом деле:

• Системная версия simplejson, если она была доступна (т.е. import simplejson работает), если она была более свежей, чем встроенная копия Django, или имела ускорения C, или
• Модуль json из стандартной библиотеки, если он доступен (т.е. Python 2.6 или выше), или
• Встроенная копия версии 2.0.7 программы simplejson.

В Django 1.5 эти функции используют модуль Python json, который основан на версии 2.0.9 модуля simplejson.

Нет никаких известных несовместимостей между копией Django версии 2.0.7 и копией Python версии 2.0.9. Однако существуют некоторые несовместимости между другими версиями simplejson:

• Хотя API simplejson документирован как всегда возвращающий строки Unicode, дополнительная реализация на языке C может возвращать байтовые строки. Это было исправлено в Python 2.7.
• simplejson.JSONEncoder получил аргумент в виде ключевого слова namedtuple_as_object в версии 2.2.

Более подробную информацию об этих несовместимостях можно найти в ticket #18023.

В итоге, если вы установили simplejson и ваш код использует внутренние компоненты сериализации Django напрямую - например, django.core.serializers.json.DjangoJSONEncoder, то переход с simplejson на json может сломать ваш код. (Как правило, изменения внутренних механизмов не документируются; здесь мы делаем исключение).

На данный момент сопровождающие Django считают, что использование json из стандартной библиотеки дает самую сильную гарантию обратной совместимости. Они рекомендуют использовать его впредь.

Строковые типы параметров метода хешера¶

Если вы написали custom password hasher, ваши методы encode(), verify() или safe_summary() должны принимать параметры Unicode (password, salt или encoded). Если какой-либо из методов хэширования требует байтовых строк, вы можете использовать утилиту force_bytes() для кодирования строк.

Проверка номера предыдущей_страницы и номера следующей_страницы¶

При использовании object pagination методы previous_page_number() и next_page_number() объекта Page не проверяли, находится ли возвращаемое число внутри существующего диапазона страниц. Теперь они проверяют это и вызывают исключение InvalidPage, если число слишком мало или слишком велико.

Изменено поведение опции автокоммита базы данных в PostgreSQL¶

Опция автокоммита в PostgreSQL не работала так, как рекламировалось ранее. Она работала для одного блока транзакции, но после выхода первого блока поведение автокоммита не восстанавливалось. Теперь эта ошибка исправлена в версии 1.5. Хотя это всего лишь исправление, стоит проверить поведение ваших приложений, если вы используете PostgreSQL вместе с опцией autocommit.

Сессия не сохраняется при 500 ответах¶

Django’s session middleware пропустит сохранение данных сессии, если код состояния ответа равен 500.

Проверка электронной почты при неудачном входе в систему администратора¶

До версии Django 1.5, если вы пытались войти в интерфейс администратора и по ошибке использовали свой адрес электронной почты вместо имени пользователя, интерфейс администратора выдавал предупреждение о том, что ваш адрес электронной почты не является вашим именем пользователя. В Django 1.5 введение custom user models потребовало удаления этого предупреждения. Это не меняет поведение входа на сайт администратора; это только влияет на предупреждение, которое отображается при одном конкретном способе отказа входа.

Изменения в выполнении тестов¶

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

cleaned_data словарь сохраняется для недействительных форм¶

Словарь cleaned_data теперь всегда присутствует после валидации формы. Когда форма не проходит валидацию, он содержит только те поля, которые прошли валидацию. Вы должны проверять успешность валидации методом is_valid(), а не наличием или отсутствием атрибута cleaned_data на форме.

Поведение syncdb с несколькими базами данных¶

syncdb теперь запрашивает маршрутизаторы базы данных, чтобы определить, должны ли типы содержимого (когда включена опция contenttypes) и разрешения (когда включена опция auth) быть созданы в целевой базе данных. Ранее они создавались в базе данных по умолчанию, даже если с помощью опции --database была указана другая база данных.

Если вы используете syncdb на нескольких базах данных, вы должны убедиться, что ваши маршрутизаторы позволяют синхронизировать типы содержимого и разрешения только на одной из них. Более подробную информацию смотрите в документации по behavior of contrib apps with multiple databases.

Десериализатор XML не будет разбирать документы с DTD¶

Для предотвращения атак типа «отказ в обслуживании», связанных с внешними ссылками на сущности и расширением сущностей, десериализатор модели XML теперь отказывается анализировать XML документы, содержащие DTD (определение DOCTYPE). Поскольку XML сериализатор не выводит DTD, это не повлияет на обычное использование, только на случаи, когда созданные пользователем XML документы передаются десериализатору модели Django.

Наборы форм по умолчанию max_num¶

Значение None (по умолчанию) для аргумента max_num фабрики форм больше не разрешает по умолчанию любое количество форм в наборе форм. Вместо этого, для предотвращения атак на исчерпание памяти, теперь по умолчанию устанавливается ограничение в 1000 форм. Это ограничение можно повысить, явно задав большее значение для max_num.

Разное¶

• django.forms.ModelMultipleChoiceField теперь возвращает пустое значение QuerySet вместо пустого списка.
• int_to_base36() правильно выдает TypeError вместо ValueError для нецелых входов.
• Шаблонный фильтр slugify теперь доступен как стандартная функция Python по адресу django.utils.text.slugify(). Аналогично, remove_tags доступен по адресу django.utils.html.remove_tags().
• Загруженные файлы больше не создаются как исполняемые по умолчанию. Если вам нужно, чтобы они были исполняемыми, измените значение FILE_UPLOAD_PERMISSIONS в соответствии с вашими потребностями. Новое значение по умолчанию - 0o666 (восьмеричное), а текущее значение umask сначала маскируется.
• F expressions поддерживал побитовые операторы & и |. Теперь эти операторы доступны с помощью .bitand() и .bitor() вместо них. Удаление & и | было сделано для согласованности с объединением Q() expressions и QuerySet, где эти операторы используются как булевы операторы AND и OR.
• В вызове filter(), когда F expressions содержал поиск, охватывающий многозначные отношения, он не всегда повторно использовал те же отношения, что и другие поиски по той же цепочке. Это было изменено, и теперь выражения F() всегда будут использовать те же отношения, что и другие поиски в пределах одного вызова filter().
• Тег шаблона csrf_token больше не заключен в div. Если вам нужна проверка HTML на соответствие DTD до HTML5 Strict, вы должны добавить div вокруг него на своих страницах.
• Библиотека тегов шаблонов adminmedia, которая содержала только устаревший тег шаблона {% admin_media_prefix %}, была удалена. Попытка загрузить ее с помощью {% load adminmedia %} будет неудачной. Если ваши шаблоны все еще содержат эту строку, вы должны удалить ее.
• Из-за ошибки в реализации можно было использовать django.contrib.redirects без включения django.contrib.sites. Теперь это больше не допускается. Если вы используете django.contrib.redirects, убедитесь, что INSTALLED_APPS содержит django.contrib.sites.
• BoundField.label_tag теперь экранирует свой аргумент contents. Чтобы избежать экранирования HTML, используйте django.utils.safestring.mark_safe() для аргумента перед его передачей.
• Доступ к обратным отношениям один-к-одному, полученным через select_related(), теперь вызывает DoesNotExist вместо возврата None.

django.contrib.localflavor¶

Приложение localflavor contrib было разделено на отдельные пакеты. Сам django.contrib.localflavor будет удален в Django 1.6, после ускоренной депривации.

Новые пакеты доступны на GitHub. Основная команда не может эффективно поддерживать эти пакеты в долгосрочной перспективе - на данный момент она охватывает всего десяток стран; как и в случае с переводами, поддержка будет передана заинтересованным членам сообщества.

django.contrib.markup¶

Модуль markup contrib был устаревшим и будет следовать ускоренному графику устаревания. Прямое использование библиотек разметки Python или сторонних библиотек тегов предпочтительнее, чем Django, поддерживающий эту функциональность во фреймворке.

AUTH_PROFILE_MODULE¶

С введением custom user models больше нет необходимости во встроенном механизме для хранения данных профиля пользователя.

Вы по-прежнему можете определять модели профилей пользователей, которые имеют связь один-к-одному с моделью User - на самом деле, для многих приложений, которым необходимо связать данные с учетной записью User, это будет подходящим шаблоном проектирования. Однако параметр AUTH_PROFILE_MODULE и метод django.contrib.auth.models.User.get_profile() для доступа к модели профиля пользователя больше не должны использоваться.

Потоковое поведение HttpResponse¶

В Django 1.5 устарела возможность потоковой передачи ответа путем передачи итератора в HttpResponse. Если вы полагаетесь на это поведение, переключитесь на StreamingHttpResponse. См. Явная поддержка потоковых ответов выше.

В Django 1.7 и выше итератор будет немедленно поглощен HttpResponse.

django.utils.simplejson¶

Поскольку Django 1.5 отказывается от поддержки Python 2.5, мы теперь можем полагаться на наличие модуля json в стандартной библиотеке Python, поэтому мы удалили нашу собственную копию simplejson. Теперь вам следует импортировать json вместо django.utils.simplejson.

К сожалению, это изменение может иметь нежелательные побочные эффекты из-за несовместимости версий simplejson - см. раздел backwards-incompatible changes. Если вы полагаетесь на возможности, добавленные в simplejson после того, как он стал json Python, вам следует явно импортировать simplejson.

django.utils.encoding.StrAndUnicode¶

Микс-ин django.utils.encoding.StrAndUnicode был устаревшим. Определите метод __str__ и вместо него примените декоратор django.utils.encoding.python_2_unicode_compatible.

django.utils.itercompat.product¶

Функция django.utils.itercompat.product была устаревшей. Вместо нее используйте встроенную itertools.product().

cleanup команда управления¶

Команда управления cleanup была устаревшей и заменена на clearsessions.

daily_cleanup.py сценарий¶

Недокументированный сценарий daily_cleanup.py был устаревшим. Вместо него используйте команду управления clearsessions.

depth аргумент ключевого слова в select_related¶

Аргумент depth в ключевом слове select_related() был устаревшим. Вместо него следует использовать имена полей.