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

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

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

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

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

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

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

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

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

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

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

Новый стиль для contrib.admin¶

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

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

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

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

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

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

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

API серверной части базы данных ¶

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

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

  Рекомендуемый способ добавить часовой пояс к datetimeзначениям, полученным из базы данных, - зарегистрировать преобразователь для DateTimeField in 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 = TrueDatabaseCreation.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()методе связанных менеджеров, который по умолчанию обрабатывает только изменения между существующим связанным набором и новым назначенным. Предыдущее поведение можно восстановить, заменив прямое присвоение вызовом 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-адресов схемы и домена. Например, следует заменить на (если перенаправление специально не содержит абсолютный URL-адрес).self.assertRedirects(response, 'http://testserver/some-url/')self.assertRedirects(response, '/some-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, когда механизм шаблонов был инициализирован с помощью debug as 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()для предоставления тегов и фильтров шаблонов без использования тега. Этот API формализован. Теперь проекты должны определять встроенные библиотеки с помощью ключа при определении серверной части.{% load %}'builtins'OPTIONSDjangoTemplates

simple_tagтеперь переносит вывод тегов в conditional_escape¶

Как правило, теги шаблона не экранируют свое содержимое автоматически, и это поведение задокументировано . Для таких тегов inclusion_tagэто не проблема, потому что включенный шаблон будет выполнять автоматическое экранирование. For 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_tagошибки, лучше всего применить следующие методы:

• Любой код, генерирующий 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возвращал a listв Python 2 и a rangeв Python 3. Django 1.8 последовательно возвращал список, но итератор более эффективен.

Существующий код, зависящий от listопределенных функций, таких как индексация, можно перенести путем преобразования итератора в listusing 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, используя который также обновит инструменты установки. Эта проблема решена в более поздних версиях Django, как описано в примечаниях к выпуску Django 1.9.2 .python -m pip install -U pip

Разное ¶

• Статические файлы jQuery contrib.adminперемещены в vendor/jqueryподкаталог.
• Текст, отображаемый для пустых столбцов в list_display ячейках административного списка изменений, изменился с (None)(или его переведенного эквивалента) на -(тире).
• django.http.responses.REASON_PHRASESи django.core.handlers.wsgi.STATUS_CODE_TEXTбыли удалены. Вместо этого используйте Python stdlib: 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 хранится в атрибуте данных <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атрибут class в 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 как он не используется приложением. Если ваш проект или стороннее приложение использует его, создайте собственный 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аргумент ¶

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

Обновите модели и существующие миграции, чтобы явно указать аргумент. Поскольку значение по умолчанию - models.CASCADEдобавить on_delete=models.CASCADEко всем ForeignKeyи OneToOneFields, которые не используют другой параметр. Вы также можете передать его как второй позиционный аргумент, если вас не волнует совместимость со старыми версиями 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 можно найти в документации загрузчика шаблонов .

Передача 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()был заменен путем пропускания 2-кортеж (как указано выше), или передавая объект или модуль с 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, за исключением того, что он не предоставляет устаревшие методы совместимости GeoIP-Python API.

Разное ¶

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