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

Выполнение действий после фиксации транзакции¶

Новый хук on_commit() позволяет выполнять действия после успешной фиксации транзакции базы данных. Это полезно для таких задач, как отправка писем с уведомлениями, создание задач в очереди или аннулирование кэша.

Эта функциональность из пакета django-transaction-hooks была интегрирована в Django.

Проверка пароля¶

Django теперь предлагает проверку паролей, чтобы помочь предотвратить использование слабых паролей пользователями. Валидация встроена в прилагаемые формы смены и сброса пароля и легко интегрируется в любой другой код. Проверка выполняется одним или несколькими валидаторами, настраиваемыми в новой настройке AUTH_PASSWORD_VALIDATORS.

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

По умолчанию валидация не производится, и все пароли принимаются, поэтому если вы не установите AUTH_PASSWORD_VALIDATORS, вы не увидите никаких изменений. В новых проектах, созданных с шаблоном по умолчанию startproject, включается простой набор валидаторов. Чтобы включить базовую валидацию во включенных auth-формах для вашего проекта, вы можете установить, например:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

Более подробную информацию см. в разделе Проверка пароля.

Миксины разрешений для представлений на основе классов¶

Django теперь поставляется с миксинами AccessMixin, LoginRequiredMixin, PermissionRequiredMixin и UserPassesTestMixin для обеспечения функциональности django.contrib.auth.decorators для представлений на основе классов. Эти миксины были взяты из проекта django-braces или, по крайней мере, вдохновлены им.

Однако есть несколько различий между реализацией Django и django-braces':

• Атрибут raise_exception может быть только True или False. Пользовательские исключения или callables не поддерживаются.
• Метод handle_no_permission() не принимает аргумент request. Текущий запрос доступен в self.request.
• Пользовательский test_func() из UserPassesTestMixin не принимает аргумент user. Текущий пользователь доступен в self.request.user.
• Атрибут permission_required поддерживает строку (определяющую одно разрешение) или список/кортеж строк (определяющих несколько разрешений), которые должны быть выполнены для предоставления доступа.
• Новый атрибут permission_denied_message позволяет передать сообщение в исключение PermissionDenied.

Новая стилизация для contrib.admin¶

Админка имеет современный плоский дизайн с новыми SVG иконками, которые идеально смотрятся на экранах HiDPI. Он по-прежнему обеспечивает полнофункциональную работу браузеров YUI’s A-grade. В более старых браузерах может наблюдаться различный уровень плавной деградации.

Параллельное выполнение тестов¶

Команда test теперь поддерживает опцию --parallel для параллельного запуска тестов проекта в нескольких процессах.

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

Эта опция включена по умолчанию для собственного набора тестов, предоставляемого Django:

• ОС поддерживает его (все, кроме Windows)
• бэкенд базы данных поддерживает его (все встроенные бэкенды, кроме Oracle)

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

API бэкенда базы данных¶

• Пара новых тестов полагается на способность бэкенда интроспектировать значения столбцов по умолчанию (возвращая результат в виде Field.default). Вы можете установить функцию базы данных can_introspect_default на False, если ваш бэкенд этого не делает. Вы можете просмотреть реализацию на бэкендах, которые Django включает для справки (#24245).

• Не рекомендуется регистрировать глобальный адаптер или конвертер на уровне модуля DB-API для обработки информации о часовом поясе значений datetime, передаваемых в качестве параметров запроса или возвращаемых в качестве результатов запроса в базах данных, не поддерживающих часовые пояса. Это может привести к конфликту с другими библиотеками.

  Рекомендуемый способ добавления часового пояса к значениям datetime, получаемым из базы данных, заключается в регистрации конвертера для DateTimeField в DatabaseOperations.get_db_converters().

  Функция базы данных needs_datetime_string_cast была удалена. Бэкенды баз данных, установившие его, должны зарегистрировать вместо него конвертер, как объяснено выше.

• Методы DatabaseOperations.value_to_db_<type>() были переименованы в adapt_<type>field_value(), чтобы отразить методы convert_<type>field_value().

• Для использования нового поиска date сторонним бэкендам баз данных может потребоваться реализовать метод DatabaseOperations.datetime_cast_date_sql().

• Был добавлен метод DatabaseOperations.time_extract_sql(). Он вызывает существующий метод date_extract_sql(). Этот метод переопределяется бэкендом SQLite для добавления поиска времени (час, минута, секунда) в TimeField, а также может понадобиться бэкендам баз данных сторонних производителей.

• Метод DatabaseOperations.datetime_cast_sql() (не путать с DatabaseOperations.datetime_cast_date_sql(), упомянутым выше) был удален. Этот метод служил для форматирования дат в Oracle задолго до 1.0, но он не переопределялся ни одним бэкендом ядра в течение многих лет и не вызывался нигде в коде или тестах Django.

• Для поддержки распараллеливания тестов вы должны реализовать метод DatabaseCreation._clone_test_db() и установить DatabaseFeatures.can_clone_databases = True. Возможно, вам придется настроить DatabaseCreation.get_test_db_clone_settings().

Параметры по умолчанию, которые были кортежами, теперь стали списками¶

Настройки по умолчанию в django.conf.global_settings представляли собой комбинацию списков и кортежей. Все настройки, которые раньше были кортежами, теперь стали списками.

Атрибут is_usable на загрузчиках шаблонов удален¶

Загрузчики шаблонов Django ранее требовали определения атрибута is_usable. Если загрузчик был настроен в настройках шаблона, а этот атрибут был False, то загрузчик молча игнорировался. На практике это использовалось только загрузчиком яиц, чтобы определить, установлен ли setuptools. Теперь атрибут is_usable удален, и вместо этого загрузчик яиц завершает работу во время выполнения, если setuptools не установлен.

Связанное прямое назначение¶

Прямое присвоение связанных объектов в ORM раньше выполняло clear() с последующим вызовом add(). Это вызывало ненужные большие изменения данных и не позволяло использовать сигнал m2m_changed для отслеживания отдельных изменений в отношениях «многие-ко-многим».

Прямое присвоение теперь полагается на новый метод set() на менеджерах related, который по умолчанию обрабатывает только изменения между существующим набором related и вновь присваиваемым. Прежнее поведение можно восстановить, заменив прямое присваивание вызовом set() с аргументом ключевого слова clear=True.

ModelForm, и, следовательно, ModelAdmin, внутренне полагаются на прямое присвоение для отношений «многие-ко-многим» и, как следствие, теперь используют новое поведение.

Загрузчики шаблонов на базе файловой системы отлавливают более специфические исключения¶

При использовании загрузчиков шаблонов filesystem.Loader или app_directories.Loader ранние версии Django выдавали ошибку TemplateDoesNotExist, если источник шаблона существовал, но был нечитаемым. Это могло произойти при многих обстоятельствах, например, если у Django не было прав на открытие файла, или если источник шаблона был каталогом. Теперь Django замалчивает исключение только в том случае, если источник шаблона не существует. Во всех остальных ситуациях возникает исходное IOError.

HTTP-перенаправления больше не принудительно направляются на абсолютные URI¶

Относительные перенаправления больше не преобразуются в абсолютные URI. RFC 2616 требовал, чтобы заголовок Location в ответах перенаправления был абсолютным URI, но он был заменен RFC 7231, который позволяет относительные URI в Location, признавая фактическую практику пользовательских агентов, почти все из которых поддерживают их.

Следовательно, ожидаемые URL, передаваемые в assertRedirects, как правило, больше не должны включать схему и доменную часть URL. Например, self.assertRedirects(response, 'http://testserver/some-url/') должен быть заменен на self.assertRedirects(response, '/some-url/') (если только перенаправление не содержало абсолютный URL).

В редких случаях, когда вам нужно старое поведение (обнаруженное в древней версии Apache с mod_scgi, которая интерпретирует относительный редирект как «внутренний редирект»), вы можете восстановить его, написав пользовательское промежуточное ПО:

class LocationHeaderFix(object):
    def process_response(self, request, response):
        if 'Location' in response:
            response['Location'] = request.build_absolute_uri(response['Location'])
        return response

Прекращена поддержка PostgreSQL 9.0¶

Поддержка PostgreSQL 9.0 завершилась в сентябре 2015 года. Как следствие, Django 1.9 устанавливает 9.1 в качестве минимальной версии PostgreSQL, которую он официально поддерживает.

Прекращена поддержка Oracle 11.1¶

Поддержка Oracle 11.1 завершилась в августе 2015 года. Как следствие, Django 1.9 устанавливает 11.2 в качестве минимальной версии Oracle, которую он официально поддерживает.

Массовое поведение метода add() связанных менеджеров¶

Для повышения производительности методы add() связанных менеджеров, созданных ForeignKey и GenericForeignKey, перешли от серии вызовов Model.save() к одному вызову QuerySet.update(). Это изменение означает, что сигналы pre_save и post_save больше не посылаются. Вы можете использовать аргумент ключевого слова bulk=False, чтобы вернуться к предыдущему поведению.

Шаблон LoaderOrigin и StringOrigin удалены¶

В предыдущих версиях Django, когда шаблонизатор инициализировался с отладкой как True, экземпляр django.template.loader.LoaderOrigin или django.template.base.StringOrigin устанавливался в качестве атрибута origin для объекта шаблона. Эти классы были объединены в Origin и теперь всегда устанавливаются независимо от настройки отладки движка. Для минимального уровня обратной совместимости старые имена классов будут сохранены в качестве псевдонимов для нового класса Origin до выхода Django 2.0.

Изменения в конфигурации протоколирования по умолчанию¶

Чтобы облегчить написание пользовательских конфигураций логирования, стандартная конфигурация логирования Django больше не определяет django.request и django.security логгеры. Вместо этого, она определяет один регистратор django, отфильтрованный на уровне INFO, с двумя обработчиками:

• console: фильтруется на уровне INFO и активен, только если DEBUG=True.
• mail_admins: фильтруется на уровне ERROR и активен, только если DEBUG=False.

Если вы не переопределяете логирование Django по умолчанию, вы должны увидеть минимальные изменения в поведении, но вы можете увидеть некоторые новые логи в консоли runserver, например.

Если вы переопределяете логирование Django по умолчанию, вам следует проверить, как ваша конфигурация сочетается с новыми настройками по умолчанию.

HttpRequest подробности в отчетах об ошибках¶

Было излишним отображать полную информацию о HttpRequest каждый раз, когда она появлялась как переменная стекового кадра в HTML-версии отладочной страницы и письма об ошибке. Таким образом, теперь в HTTP-запросе будет отображаться то же стандартное представление, что и для других переменных (repr(request)). В результате метод ExceptionReporterFilter.get_request_repr() и недокументированная функция django.http.build_request_repr() были удалены.

Содержимое текстовой версии письма было изменено, чтобы обеспечить отслеживание той же структуры, что и в случае AJAX-запросов. Детали трассировки выводятся методом ExceptionReporter.get_traceback_text().

Удаление глобальных адаптеров и конвертеров для временных периодов с учетом часовых поясов¶

Django больше не регистрирует глобальные адаптеры и конвертеры для управления информацией о часовом поясе на значениях datetime, отправленных в базу данных в качестве параметров запроса или прочитанных из базы данных в результатах запроса. Это изменение затрагивает проекты, удовлетворяющие всем следующим условиям:

• Настройкой USE_TZ является True.
• База данных - это SQLite, MySQL, Oracle или база данных стороннего производителя, которая не поддерживает часовые пояса. В случае сомнений можно проверить значение connection.features.supports_timezones.
• Код запрашивает базу данных вне ORM, обычно с помощью cursor.execute(sql, params).

Если вы передаете в такие запросы знающие параметры datetime, вам следует преобразовать их в наивные даты в UTC:

from django.utils import timezone
param = timezone.make_naive(param, timezone.utc)

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

Если вы считываете значения datetime из результатов, они будут наивными, а не осознанными. Вы можете компенсировать это следующим образом:

from django.utils import timezone
value = timezone.make_aware(value, timezone.utc)

Вам не нужно ничего из этого, если вы запрашиваете базу данных через ORM, даже если вы используете запросы raw(). ORM позаботится об управлении информацией о часовом поясе.

Модули тегов шаблонов импортируются при настройке шаблонов¶

Бэкенд DjangoTemplates теперь выполняет обнаружение установленных модулей тегов шаблонов при инстанцировании. Это обновление позволяет явно предоставлять библиотеки через ключ 'libraries' в OPTIONS при определении бэкенда DjangoTemplates. Ошибки импорта или синтаксиса в модулях тегов шаблонов теперь выдаются раньше во время инстанцирования, а не при первой компиляции шаблона с тегом {% load %}.

django.template.base.add_to_builtins() удаляется¶

Хотя это был частный API, проекты обычно использовали add_to_builtins(), чтобы сделать теги шаблонов и фильтры доступными без использования тега {% load %}. Этот API был формализован. Теперь проекты должны определять встроенные библиотеки через ключ 'builtins' в OPTIONS при определении бэкенда DjangoTemplates.

simple_tag теперь обертывает вывод тегов в conditional_escape¶

В общем случае теги шаблонов не автоэскейпируют свое содержимое, и это поведение documented. Для таких тегов, как inclusion_tag, это не является проблемой, поскольку включенный шаблон будет выполнять автоэскейп. Для assignment_tag() вывод будет экранирован, когда он будет использоваться как переменная в шаблоне.

Однако для предполагаемых случаев использования simple_tag очень легко получить неправильный HTML и, возможно, XSS-эксплойт. Например:

@register.simple_tag(takes_context=True)
def greeting(context):
    return "Hello {0}!".format(context['request'].user.first_name)

В старых версиях Django это будет XSS проблемой, поскольку user.first_name не экранируется.

В Django 1.9 это исправлено: если в контексте шаблона установлено autoescape=True (по умолчанию), то simple_tag будет обертывать вывод функции тега с помощью conditional_escape().

Чтобы исправить simple_tags, лучше всего применять следующие методы:

• Любой код, генерирующий HTML, должен использовать либо систему шаблонов, либо format_html().
• Если вывод simple_tag требует экранирования, используйте escape() или conditional_escape().
• Если вы абсолютно уверены, что выводите HTML из доверенного источника (например, из поля CMS, которое хранит HTML, введенный администраторами), вы можете пометить его как таковой, используя mark_safe().

Теги, которые следуют этим правилам, будут корректны и безопасны независимо от того, выполняются ли они на Django 1.9+ или более ранних версиях.

Paginator.page_range¶

Paginator.page_range теперь является итератором, а не списком.

В версиях Django, предшествующих 1.8, Paginator.page_range возвращало list в Python 2 и range в Python 3. Django 1.8 постоянно возвращает список, но итератор более эффективен.

Существующий код, который зависит от специфических возможностей list, таких как индексирование, может быть перенесен путем преобразования итератора в list с помощью list().

Неявный поиск QuerySet __in удален¶

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

Model.objects.filter(related_id=RelatedModel.objects.all())

неявно преобразуется в:

Model.objects.filter(related_id__in=RelatedModel.objects.all())

в результате чего получается SQL типа "related_id IN (SELECT id FROM ...)".

Этого неявного __in больше не происходит, поэтому «IN» SQL теперь «=», и если подзапрос возвращает несколько результатов, по крайней мере, некоторые базы данных будут выдавать ошибку.

contrib.admin поддержка браузера¶

Администратор больше не поддерживает Internet Explorer 8 и ниже, так как срок службы этих браузеров истек.

CSS и изображения для поддержки Internet Explorer 6 и 7 были удалены. Значки PNG и GIF были заменены значками SVG, которые не поддерживаются Internet Explorer 8 и более ранними версиями.

Библиотека jQuery, встроенная в админку, была обновлена с версии 1.11.2 до 2.1.4. jQuery 2.x имеет тот же API, что и jQuery 1.x, но не поддерживает Internet Explorer 6, 7 или 8, что позволяет повысить производительность и уменьшить размер файла. Если вам нужна поддержка IE8 и при этом необходимо использовать последнюю версию Django, вы можете заменить администраторскую копию jQuery на свою собственную, создав Django-приложение с такой структурой:

app/static/admin/js/vendor/
    jquery.js
    jquery.min.js

SyntaxError при установке Django setuptools 5.5.x¶

При установке Django 1.9 или 1.9.1 с помощью setuptools 5.5.x вы увидите:

Compiling django/conf/app_template/apps.py ...
  File "django/conf/app_template/apps.py", line 4
    class {{ camel_case_app_name }}Config(AppConfig):
          ^
SyntaxError: invalid syntax

Compiling django/conf/app_template/models.py ...
  File "django/conf/app_template/models.py", line 1
    {{ unicode_literals }}from django.db import models
                             ^
SyntaxError: invalid syntax

Можно игнорировать эти ошибки (Django все равно установится), но вы можете избежать их, обновив setuptools до более свежей версии. Если вы используете pip, вы можете обновить pip с помощью команды python -m pip install -U pip, которая также обновит setuptools. Эта проблема решена в более поздних версиях Django, как описано в Примечания к выпуску Django 1.9.2.

Разное¶

• Статические файлы jQuery в contrib.admin были перемещены в подкаталог vendor/jquery.
• Текст, отображаемый для нулевых столбцов в ячейках списка изменений администратора list_display, изменился с (None) (или его переведенного эквивалента) на - (тире).
• django.http.responses.REASON_PHRASES и django.core.handlers.wsgi.STATUS_CODE_TEXT были удалены. Вместо них используйте стандартную библиотеку Python: http.client.responses для Python 3 и httplib.responses для Python 2.
• ValuesQuerySet и ValuesListQuerySet были удалены.
• Шаблон admin/base.html больше не задает window.__admin_media_prefix__ или window.__admin_utc_offset__. Ссылки на изображения в JavaScript, которые использовали это значение для построения абсолютных URL, были перенесены в CSS для упрощения настройки. Смещение UTC хранится в атрибуте data тега <body>.
• Валидация CommaSeparatedIntegerField была усовершенствована, чтобы запретить такие значения, как ',', ',1' и '1,,2'.
• Инициализация формы была перенесена из метода ProcessFormView.get() в новый метод FormMixin.get_context_data(). Это может быть обратно несовместимо, если вы переопределили метод get_context_data() без вызова super().
• Поддержка PostGIS 1.5 была прекращена.
• Поле django.contrib.sites.models.Site.domain было изменено на unique.
• Чтобы обеспечить изоляцию тестов, запросы к базе данных по умолчанию больше не разрешены в тестах SimpleTestCase. Вы можете отключить это поведение, установив атрибут класса allow_database_queries на True в вашем тестовом классе.
• ResolverMatch.app_name был изменен, чтобы содержать полный путь к пространству имен в случае вложенных пространств имен. Для согласованности с ResolverMatch.namespace пустым значением теперь является пустая строка вместо None.
• Для усиления безопасности сеансовые ключи должны состоять не менее чем из 8 символов.
• Частная функция django.utils.functional.total_ordering() была удалена. Она содержала обходное решение для ошибки functools.total_ordering() в версиях Python старше 2.7.3.
• Раньше XML-сериализация (либо через dumpdata, либо через фреймворк синдикации) выводила любые полученные символы. Теперь, если сериализуемое содержимое содержит какие-либо управляющие символы, не разрешенные стандартом XML 1.0, сериализация завершится неудачей с ошибкой ValueError.
• CharField теперь по умолчанию удаляет из вводимых данных пробельные символы, идущие впереди и позади. Это можно отключить, установив новый аргумент strip в значение False.
• Текст шаблона, который переводится и использует два или более последовательных знаков процента, например "%%", может иметь новый msgid после выполнения makemessages (скорее всего, перевод будет помечен как нечеткий). Новый msgid будет помечен "#, python-format".
• Если ни request.current_app, ни Context.current_app не установлены, тег шаблона url теперь будет использовать пространство имен текущего запроса. Установите request.current_app в None, если вы не хотите использовать подсказку пространства имен.
• Настройка SILENCED_SYSTEM_CHECKS теперь глушит сообщения всех уровней. Ранее сообщения уровня ERROR и выше выводились на консоль.
• Поле FlatPage.enable_comments удалено из FlatPageAdmin, поскольку оно не используется приложением. Если ваш проект или стороннее приложение использует его, create a custom ModelAdmin добавьте его обратно.
• Возвращаемое значение setup_databases() и первый аргумент teardown_databases() изменились. Раньше они были кортежами (old_names, mirrors). Теперь это только первый элемент, old_names.
• По умолчанию LiveServerTestCase пытается найти доступный порт в диапазоне 8081-8179 вместо того, чтобы просто попробовать порт 8081.
• Системные проверки для ModelAdmin теперь проверяют экземпляры, а не классы.
• Частный API для применения смешанных планов миграции был упразднен по соображениям производительности. Смешанные планы состоят из списка миграций, некоторые из которых применяются, а другие не применяются.
• Связанные классы дескрипторов объектов модели в django.db.models.fields.related (частный API) перемещены из модуля related в related_descriptors и переименованы следующим образом:
  • ReverseSingleRelatedObjectDescriptor это ForwardManyToOneDescriptor
  • SingleRelatedObjectDescriptor это ReverseOneToOneDescriptor
  • ForeignRelatedObjectsDescriptor это ReverseManyToOneDescriptor
  • ManyRelatedObjectsDescriptor это ManyToManyDescriptor
• Если вы реализуете пользовательское представление handler404, оно должно возвращать ответ с кодом состояния HTTP 404. Используйте HttpResponseNotFound или передайте status=404 в HttpResponse. В противном случае APPEND_SLASH не будет корректно работать с DEBUG=False.

assignment_tag()¶

Django 1.4 добавил помощник assignment_tag для облегчения создания тегов шаблонов, которые хранят результаты в переменной шаблона. Помощник simple_tag() получил такую же возможность, сделав assignment_tag устаревшим. Теги, использующие assignment_tag, должны быть обновлены для использования simple_tag.

Синтаксис {% cycle %} с аргументами, разделенными запятыми¶

Тег cycle поддерживает устаревший синтаксис из предыдущих версий Django:

{% cycle row1,row2,row3 %}

Его разбор вызвал ошибки в текущем синтаксисе, поэтому поддержка старого синтаксиса будет удалена в Django 1.10 после ускоренной депривации.

ForeignKey и OneToOneField on_delete аргумент¶

Чтобы повысить осведомленность о каскадном удалении моделей, аргумент on_delete в ForeignKey и OneToOneField будет обязательным в Django 2.0.

Обновите модели и существующие миграции для явного задания аргумента. Поскольку по умолчанию используется models.CASCADE, добавьте on_delete=models.CASCADE ко всем ForeignKey и OneToOneField, которые не используют другую опцию. Вы также можете передать его в качестве второго позиционного аргумента, если вас не волнует совместимость со старыми версиями Django.

Field.rel изменения¶

Field.rel и его методы и атрибуты изменились, чтобы соответствовать API связанных полей. Атрибут Field.rel переименован в remote_field, а многие его методы и атрибуты либо изменены, либо переименованы.

Цель этих изменений - предоставить документированный API для полей отношений.

GeoManager и GeoQuerySet пользовательские методы¶

Все пользовательские методы GeoQuerySet (area(), distance(), gml(), …) были заменены эквивалентными географическими выражениями в аннотациях (см. в новых возможностях). Следовательно, необходимость задавать пользовательский GeoManager для моделей с поддержкой ГИС теперь отпала. Как только ваш код не будет вызывать ни один из устаревших методов, вы можете просто удалить строки objects = GeoManager() из ваших моделей.

API загрузчика шаблонов изменились¶

Загрузчики шаблонов Django были обновлены, чтобы позволить рекурсивное расширение шаблонов. Это изменение привело к необходимости создания нового API загрузчика шаблонов. Старые методы load_template() и load_template_sources() теперь устарели. Подробности о новом API можно найти in the template loader documentation.

Передача 3-кортежа или app_name в include()¶

Часть передачи кортежа в качестве аргумента в include() была заменена передачей аргумента namespace в include(). Например:

polls_patterns = [
     url(...),
]

urlpatterns = [
    url(r'^polls/', include((polls_patterns, 'polls', 'author-polls'))),
]

становится:

polls_patterns = ([
     url(...),
], 'polls')  # 'polls' is the app_name

urlpatterns = [
    url(r'^polls/', include(polls_patterns, namespace='author-polls')),
]

Аргумент app_name в include() был заменен передачей кортежа (как указано выше) или передачей объекта или модуля с атрибутом app_name (как указано ниже). Если app_name задан этим новым способом, аргумент namespace больше не требуется. По умолчанию он будет иметь значение app_name. Например, шаблоны URL в учебнике изменены с:

urlpatterns = [
    url(r'^polls/', include('polls.urls', namespace="polls")),
    ...
]

к:

urlpatterns = [
    url(r'^polls/', include('polls.urls')),  # 'namespace="polls"' removed
    ...
]

app_name = 'polls'  # added
urlpatterns = [...]

Это изменение также означает, что старый способ включения экземпляра AdminSite устарел. Вместо этого передавайте admin.site.urls непосредственно в django.conf.urls.url():

from django.conf.urls import url
from django.contrib import admin

urlpatterns = [
    url(r'^admin/', admin.site.urls),
]

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

В прошлом пространство имен экземпляра без пространства имен приложения служило той же цели, что и пространство имен приложения, но при наличии пространства имен приложения с тем же именем невозможно было отменить шаблоны. Включения, указывающие пространство имен экземпляра, требуют, чтобы включенный URLconf устанавливал пространство имен приложения.

current_app параметр к представлениям contrib.auth¶

Все представления в django.contrib.auth.views имеют следующую структуру:

def view(request, ..., current_app=None, ...):

    ...

    if current_app is not None:
        request.current_app = current_app

    return TemplateResponse(request, template_name, context)

Начиная с Django 1.8, current_app устанавливается на объект request. Для согласованности, эти представления будут требовать от вызывающего установить current_app на request вместо того, чтобы передавать его в отдельном аргументе.

django.contrib.gis.geoip¶

Модуль django.contrib.gis.geoip2 заменяет модуль django.contrib.gis.geoip. Новый модуль предоставляет аналогичный API, за исключением того, что он не предоставляет методы совместимости с устаревшим API GeoIP-Python.

Разное¶

• Аргумент weak в django.dispatch.signals.Signal.disconnect() был устаревшим, так как не имеет никакого эффекта.
• Метод check_aggregate_support() django.db.backends.base.BaseDatabaseOperations был устаревшим и будет удален в Django 2.0. Вместо него следует использовать более общий check_expression_support().
• django.forms.extras является устаревшим. Вместо этого вы можете найти SelectDateWidget в django.forms.widgets (или просто django.forms).
• Частный API django.db.models.fields.add_lazy_relation() устарел.
• Декоратор django.contrib.auth.tests.utils.skipIfCustomUser() устарел. С изменениями в обнаружении тестов в Django 1.6, тесты для приложений django.contrib больше не запускаются как часть проекта пользователя. Поэтому декоратор @skipIfCustomUser больше не нужен для декорирования тестов в django.contrib.auth.
• Если вы настроили некоторые error handlers, сигнатуры представлений только с одним параметром запроса устарели. Теперь представления должны принимать и второй позиционный параметр exception.
• Атрибуты django.utils.feedgenerator.Atom1Feed.mime_type и django.utils.feedgenerator.RssFeed.mime_type устарели в пользу content_type.
• Signer теперь выдает предупреждение, если используется недопустимый разделитель. Это станет исключением в Django 1.10.
• django.db.models.Field._get_val_from_obj() устарел в пользу Field.value_from_object().
• django.template.loaders.eggs.Loader устарел, так как распространение приложений в виде яиц не рекомендуется.
• Аргумент callable_obj в виде ключевого слова SimpleTestCase.assertRaisesMessage() устарел. Вместо этого передавайте вызываемый объект в качестве позиционного аргумента.
• Атрибут allow_tags для методов ModelAdmin был устаревшим. Вместо него используйте format_html(), format_html_join() или mark_safe() при построении возвращаемого значения метода.
• Аргумент enclosure с ключевым словом SyndicationFeed.add_item() устарел. Используйте новый аргумент enclosures, который принимает список объектов Enclosure вместо одного.
• Псевдонимы django.template.loader.LoaderOrigin и django.template.base.StringOrigin для django.template.base.Origin устарели.