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

Model._meta API¶

Django теперь имеет формализованный API для Model._meta, предоставляя официально поддерживаемый способ retrieve fields и фильтрации полей на основе их attributes.

Объект Model._meta был частью Django со времен до версии 0.96 «Magic Removal» - он просто не был официальным, стабильным API. Признавая это, мы постарались сохранить обратную совместимость со старой конечной точкой API, где это возможно. Однако конечные точки API, которые не являются частью нового официального API, были устаревшими и со временем будут удалены.

Несколько шаблонизаторов¶

Django 1.8 определяет стабильный API для интеграции бэкендов шаблонов. Он включает встроенную поддержку языка шаблонов Django и Jinja2. Он поддерживает рендеринг шаблонов с несколькими движками в рамках одного проекта. Узнайте больше о новых возможностях в topic guide и ознакомьтесь с инструкциями по обновлению в старых версиях документации.

Усовершенствования в области безопасности¶

Некоторые возможности сторонней библиотеки django-secure были интегрированы в Django. django.middleware.security.SecurityMiddleware обеспечивает несколько улучшений безопасности цикла запрос/ответ. Новая опция check --deploy позволяет вам проверить файл настроек вашего продакшена на предмет способов повышения безопасности вашего сайта.

Новая функциональность, специфичная для PostgreSQL¶

В Django появился модуль с расширениями для специфических возможностей PostgreSQL, таких как ArrayField, HStoreField, Поля диапазона и unaccent lookup. Полное описание возможностей доступно in the documentation.

Новые типы данных¶

• В Django теперь есть UUIDField для хранения универсально уникальных идентификаторов. Он хранится как собственный тип данных uuid в PostgreSQL и как символьное поле фиксированной длины в других бэкендах. Существует соответствующий form field.
• В Django теперь есть DurationField для хранения периодов времени - в Python это моделируется timedelta. Он хранится в собственном типе данных interval в PostgreSQL, как INTERVAL DAY(9) TO SECOND(6) в Oracle, и как bigint микросекунд в других бэкендах. Арифметика, связанная с датой и временем, также была улучшена на всех бэкендах. Имеется соответствующее значение form field.

Выражения запросов, условные выражения и функции базы данных¶

Query Expressions позволяют создавать, настраивать и составлять сложные SQL-выражения. Это позволило annotate принимать выражения, отличные от агрегатов. Агрегаты теперь могут ссылаться на несколько полей, а также выполнять арифметические действия, аналогично объектам F(). order_by() также получил возможность принимать выражения.

Conditional Expressions позволяют использовать if … elif … else логику в запросах.

Коллекция database functions также включена с такими функциональными возможностями, как Coalesce, Concat и Substr.

TestCase установка данных¶

TestCase был рефакторингован, чтобы позволить инициализацию данных на уровне класса с использованием транзакций и точек сохранения. Бэкенды баз данных, не поддерживающие транзакции, такие как MySQL с механизмом хранения MyISAM, по-прежнему смогут выполнять эти тесты, но не получат преимуществ от улучшений. Тесты теперь выполняются в двух вложенных блоках atomic(): один для всего класса и один для каждого теста.

• Метод класса TestCase.setUpTestData() добавляет возможность устанавливать тестовые данные на уровне класса. Использование этой техники может ускорить выполнение тестов по сравнению с использованием setUp().
• Загрузка приспособления в пределах TestCase теперь выполняется один раз для всего TestCase.

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

Операции со связанными объектами выполняются в транзакции¶

Некоторые операции над связанными объектами, такие как add() или прямое присвоение, выполняли несколько запросов на модификацию данных, не оборачивая их в транзакции. Чтобы снизить риск повреждения данных, все методы модификации данных, затрагивающие несколько связанных объектов (т.е. add(), remove(), clear() и прямое присвоение), теперь выполняют свои запросы на модификацию данных внутри транзакции, если ваша база данных поддерживает транзакции.

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

Присвоение несохраненных объектов отношениям приводит к ошибке¶

>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.save()
Traceback (most recent call last):
...
ValueError: save() prohibited to prevent data loss due to unsaved related object 'author'.

Назначение несохраненных объектов на ForeignKey, GenericForeignKey и OneToOneField теперь вызывает ошибку ValueError.

Ранее назначение несохраненного объекта молча игнорировалось. Например:

>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.author.save()
>>> book.save()

>>> Book.objects.get(name="Django")
>>> book.author
>>>

Теперь для предотвращения потери данных будет выдаваться ошибка:

>>> book.author = Author(name="john")
Traceback (most recent call last):
...
ValueError: Cannot assign "<Author: John>": "Author" instance isn't saved in the database.

Если вам необходимо разрешить присвоение несохраненных экземпляров (старое поведение) и вас не беспокоит возможность потери данных (например, вы никогда не сохраняете объекты в базе данных), вы можете отключить эту проверку с помощью атрибута ForeignKey.allow_unsaved_instance_assignment. (Этот атрибут был удален в версии 1.8.4, поскольку он больше не актуален).

Команды управления, которые принимают только позиционные аргументы¶

Если вы написали пользовательскую команду управления, которая принимает только позиционные аргументы, и не указали командную переменную args, вы можете получить ошибку типа Error: unrecognized arguments: ..., поскольку разбор переменных теперь основан на argparse, который неявно не принимает позиционные аргументы. Вы можете сделать свою команду обратно совместимой, просто установив переменную класса args. Однако, если вам не нужно сохранять совместимость со старыми версиями Django, лучше реализовать новый метод add_arguments(), как описано в Как создавать пользовательские команды django-admin.

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

Метод добавления пользовательских аргументов к команде управления test через бегунок тестирования изменился. Раньше для добавления дополнительных аргументов можно было использовать переменную класса option_list в тестовом бегуне (а-ля optparse). Теперь для реализации того же поведения необходимо создать метод класса add_arguments(cls, parser) в тестовом бегуне и вызвать parser.add_argument для добавления любых пользовательских аргументов, поскольку парсер теперь является экземпляром argparse.ArgumentParser.

Проверка модели гарантирует, что автоматически генерируемые имена столбцов находятся в пределах, заданных базой данных¶

Имя поля, длина которого превышает длину имени столбца, поддерживаемую базой данных, может создать проблемы. Например, в MySQL вы получите исключение при попытке создать колонку, а в PostgreSQL имя колонки будет усечено базой данных (вы можете увидеть предупреждение в журналах PostgreSQL).

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

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

Эта проверка также применяется к столбцам, созданным в неявной модели ManyToManyField.through. Если вы столкнулись с проблемой, используйте through для создания явной модели, а затем укажите db_column на ее столбце (столбцах) по мере необходимости.

Поиск отношений запросов теперь проверяет типы объектов¶

Запрос на поиск модели теперь проверяет правильность типа переданного объекта и выдает ошибку ValueError, если это не так. Ранее Django не заботился о том, правильного ли типа объект; он просто использовал атрибут связанного поля объекта (например, id) для поиска. Теперь для предотвращения неправильного поиска выдается ошибка:

>>> book = Book.objects.create(name="Django")
>>> book = Book.objects.filter(author=book)
Traceback (most recent call last):
...
ValueError: Cannot query "<Book: Django>": Must be "Author" instance.

select_related() теперь проверяет заданные поля¶

select_related() теперь проверяет, что заданные поля действительно существуют. Ранее несуществующие поля молча игнорировались. Теперь выдается ошибка:

>>> book = Book.objects.select_related('nonexistent_field')
Traceback (most recent call last):
...
FieldError: Invalid field name(s) given in select_related: 'nonexistent_field'

Проверка также проверяет, что данное поле является реляционным:

>>> book = Book.objects.select_related('name')
Traceback (most recent call last):
...
FieldError: Non-relational field given in select_related: 'name'

По умолчанию EmailField.max_length увеличено до 254¶

Старый стандартный 75-символьный max_length не позволял хранить все возможные адреса электронной почты, соответствующие требованиям RFC3696/5321. Для того чтобы хранить все возможные действительные адреса электронной почты, max_length был увеличен до 254 символов. Вам необходимо создать и применить миграции базы данных для ваших затронутых моделей (или добавить max_length=75, если вы хотите сохранить длину для ваших текущих полей). Миграция для django.contrib.auth.models.User.email включена в комплект поставки.

Поддержка версий PostgreSQL старше 9.0¶

В июле 2014 года закончился срок поддержки PostgreSQL 8.4. Как следствие, Django 1.8 устанавливает 9.0 в качестве минимальной версии PostgreSQL, которую он официально поддерживает.

Это также включает отказ от поддержки PostGIS 1.3 и 1.4, поскольку эти версии не поддерживаются на версиях PostgreSQL позже 8.4.

Django также теперь требует использования Psycopg2 версии 2.4.5 или выше (или 2.5+, если вы хотите использовать django.contrib.postgres).

Поддержка версий MySQL старше 5.5¶

Окончание срока поддержки было достигнуто в январе 2012 года для MySQL 5.0 и в декабре 2013 года для MySQL 5.1. Как следствие, Django 1.8 устанавливает 5.5 в качестве минимальной версии MySQL, которую он официально поддерживает.

Поддержка версий Oracle старше 11.1¶

Окончание периода поддержки было достигнуто в июле 2010 года для Oracle 9.2, в январе 2012 года для Oracle 10.1 и в июле 2013 года для Oracle 10.2. Как следствие, Django 1.8 устанавливает 11.1 в качестве минимальной версии Oracle, которую он официально поддерживает.

Использование специфических привилегий вместо ролей для тестов на Oracle¶

В предыдущих версиях Django тестовому пользователю на Oracle предоставлялись роли CONNECT и RESOURCE. Эти роли были устаревшими, поэтому Django 1.8 вместо них использует конкретные базовые привилегии. Это изменяет привилегии, требуемые от основного пользователя для запуска тестов (если только проект не настроен так, чтобы не создавать тестового пользователя). Точные привилегии, требуемые сейчас, подробно описаны в Oracle notes.

AbstractUser.last_login допускает нулевые значения¶

Поле AbstractUser.last_login теперь допускает нулевые значения. Ранее оно по умолчанию указывало время, когда пользователь был создан, что вводило в заблуждение, если пользователь никогда не входил в систему. Если вы используете пользователя по умолчанию (django.contrib.auth.models.User), запустите миграцию базы данных, включенную в contrib.auth.

Если вы используете пользовательскую модель пользователя, которая наследуется от AbstractUser, вам нужно будет выполнить makemigrations и сгенерировать миграцию для вашего приложения, содержащего эту модель. Также, если вы хотите установить last_login в NULL для пользователей, которые не вошли в систему, вы можете выполнить следующий запрос:

from django.db import models
from django.contrib.auth import get_user_model
from django.contrib.auth.models import AbstractBaseUser

UserModel = get_user_model()
if issubclass(UserModel, AbstractBaseUser):
    UserModel._default_manager.filter(
        last_login=models.F('date_joined')
    ).update(last_login=None)

django.contrib.gis¶

• Поддержка GEOS 3.1 и GDAL 1.6 была прекращена.
• Поддержка SpatiaLite < 2.4 была прекращена.
• Поиск, специфичный для ГИС, был переработан для использования API django.db.models.Lookup.
• Представление по умолчанию str объектов GEOSGeometry было изменено с формата WKT на формат EWKT (включая SRID). Поскольку это представление используется во фреймворке сериализации, это означает, что вывод dumpdata теперь будет содержать значение SRID геометрических объектов.

Приоритет контекстных процессоров для TemplateResponse приведен в соответствие с render¶

Конструктор TemplateResponse был разработан как замена функции render(). Однако в нем была небольшая несовместимость, заключавшаяся в том, что для TemplateResponse контекстные данные из переданного контекстного словаря могли быть затенены контекстными данными, возвращаемыми контекстными процессорами, в то время как для render все было наоборот. Это была ошибка, и поведение render является более подходящим, поскольку позволяет переопределять глобально определенные контекстные процессоры локально в представлении. Если вы полагались на то, что контекстные данные в TemplateResponse могут быть переопределены с помощью контекстного процессора, вам придется изменить свой код.

Переопределение setUpClass / tearDownClass в тестовых случаях¶

Декораторы override_settings() и modify_settings() теперь действуют на уровне класса, когда используются в качестве декораторов класса. Как следствие, при переопределении setUpClass() или tearDownClass() всегда следует вызывать реализацию super.

Удаление django.contrib.formtools¶

Приложение formtools contrib было перенесено в отдельный пакет, а соответствующие страницы документации были обновлены или удалены.

Новый пакет доступен on GitHub и на PyPI.

Перезагрузка соединения с базой данных между тестами¶

Раньше Django закрывал соединения с базой данных между каждым тестом в рамках TestCase. Теперь это не так, поскольку Django теперь оборачивает весь TestCase внутри транзакции. Если некоторые из ваших тестов полагаются на старое поведение, вам следует унаследовать их от TransactionTestCase.

Очистка пространства имен django.template¶

Если вы полагались на частные API, открытые в модуле django.template, вам, возможно, придется импортировать их из django.template.base вместо этого.

Также были удалены приватные API django.template.base.compile_string(), django.template.loader.find_template() и django.template.loader.get_template_from_string().

model атрибут на частных отношениях модели¶

В ранних версиях Django в модели с обратной связью по внешнему ключу (например) метод model._meta.get_all_related_objects() возвращал связь как django.db.models.related.RelatedObject с атрибутом model, установленным на источник связи. Теперь этот метод возвращает отношение как django.db.models.fields.related.ManyToOneRel (частный API RelatedObject был удален), а атрибут model устанавливается на цель отношения вместо источника. Модель источника доступна по атрибуту related_model вместо этого.

Рассмотрим этот пример из учебника по Django 1.8:

>>> p = Poll.objects.get(pk=1)
>>> p._meta.get_all_related_objects()
[<ManyToOneRel: polls.choice>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Poll'>
>>> p._meta.get_all_related_objects()[0].related_model
<class 'polls.models.Choice'>

и сравните его с поведением на более старых версиях:

>>> p._meta.get_all_related_objects()
[<RelatedObject: polls:choice related to poll>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Choice'>

Для доступа к исходной модели вы можете использовать паттерн, подобный этому, чтобы написать код, который будет работать как с Django 1.8, так и с более старыми версиями:

for relation in opts.get_all_related_objects():
    to_model = getattr(relation, 'related_model', relation.model)

Также обратите внимание, что get_all_related_objects() устарел в версии 1.8.

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

Следующие изменения в API бэкенда базы данных документированы, чтобы помочь тем, кто пишет сторонние бэкенды, обновить свой код:

• Классы BaseDatabaseXXX были перемещены в django.db.backends.base. Пожалуйста, импортируйте их из новых мест:

  from django.db.backends.base.base import BaseDatabaseWrapper
  from django.db.backends.base.client import BaseDatabaseClient
  from django.db.backends.base.creation import BaseDatabaseCreation
  from django.db.backends.base.features import BaseDatabaseFeatures
  from django.db.backends.base.introspection import BaseDatabaseIntrospection
  from django.db.backends.base.introspection import FieldInfo, TableInfo
  from django.db.backends.base.operations import BaseDatabaseOperations
  from django.db.backends.base.schema import BaseDatabaseSchemaEditor
  from django.db.backends.base.validation import BaseDatabaseValidation
  

• Атрибуты data_types, data_types_suffix и data_type_check_constraints перешли из класса DatabaseCreation в DatabaseWrapper.

• Метод SQLCompiler.as_sql() теперь принимает параметр subquery (#24164).

• Метод BaseDatabaseOperations.date_interval_sql() теперь принимает только параметр timedelta.

django.contrib.admin¶

• AdminSite больше не принимает аргумент app_name и его атрибут app_name был удален. Имя приложения всегда admin (в отличие от имени экземпляра, которое все еще можно настроить с помощью AdminSite(name="...").
• Метод ModelAdmin.get_object() (частный API) теперь принимает третий аргумент from_field, чтобы указать, какое поле должно соответствовать предоставленному object_id.
• Метод ModelAdmin.response_delete() теперь принимает второй аргумент obj_id, который является сериализованным идентификатором, используемым для получения объекта перед удалением.

Автоперевод функций в django.template.defaultfilters по умолчанию¶

Чтобы сделать встроенные фильтры шаблонов, выводящие HTML, «безопасными по умолчанию» при вызове их в коде Python, следующие функции в django.template.defaultfilters были изменены так, чтобы автоматически экранировать их входное значение:

• join
• linebreaksbr
• linebreaks_filter
• linenumbers
• unordered_list
• urlize
• urlizetrunc

Вы можете вернуться к старому поведению, указав autoescape=False, если вы передаете доверенное содержимое. Это изменение не влияет на использование соответствующих фильтров в шаблонах.

Разное¶

• connections.queries теперь является атрибутом только для чтения.

• Соединения базы данных считаются одинаковыми, только если они являются одним и тем же объектом. Они больше не являются хэшируемыми.

• GZipMiddleware используется для отключения сжатия для некоторых типов контента при запросе из Internet Explorer, чтобы обойти ошибку в IE6 и более ранних версиях. Такое поведение могло повлиять на производительность в IE7 и более поздних версиях. Оно было удалено.

• URLField.to_python больше не добавляет косую черту в URL без пути.

• Фильтр шаблона length теперь возвращает 0 для неопределенной переменной, а не пустую строку.

• ForeignKey.default_error_message['invalid'] был изменен с '%(model)s instance with pk %(pk)r does not exist.' на '%(model)s instance with %(field)s %(value)r does not exist.' Если вы используете это сообщение в своем собственном коде, пожалуйста, обновите список интерполируемых параметров. Внутри Django будет продолжать предоставлять параметр pk в params для обратной совместимости.

• UserCreationForm.error_messages['duplicate_username'] больше не используется. Если вы хотите настроить это сообщение об ошибке, override it on the form используйте ключ 'unique' в Meta.error_messages['username'] или, если у вас есть пользовательское поле формы для 'username', используйте ключ 'unique' в его аргументе error_messages.

• Блок usertools в шаблоне base.html шаблона django.contrib.admin теперь требует установки контекстной переменной has_permission. Если у вас есть пользовательские представления администратора, использующие этот шаблон, обновите их, чтобы передать AdminSite.has_permission() в качестве значения этой новой переменной или просто включите AdminSite.each_context(request) в контекст.

• В виджете ClearableFileInput были сделаны внутренние изменения, чтобы обеспечить более широкую настройку. Недокументированный атрибут url_markup_template был удален в пользу template_with_initial.

• Для согласованности с другими крупными производителями, локаль en_GB теперь имеет понедельник в качестве первого дня недели.

• Секунды были удалены из всех локалей, в которых они были в TIME_FORMAT, DATETIME_FORMAT или SHORT_DATETIME_FORMAT.

• Максимальный размер тестового табличного пространства Oracle по умолчанию увеличился с 300M (или 200M, до версии 1.7.2) до 500M.

• reverse() и reverse_lazy() теперь возвращают строки Unicode вместо байтовых строк.

• Псевдоним CacheClass был удален из всех бэкендов кэша. Эти псевдонимы были предоставлены для обратной совместимости с Django 1.3. Если вы все еще используете их, пожалуйста, обновите свой проект, чтобы использовать реальное имя класса, найденное в ключе BACKEND параметра CACHES.

• По умолчанию call_command() теперь всегда пропускает рамки проверки (если только вы не передадите ему skip_checks=False).

• При итерации по строкам File теперь используется universal newlines. Окончание строки распознается следующим образом: соглашение Unix о конце строки '\n', соглашение Windows '\r\n' и старое соглашение Macintosh '\r'.

• Бэкенды кэша Memcached MemcachedCache и PyLibMCCache будут удалять ключ, если set() не работает. Это необходимо для того, чтобы хранилище сессий cache_db всегда получало самые актуальные данные сессии.

• Частные API override_template_loaders и override_with_test_loader в django.test.utils были удалены. Вместо них переопределите TEMPLATES с помощью override_settings.

• Предупреждения от бэкенда базы данных MySQL больше не преобразуются в исключения, когда DEBUG равно True.

• HttpRequest теперь имеет упрощенное repr (например, <WSGIRequest: GET '/somepath/'>). Это не изменит поведение класса SafeExceptionReporterFilter.

• Представления на основе классов, использующие ModelFormMixin, будут вызывать исключение ImproperlyConfigured, если указаны оба атрибута fields и form_class. Ранее fields молча игнорировался.

• При выполнении перенаправлений тестовый клиент теперь поднимает RedirectCycleError, если обнаруживает цикл или достигает максимального предела перенаправления (а не проходит молча).

• Переводимые строки, заданные в качестве параметра default поля, впоследствии приводятся к конкретным строкам, поэтому в некоторых случаях возвращаемый тип Field.get_default() отличается. Значения по умолчанию, которые являются результатом вызываемого поля, не изменяются.

• GenericIPAddressField.empty_strings_allowed теперь False. Бэкенды баз данных, которые интерпретируют пустые строки как null (только Oracle среди бэкендов, которые Django включает), больше не будут преобразовывать нулевые значения обратно в пустую строку. Это соответствует другим бэкендам.

• Когда атрибут BaseCommand.leave_locale_alone имеет значение False, переводы теперь деактивируются вместо принудительной установки локали «en-us». В случае, если ваши модели содержали неанглийские строки и вы рассчитывали на то, что в командах управления будут активированы английские переводы, этого больше не произойдет. Возможно, после перехода на 1.8 создаются новые миграции базы данных (один раз).

• django.utils.translation.get_language() теперь возвращает None вместо LANGUAGE_CODE, когда переводы временно отключены.

• Если для определенного литерала не существует перевода, то обратный перевод теперь берется из языка LANGUAGE_CODE (а не из непереведенного сообщения msgid).

• Поле name в django.contrib.contenttypes.models.ContentType было удалено в результате миграции и заменено свойством. Это означает, что больше нельзя запрашивать или фильтровать ContentType по этому полю.

  Будьте осторожны, если вы переходите на Django 1.8 и пропускаете Django 1.7. Если вы выполните manage.py migrate --fake, эта миграция будет пропущена, и вы увидите исключение RuntimeError: Error creating new content types., поскольку столбец name не будет удален из базы данных. Используйте manage.py migrate --fake-initial, чтобы сымитировать только начальную миграцию.

• Новая опция migrate --fake-initial позволяет подделать начальные миграции. В версии 1.7 начальные миграции всегда автоматически подделывались, если все таблицы, созданные в начальной миграции, уже существовали.

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

Избранные методы в django.db.models.options.Options¶

В рамках формализации API Model._meta (из класса django.db.models.options.Options), ряд методов были устаревшими и будут удалены в Django 1.10:

• get_all_field_names()
• get_all_related_objects()
• get_all_related_objects_with_model()
• get_all_related_many_to_many_objects()
• get_all_related_m2m_objects_with_model()
• get_concrete_fields_with_model()
• get_field_by_name()
• get_fields_with_model()
• get_m2m_with_model()

Загрузка тегов шаблонов cycle и firstof из библиотеки future¶

В Django 1.6 появился синтаксис {% load cycle from future %} и {% load firstof from future %} для совместимости с тегами шаблонов cycle и firstof. Сейчас этот синтаксис устарел и будет удален в Django 1.10. Вы можете просто удалить теги {% load ... from future %}.

django.conf.urls.patterns()¶

В старые добрые времена Django рекомендовалось ссылаться на представления как на строки в urlpatterns:

urlpatterns = patterns('',
    url('^$', 'myapp.views.myview'),
)

и Django волшебным образом импортирует myapp.views.myview внутрь и превратит строку в настоящую ссылку на функцию. Для того чтобы уменьшить количество повторений при обращении ко многим представлениям из одного модуля, функция patterns() принимает необходимый начальный аргумент prefix, который добавляется ко всем представлениям как строкам в этом наборе urlpatterns:

urlpatterns = patterns('myapp.views',
    url('^$', 'myview'),
    url('^other/$', 'otherview'),
)

В современную эпоху мы обновили учебник и теперь рекомендуем импортировать модуль представлений и ссылаться на функции (или классы) представлений напрямую. Это имеет ряд преимуществ, все из которых вытекают из того, что мы используем обычный Python вместо «Django String Magic»: ошибки, когда вы неправильно вводите имя представления, менее непонятны, IDE может помочь с автозаполнением имен представлений и т.д.

Поэтому в наши дни вышеприведенное использование аргумента prefix с гораздо большей вероятностью будет записано (и лучше записано) как:

from myapp import views

urlpatterns = patterns('',
    url('^$', views.myview),
    url('^other/$', views.otherview),
)

Таким образом, patterns() служит мало для чего и является обучением новых пользователей (отвечая на вопрос новичка «зачем мне нужна эта пустая строка в качестве первого аргумента для patterns()?»). По этим причинам мы отказываемся от него. Обновить ваш код так же просто, как убедиться, что urlpatterns является списком экземпляров django.conf.urls.url(). Например:

from django.conf.urls import url
from myapp import views

urlpatterns = [
    url('^$', views.myview),
    url('^other/$', views.otherview),
]

Передача строки в виде view в django.conf.urls.url()¶

В связи с предыдущим пунктом, ссылки на представления как на строки в функции url() устарели. Вместо этого передавайте вызываемое представление, как описано в предыдущем разделе.

Настройки, связанные с шаблоном¶

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

• ALLOWED_INCLUDE_ROOTS
• TEMPLATE_CONTEXT_PROCESSORS
• TEMPLATE_DEBUG
• TEMPLATE_DIRS
• TEMPLATE_LOADERS
• TEMPLATE_STRING_IF_INVALID

django.core.context_processors¶

Встроенные контекстные процессоры шаблонов были перемещены в django.template.context_processors.

django.test.SimpleTestCase.urls¶

Атрибут SimpleTestCase.urls для указания конфигурации URLconf в тестах был устаревшим и будет удален в Django 1.10. Вместо него используйте @override_settings(ROOT_URLCONF=...).

prefix аргумент к i18n_patterns()¶

В связи с предыдущим пунктом, аргумент prefix в django.conf.urls.i18n.i18n_patterns() был устаревшим. Вместо этого просто передавайте список экземпляров django.conf.urls.url().

Использование неправильного подсчета распакованных значений в теге шаблона for¶

Использование неправильного подсчета распакованных значений в теге for вызывает исключение, а не молчаливый отказ в Django 1.10.

Передача точечного пути в reverse() и url¶

Реверсирование URL по пути Python является дорогостоящей операцией, поскольку это приводит к импорту реверсируемого пути. Такое поведение также привело к появлению security issue. Вместо этого используйте named URL patterns для реверсирования.

Если вы используете django.contrib.sitemaps, добавьте аргумент name к url, который ссылается на django.contrib.sitemaps.views.sitemap():

from django.contrib.sitemaps.views import sitemap

url(r'^sitemap\.xml$', sitemap, {'sitemaps': sitemaps},
    name='django.contrib.sitemaps.views.sitemap')

для обеспечения совместимости при реверсировании по пути Python удалена в Django 1.10.

Аналогично для GIS sitemaps добавьте name='django.contrib.gis.sitemaps.views.kml' или name='django.contrib.gis.sitemaps.views.kmz'.

Если вы используете путь Python для настройки LOGIN_URL или LOGIN_REDIRECT_URL, используйте вместо этого имя url().

Агрегатные методы и модули¶

Модули django.db.models.sql.aggregates и django.contrib.gis.db.models.sql.aggregates (оба частные API) были устаревшими, поскольку django.db.models.aggregates и django.contrib.gis.db.models.aggregates теперь также отвечают за генерацию SQL. Старые модули будут удалены в Django 1.10.

Если вы использовали старые модули, смотрите Query Expressions инструкции по переписыванию пользовательских агрегатов с использованием нового стабильного API.

Следующие методы и свойства django.db.models.sql.query.Query также были устаревшими и будут удалены в Django 1.10:

• Query.aggregates, заменяется на annotations.
• Query.aggregate_select, заменяется на annotation_select.
• Query.add_aggregate(), заменяется на add_annotation().
• Query.set_aggregate_mask(), заменяется на set_annotation_mask().
• Query.append_aggregate_mask(), заменяется на append_annotation_mask().

Расширение аргументов команд управления через Command.option_list¶

Команды управления теперь используют argparse вместо optparse для разбора аргументов командной строки, передаваемых командам. Это также означает, что изменился способ добавления пользовательских аргументов в команды: вместо расширения списка классов option_list теперь следует переопределить метод add_arguments() и добавлять аргументы через argparse.add_argument(). Более подробную информацию смотрите в this example.

django.core.management.NoArgsCommand¶

Класс NoArgsCommand сейчас устарел и будет удален в Django 1.10. Вместо него используйте BaseCommand, который по умолчанию не принимает аргументов.

Перечисление всех миграций в проекте¶

Опция --list в команде управления migrate устарела и будет удалена в Django 1.10. Вместо него используйте showmigrations.

cache_choices вариант ModelChoiceField и ModelMultipleChoiceField¶

ModelChoiceField и ModelMultipleChoiceField использовали недокументированную, непроверенную опцию cache_choices. Она кэшировала наборы запросов между несколькими рендерами одного и того же объекта Form. Эта опция подлежит ускоренной депривации и будет удалена в Django 1.9.

django.template.resolve_variable()¶

Эта функция уже некоторое время неофициально помечена как «Устаревшая». Замените resolve_variable(path, context) на django.template.Variable(path).resolve(context).

django.contrib.webdesign¶

В нем был предусмотрен тег шаблона lorem, который теперь включен во встроенные теги. Просто удалите 'django.contrib.webdesign' из INSTALLED_APPS и {% load webdesign %} из ваших шаблонов.

error_message аргумент к django.forms.RegexField¶

Он обеспечивал обратную совместимость с кодом до версии 1.0, но его функциональность является избыточной. Вместо него используйте Field.error_messages['invalid'].

Старый синтаксис unordered_list¶

Старый (до версии 1.0), более строгий и многословный формат ввода для фильтра шаблонов unordered_list был устаревшим:

['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]

Используя новый синтаксис, это становится:

['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]

django.forms.Field._has_changed()¶

Переименуйте этот метод в has_changed(), удалив ведущее подчеркивание. Старое имя будет работать до версии Django 1.10.

django.utils.html.remove_tags() и removetags фильтр шаблонов¶

django.utils.html.remove_tags(), а также шаблонный фильтр removetags были устаревшими, поскольку они не могут гарантировать безопасный вывод. Их существование, скорее всего, приведет к их использованию в чувствительных к безопасности контекстах, где они на самом деле не являются безопасными.

Неиспользуемая и недокументированная функция django.utils.html.strip_entities() также была упразднена.

is_admin_site аргумент к django.contrib.auth.views.password_reset()¶

Это унаследованная опция, в которой больше нет необходимости.

SubfieldBase¶

django.db.models.fields.subclassing.SubfieldBase был устаревшим и будет удален в Django 1.10. Исторически он использовался для обработки полей, где требовалось преобразование типов при загрузке из базы данных, но он не использовался в вызовах .values() или в агрегатах. Он был заменен на from_db_value().

Новый подход не вызывает метод to_python() при присваивании, как это было в случае с SubfieldBase. Если вам нужно такое поведение, перереализуйте класс Creator from Django’s source code в своем проекте.

django.utils.checksums¶

Модуль django.utils.checksums был устаревшим и будет удален в Django 1.10. Функциональность, которую он предоставлял (проверка контрольной суммы по алгоритму Luhn), была недокументирована и не использовалась в Django. Модуль был перемещен в пакет django-localflavor (версия 1.1+).

InlineAdminForm.original_content_type_id¶

Атрибут original_content_type_id на InlineAdminForm был устаревшим и будет удален в Django 1.10. Исторически он использовался для построения URL «view on site». Теперь этот URL доступен с помощью атрибута absolute_url формы.

django.views.generic.edit.FormMixin.get_form() аргумент form_class¶

Подклассы FormMixin, переопределяющие метод get_form(), должны позаботиться о том, чтобы предоставить значение по умолчанию для аргумента form_class, поскольку теперь он необязателен.

Рендеринг шаблонов, загруженных get_template() с помощью Context¶

В Django 1.8 изменился тип возврата get_template(): вместо django.template.Template он возвращает экземпляр Template, точный тип которого зависит от того, какой бэкенд его загрузил.

Оба класса предоставляют метод render(), однако первый принимает в качестве аргумента django.template.Context, а второй ожидает dict. Это изменение вводится в действие через путь обесценивания для шаблонов Django.

Все это также относится и к select_template().

Классы Template и Context в шаблонных ответах¶

Некоторые методы SimpleTemplateResponse и TemplateResponse принимали в качестве аргументов объекты django.template.Context и django.template.Template. Теперь они должны принимать dict и объекты шаблона, зависящего от бэкенда, соответственно.

Это также относится к типам возврата, если вы подклассифицировали любой из классов шаблона ответа.

Подробности смотрите в template response API documentation.

current_app аргумент API, связанных с шаблонами¶

Следующие функции и классы больше не будут принимать параметр current_app для установки пространства имен URL в Django 1.10:

• django.shortcuts.render()
• django.template.Context()
• django.template.RequestContext()
• django.template.response.TemplateResponse()

Вместо этого установите request.current_app, где request - первый аргумент этих функций или классов. Если вы используете обычный Context, используйте вместо него RequestContext.

dictionary и context_instance аргументы функций рендеринга¶

Следующие функции больше не будут принимать параметры dictionary и context_instance в Django 1.10:

• django.shortcuts.render()
• django.shortcuts.render_to_response()
• django.template.loader.render_to_string()

Вместо этого используйте параметр context. Когда dictionary передается как позиционный аргумент, что является наиболее распространенной идиомой, никаких изменений не требуется.

Если вы передаете Context в context_instance, передайте dict в параметре context вместо этого. Если вы передаете RequestContext, передайте запрос отдельно в параметре request.

dirs аргумент функций поиска шаблонов¶

Следующие функции больше не будут принимать параметр dirs для переопределения TEMPLATE_DIRS в Django 1.10:

• django.template.loader.get_template()
• django.template.loader.select_template()
• django.shortcuts.render()
• django.shortcuts.render_to_response()

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

django.template.loader.BaseLoader¶

django.template.loader.BaseLoader был переименован в django.template.loaders.base.Loader. Если вы написали пользовательский загрузчик шаблонов, который наследует BaseLoader, вы должны наследовать Loader вместо него.

django.test.utils.TestTemplateLoader¶

Приватный API django.test.utils.TestTemplateLoader устарел в пользу django.template.loaders.locmem.Loader и будет удален в Django 1.9.

Поддержка аргумента max_length в пользовательских классах Storage¶

Подклассы Storage должны добавить max_length=None в качестве параметра к get_available_name() и/или save(), если они переопределяют любой из методов. Поддержка хранилищ, не принимающих этот аргумент, будет удалена в Django 1.10.

qn заменяется на compiler¶

В предыдущих версиях Django различные внутренние методы ORM (в основном методы as_sql) принимали аргумент qn (для «quote name»), который представлял собой ссылку на функцию, цитирующую идентификаторы для отправки в базу данных. В Django 1.8 этот аргумент был переименован в compiler и теперь является полноценным экземпляром SQLCompiler. Для обратной совместимости, вызов экземпляра SQLCompiler выполняет то же самое цитирование имен, что и функция qn. Однако, этот шим для обратной совместимости немедленно устаревает: вам следует переименовать ваши аргументы qn в compiler, и вызывать compiler.quote_name_unless_alias(...) там, где вы раньше вызывали qn(...).

Значение по умолчанию RedirectView.permanent¶

Значение по умолчанию атрибута RedirectView.permanent изменится с True на False в Django 1.9.

Использование AuthenticationMiddleware без SessionAuthenticationMiddleware¶

django.contrib.auth.middleware.SessionAuthenticationMiddleware был добавлен в Django 1.7. В Django 1.7.2 его функциональность была перенесена в auth.get_user() и, для обратной совместимости, включена только если 'django.contrib.auth.middleware.SessionAuthenticationMiddleware' появляется в MIDDLEWARE_CLASSES.

В Django 1.10 проверка сессии будет включена независимо от того, включена ли SessionAuthenticationMiddleware (в этом случае SessionAuthenticationMiddleware не будет иметь никакого значения). Вы можете добавить ее в MIDDLEWARE_CLASSES как-нибудь до этого момента, чтобы отказаться от участия. Пожалуйста, сначала прочитайте upgrade considerations.

django.contrib.sitemaps.FlatPageSitemap¶

django.contrib.sitemaps.FlatPageSitemap переместился в django.contrib.flatpages.sitemaps.FlatPageSitemap. Старое расположение импорта устарело и будет удалено в Django 1.9.

Модель Field.related¶

Приватный атрибут django.db.models.Field.related устарел в пользу Field.rel. Последний является экземпляром django.db.models.fields.related.ForeignObjectRel, который заменяет django.db.models.related.RelatedObject. Модуль django.db.models.related был удален, а атрибут Field.related будет удален в Django 1.10.

ssi шаблонный тег¶

Тег шаблона ssi позволяет включать файлы в шаблон по абсолютному пути. Это ограниченное применение в большинстве ситуаций развертывания, и тег include часто имеет больше смысла. Этот тег устарел и будет удален в Django 1.10.

= как оператор сравнения в теге шаблона if¶

Использование одиночного знака равенства с тегом шаблона {% if %} для проверки равенства было недокументированным и непроверенным. Теперь оно устарело в пользу ==.

Синтаксис %(<foo>)s в ModelFormMixin.success_url¶

Устаревший синтаксис %(<foo>)s в ModelFormMixin.success_url устарел и будет удален в Django 1.10.

GeoQuerySet агрегатные методы¶

Агрегатные методы collect(), extent(), extent3d(), make_line() и unionagg() устарели и должны быть заменены их агрегатными эквивалентами на основе функций (Collect, Extent, Extent3D, MakeLine и Union).

Сигнатура метода маршрутизатора allow_migrate¶

Подпись метода allow_migrate() маршрутизаторов базы данных изменилась с allow_migrate(db, model) на allow_migrate(db, app_label, model_name=None, **hints).

Если установлено значение model_name, то значение, которое ранее было задано через позиционный аргумент model, теперь можно найти в словаре hints под ключом 'model'.

После перехода на новую сигнатуру маршрутизатор также будет вызываться операциями RunPython и RunSQL.