Поддержка 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, на которых основано ваше приложение.

Дополнительную информацию см. в документации по пользовательским моделям <auth-custom-user>.

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

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

{% дословно %} тег шаблона¶

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

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

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

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

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

ГеоДжанго¶

• LineString и MultiLineString Объекты GEOS теперь поддерживают interpolate() и project() методы (так называемые линейные ссылки).

• Свойства wkb и hex объектов GEOSGeometry сохраняют измерение Z.

• Добавлена ​​поддержка PostGIS 2.0, а поддержка GDAL < 1.5 прекращена.

Новые уроки¶

Дополнения к документации включают обновленный Урок 3 и новый учебник по тестированию. Новый раздел «Продвинутые руководства» предлагает Как писать повторно используемые приложения, а также пошаговое руководство для новых участников Написание первого патча для 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() теперь имеет аргумент пакетного_размера. По умолчанию размер пакета не ограничен, за исключением SQLite, где один пакет ограничен, поэтому не превышается 999 параметров на запрос.

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

• Django теперь предоставляет обработчик аутентификации mod_wsgi </howto/deployment/wsgi/apache-auth>.

• 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 исчезает во время того же сеанса браузера.

• Серверная часть сеанса на основе кэша <cached-sessions-backend>` может хранить данные сеанса в кэше, отличном от умолчанию.

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

• Во время конфигурации ведения журнала Django включены подробные предупреждения об устаревании, и предупреждения фиксируются в системе ведения журналов. Зарегистрированные предупреждения перенаправляются через обработчик журналирования 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. Для получения более подробной информации см. полную документацию для нового параметра.

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

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

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

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

Для согласованности с другими базовыми представлениями на основе даты YearArchiveView теперь передает year в контексте как datetime.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, как только функция просмотра возвращала ответ. Это плохо взаимодействовало с потоковыми ответами, которые задерживают генерацию контента.

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

Запросы 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 больше не используется.¶

Как поясняется ниже, в 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 или новее), или

• Встроенная копия Simplejson версии 2.0.7.

В 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 из стандартной библиотеки дает самую надежную гарантию обратной совместимости. Они рекомендуют использовать его с этого момента.

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

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

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

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

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

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

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

Промежуточное программное обеспечение сеанса Django пропустит сохранение данных сеанса, если код состояния ответа равен 500.

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

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

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

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

Словарь cleaned_data сохраняется для недопустимых форм.¶

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

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

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

Если вы используете syncdb в нескольких базах данных, вам следует убедиться, что ваши маршрутизаторы позволяют синхронизировать типы контента и разрешения только для одной из них. Дополнительную информацию см. в документации по поведению дополнительных приложений с несколькими базами данных.

Десериализатор 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 поддерживают побитовые операторы & и |. Эти операторы теперь доступны с использованием .bitand() и .bitor(). Удаление & и | было сделано для обеспечения совместимости с выражениями Q() и QuerySet, в которых операторы используются как логические операторы AND и OR.

• При вызове filter(), когда выражения F содержали поисковые запросы, охватывающие многозначные отношения, они не всегда повторно использовали те же отношения, что и другие поисковые запросы в той же цепочке. Это было изменено, и теперь выражения 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_lated(), теперь вызывает DoesNotExist вместо возврата None.

django.contrib.localflavor¶

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

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

django.contrib.markup¶

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

AUTH_PROFILE_MODULE¶

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

Вы по-прежнему можете определять модели профилей пользователей, которые имеют однозначное отношение к модели пользователя — фактически, для многих приложений, которым необходимо связать данные с учетной записью пользователя, это будет подходящим шаблоном проектирования. Однако параметр 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 — см. раздел обратно-несовместимые изменения. Если вы полагаетесь на функции, добавленные в simplejson после того, как он стал json` Python, вам следует импортировать simplejson явно.

django.utils.encoding.StrAndUnicode¶

Смесь django.utils.encoding.StrAndUnicode устарела. Определите метод __str__ и вместо него примените декоратор django.utils.encoding.python_2_unicode_совместимый.

django.utils.itercompat.product¶

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

команда управления очистка¶

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

скрипт daily_cleanup.py¶

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

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

Аргумент ключевого слова «глубина» в select_lated() устарел. Вместо этого вам следует использовать имена полей.