- 3.1
- Версия документации: 6.1
Примечания к выпуску Django 6.0¶
3 декабря 2025 г.
Добро пожаловать в Джанго 6.0!
Эти примечания к выпуску охватывают новые функции, а также некоторые обратно несовместимые изменения, о которых вам следует знать при обновлении с Django 5.2 или более ранней версии. Мы начали процесс прекращения поддержки некоторых функций.
См. руководство Обновление Django до новой версии, если вы обновляете существующий проект.
Совместимость версий Python¶
Django 6.0 поддерживает Python 3.12, 3.13 и 3.14. Мы настоятельно рекомендуем и только официально поддерживаем последнюю версию каждой серии.
Серия Django 5.2.x является последней, поддерживающей Python 3.10 и 3.11.
Поддержка сторонних библиотек для старых версий Django¶
После выпуска Django 6.0 мы предлагаем сторонним авторам приложений прекратить поддержку всех версий Django до 5.2. В это время вы сможете запускать тесты вашего пакета с помощью python -Wd, чтобы появлялись предупреждения об устаревании. После исправления предупреждений об устаревании ваше приложение должно быть совместимо с Django 6.0.
Что нового в Джанго 6.0¶
Поддержка политики безопасности контента¶
Теперь доступна встроенная поддержка стандарта Content Security Policy (CSP), что упрощает защиту веб-приложений от атак путем внедрения контента, таких как межсайтовый скриптинг (XSS). CSP позволяет объявлять доверенные источники контента, предоставляя браузерам строгие правила относительно того, какие скрипты, стили, изображения или другие ресурсы можно загружать.
Политики CSP теперь можно применять или отслеживать напрямую с помощью встроенных инструментов: заголовки добавляются через ContentSecurityPolicyMiddleware, одноразовые номера поддерживаются через csp() контекстный процессор, а политики настраиваются с помощью SECURE_CSP и SECURE_CSP_REPORT_ONLY настройки.
Эти настройки принимают словари Python и поддерживают константы, предоставленные Django, для ясности и безопасности. Например:
from django.utils.csp import CSP
SECURE_CSP = {
"default-src": [CSP.SELF],
"script-src": [CSP.SELF, CSP.NONCE],
"img-src": [CSP.SELF, "https:"],
}
Результирующий заголовок Content-Security-Policy будет иметь значение:
default-src 'self'; script-src 'self' 'nonce-SECRET'; img-src 'self' https:
Чтобы начать, следуйте Практическому руководству по CSP. Подробные инструкции см. в Обзоре безопасности CSP и справочной документации, которые включают подробную информацию о декораторах для переопределения или отключения политик для каждого представления.
Части шаблона¶
Язык шаблонов Django <template-language-intro> теперь поддерживает частичные шаблоны <template-partials>, что упрощает инкапсуляцию и повторное использование небольших именованных фрагментов в файле шаблона. Новые теги {% partialdef %} и {% parts %} определяют партиал и отображают его соответственно.
На частичные файлы также можно ссылаться, используя синтаксис template_name#partial_name с get_template(), render(), {% include %} и другими инструментами загрузки шаблонов, что позволяет создавать более модульные и удобные в обслуживании шаблоны без необходимости разделения компонентов на отдельные файлы.
Руководство по миграции доступно, если вы обновляетесь из стороннего пакета django-template-partials.
Фоновые задачи¶
Django теперь включает встроенную платформу Tasks для запуска кода вне цикла HTTP-запрос-ответ. Это позволяет переложить работу, такую как отправка электронных писем или обработка данных, на фоновых работников.
Платформа обеспечивает определение задач, проверку, организацию очереди и обработку результатов. Django гарантирует единообразное поведение при создании задач и управлении ими, при этом ответственность за их выполнение продолжает принадлежать внешним рабочим процессам.
Задачи определяются с помощью декоратора task():
from django.core.mail import send_mail
from django.tasks import task
@task
def email_users(emails, subject, message):
return send_mail(subject, message, None, emails)
После определения задачи могут быть поставлены в очередь через настроенный бэкэнд:
email_users.enqueue(
emails=["user@example.com"],
subject="You have a message",
message="Hello there!",
)
Серверные части настраиваются с помощью параметра TASKS. два встроенных бэкэнда, включенные в этот выпуск, в первую очередь предназначены для разработки и тестирования.
Django занимается созданием и постановкой задач в очередь, но не предоставляет рабочий механизм для запуска задач. Выполнение должно управляться внешней инфраструктурой, например отдельным процессом или службой.
См. Фреймворк задач Django для обзора и Справочник по задачам для получения подробной информации об API.
Внедрение современного API электронной почты Python.¶
Для обработки электронной почты в Django теперь используется современный API электронной почты Python, представленный в Python 3.6. Этот API, основанный на классе email.message.EmailMessage, предлагает более понятный и дружественный к Unicode интерфейс для создания и отправки электронных писем. Он заменяет использование устаревшего API Python (Compat32), который опирался на классы MIME нижнего уровня (из email.mime) и требовал более ручной обработки структуры и кодирования сообщений.
Примечательно, что тип возвращаемого значения метода EmailMessage.message() теперь является экземпляром Python email.message.EmailMessage. Он поддерживает тот же API, что и предыдущие возвращаемые типы SafeMIMEText и SafeMIMEMultipart, но не является экземпляром этих ныне устаревших классов.
Минорные изменения¶
django.contrib.admin¶
Набор значков Font Awesome Free (версия 6.7.2) теперь используется для значков интерфейса администратора.
Новый атрибут
AdminSite.password_change_formпозволяет настроить форму, используемую в представлении изменения пароля сайта администратора.Уровни сообщений
messages.DEBUGиmessages.INFOтеперь имеют отдельные значки и стили CSS. Раньше оба уровня имели тот же внешний вид, что и messages.SUCCESS. Учитывая, чтоModelAdmin.message_user()по умолчанию используетmessages.INFO, установите уровеньmessages.SUCCESS, чтобы сохранить предыдущий значок и стиль.
django.contrib.auth¶
Число итераций по умолчанию для хэшера паролей PBKDF2 увеличено с 1 000 000 до 1 200 000.
django.contrib.gis¶
Новое свойство
GEOSGeometry.hasmпроверяет, имеет ли геометрия размер M.Новая функция базы данных
Rotateвращает геометрию на заданный угол вокруг начала координат или указанной точки.Новый атрибут
BaseGeometryWidget.base_layerпозволяет указать базовый слой карты JavaScript, что позволяет настраивать поставщиков фрагментов карты.coveredbyиisvalid,Collectагрегация иGeoHashиIsValidФункции базы данных теперь поддерживаются в MariaDB 12.0.1+.Новый поиск
geom_typeи функция базы данныхGeometryType()позволяют фильтровать геометрии по их типам.Виджеты из
django.contrib.gis.forms.widgetsтеперь отображаются без встроенного JavaScript в шаблонах. Если вы настроили какие-либо геометрические виджеты или их шаблоны, вам может потребоваться обновить их, чтобы они соответствовали новому макету.
django.contrib.postgres¶
Новое выражение
Lexemeдля полнотекстового поиска обеспечивает детальный контроль над условиями поиска. ОбъектыLexemeавтоматически экранируют вводимые данные и поддерживают операторы логической комбинации (&,|,~), сопоставление префиксов и взвешивание терминов.Поля модели, индексы и ограничения из
django.contrib.postgresтеперь включают системные проверки, чтобы убедиться, что django.contrib.postgres`` является установленным приложением.CreateExtension,BloomExtension,BtreeGinExtension,BtreeGistExtension,CITextExtension,CryptoExtension,HStoreExtension,TrigramExtension, иОперации UnaccentExtensionтеперь поддерживают дополнительный параметрhints. Это позволяет предоставлять подсказки по базе данных маршрутизаторам баз данных, чтобы помочь им принимать решения о маршрутизации.
django.contrib.staticfiles¶
ManifestStaticFilesStorageтеперь обеспечивает согласованный порядок путей в файлах манифеста, делая их более воспроизводимыми и уменьшая ненужные различия.Команда
collectstaticтеперь сообщает только сводную информацию о пропущенных файлах (и об удаленных файлах при использовании--clear) при--verbosity1. Чтобы просмотреть детали каждого файла в любом случае, установите--verbosityравным 2 или выше.
Электронная почта¶
Новый аргумент
policyдляEmailMessage.message()позволяет указать политику электронной почты, набор правил для обновления и сериализации представления сообщения. По умолчанию: data:email.policy.default.EmailMessage.attach()теперь принимает объектMIMEPartиз современного API электронной почты Python.
Интернационализация¶
Добавлена поддержка и перевод гаитянского креольского языка.
Команды управления¶
Команды
startprojectиstartappтеперь создают пользовательский целевой каталог, если он не существует.Общие утилиты, такие как django.conf.settings, теперь по умолчанию автоматически импортируются в оболочку
shell.
Миграции¶
Сжатая миграция теперь может быть подавлена перед переходом к обычной миграции.
Миграции теперь поддерживают сериализацию экземпляров
zoneinfo.ZoneInfo.Сериализация деконструируемых объектов теперь поддерживает аргументы ключевых слов с именами, которые не являются допустимыми идентификаторами Python.
Модели¶
Ограничения теперь реализуют метод
check(), который уже зарегистрирован в системе проверки.Новый аргумент order_by для
Aggregateпозволяет указать порядок элементов в результате.Новый атрибут класса
Aggregate.allow_order_byопределяет, позволяет ли агрегатная функция передавать аргумент ключевого словаorder_by.Новый агрегат
StringAggвозвращает входные значения, объединенные в строку, разделенную строкойdelimiter. Ранее этот агрегат поддерживался только для PostgreSQL.Метод
save()теперь вызывает специализированное исключениеModel.NotUpdated, когда принудительное обновление не приводит к появлению затронутых строк, вместо общегоdjango.db.DatabaseError.QuerySet.raw()теперь поддерживает модели сCompositePrimaryKey.Подзапросы, возвращающие
CompositePrimaryKey, теперь могут использоваться в качестве цели поиска, отличного от__in, например__exact.JSONFieldтеперь поддерживает индексацию отрицательного массива в SQLite.Новый агрегат
AnyValueвозвращает произвольное значение из ненулевых входных значений. Это поддерживается в SQLite, MySQL, Oracle и PostgreSQL 16+.GeneratedFields и полям, которым присвоены выражения, теперь обновляются из базы данных послеsave()на серверных модулях, которые поддерживают предложениеRETURNING(SQLite, PostgreSQL и Oracle). На серверах, которые его не поддерживают (MySQL и MariaDB), поля помечаются как отложенные, чтобы инициировать обновление при последующих обращениях.Использование ForeignObject с несколькими
from_fieldsв индексах модели, ограничениях илиunique_togetherтеперь вызывает ошибку проверки системы.
Пагинация¶
Новые
AsyncPaginatorиAsyncPageпредоставляют асинхронные реализацииPaginatorиPageсоответственно.
Запросы и ответы¶
Теперь для запросов HTTP/2 при работе с ASGI поддерживаются несколько заголовков Cookie.
Шаблоны¶
Новая переменная forloop.length теперь доступна в цикле
for.Тег шаблона
querystringтеперь последовательно добавляет к возвращаемой строке запроса префикс?, обеспечивая надежное создание ссылок.Тег шаблона
querystringтеперь принимает несколько позиционных аргументов, которые должны быть сопоставлениями, напримерQueryDictилиdict.
Тесты¶
DiscoverRunnerтеперь поддерживает параллельное выполнение тестов в системах с использованием метода запускаforkservermultiprocessing.
Изменения обратной несовместимости в версии 6.0¶
Серверный API базы данных¶
В этом разделе описаны изменения, которые могут потребоваться в сторонних базах данных.
BaseDatabaseSchemaEditorи серверные части PostgreSQL больше не используютCASCADEпри удалении столбца.Методы DatabaseOperations.return_insert_columns() и DatabaseOperations.fetch_returned_insert_rows() переименованы в return_columns() и fetch_returned_rows() соответственно, чтобы обозначить, что их можно использовать в контексте операторов UPDATE… RETURNING, а также INSERT… RETURNING.
Метод
DatabaseOperations.fetch_returned_insert_columns()удален, а методfetch_returned_rows(), заменяющийfetch_returned_insert_rows(), ожидает предоставления какcursor, так иreturning_params, точно так же, как это сделалfetch_returned_insert_columns().Если база данных поддерживает операторы
UPDATE… RETURNING, серверные части могут установитьDatabaseFeatures.can_return_rows_from_update=True.
Прекращена поддержка MariaDB 10.5.¶
Восходящая поддержка MariaDB 10.5 заканчивается в июне 2025 года. Django 6.0 поддерживает MariaDB 10.6 и выше.
Прекращена поддержка Python <3.12.¶
Поскольку Python 3.12 теперь является минимально поддерживаемой версией для Django, любые дополнительные зависимости также должны соответствовать этому требованию. Следующие версии каждой библиотеки первыми добавляют или подтверждают совместимость с Python 3.12:
aiosmtpd1.4.5argon2-cffi23.1.0bcrypt4.1.1документы0.22geoip24.8.0Подушка10.1.0mysqlclient2.2.1numpy1.26.0PyYAML6.0.2псикопг3.1.12psycopg22.9.9redis-py5.1.0селен4.23.0sqlparse0.5.0tblib3.0.0
Электронная почта¶
Недокументированные свойства
mixed_subtypeиalternative_subtypeEmailMessageиEmailMultiAlternativesбольше не поддерживаются.Недокументированное свойство encoding объекта
EmailMessageбольше не поддерживает устаревшие объектыemail.charset.CharsetPython.Поскольку внутренние реализации
EmailMessageиEmailMultiAlternativesзначительно изменились, внимательно изучите все пользовательские подклассы, которые полагаются на переопределение недокументированных внутренних методов подчеркивания.
Параметр DEFAULT_AUTO_FIELD теперь по умолчанию имеет значение BigAutoField.¶
Начиная с Django 3.2, когда был добавлен параметр DEFAULT_AUTO_FIELD, файл settings.py шаблона startproject по умолчанию содержал:
DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField"
и шаблон AppConfig по умолчанию startapp содержал:
default_auto_field = "django.db.models.BigAutoField"
В то время значение по умолчанию DEFAULT_AUTO_FIELD оставалось django.db.models.AutoField для обратной совместимости.
В Django 6.0 DEFAULT_AUTO_FIELD теперь по умолчанию имеет значение django.db.models.BigAutoField, а вышеупомянутые строки в шаблонах проекта и приложения удалены.
На большинство проектов это не повлияет, поскольку Django 3.2 выдает предупреждение проверки системы models.W042 для проектов, в которых не установлено DEFAULT_AUTO_FIELD.
Если вы еще не разобрались с этим предупреждением, добавьте DEFAULT_AUTO_FIELD = „django.db.models.AutoField“` в настройки вашего проекта или default_auto_field = 'django.db.models.AutoField' в AppConfig приложения, если необходимо.
Пользовательские выражения ORM должны возвращать параметры в виде кортежа.¶
До Django 6.0 пользовательские запросы и пользовательские выражения, реализующие метод as_sql() (и поддерживающие его методы process_lhs() и process_rhs()), позволяли возвращать последовательность параметров в виде списка или кортежа. Чтобы решить возникшие проблемы совместимости, второй возвращаемый элемент метода as_sql() теперь должен быть кортежем:
def as_sql(self, compiler, connection) -> tuple[str, tuple]: ...
Если ваши пользовательские выражения поддерживают несколько версий Django, вам следует настроить любую предварительную обработку параметров, чтобы она была устойчивой к кортежам или спискам. Например, предпочтительнее распаковывать следующим образом:
params = (*lhs_params, *rhs_params)
Разнообразный¶
Сериализатор JSON теперь записывает новую строку в конце вывода, даже без установленной опции
indent.Минимальная поддерживаемая версия asgiref увеличена с 3.8.1 до 3.9.1.
Функции, устаревшие в версии 6.0¶
Позиционные аргументы в API django.core.mail¶
django.core.mail API теперь требуют аргументы ключевых слов для менее часто используемых параметров. Использование позиционных аргументов для них теперь выдает предупреждение об устаревании и вызывает TypeError, когда период устаревания заканчивается:
Все необязательные параметры (
fail_sillyи более поздние версии) должны передаваться в качестве аргументов ключевых слов вget_connection(),mail_admins(),mail_managers(),send_mail()иsend_mass_mail().Все параметры должны передаваться в качестве аргументов ключевого слова при создании экземпляра
EmailMessageилиEmailMultiAlternatives, за исключением первых четырех («subject»,body,from_emailиto), которые по-прежнему могут передаваться либо как позиционные аргументы, либо как аргументы ключевого слова.
Разнообразный¶
BaseDatabaseCreation.create_test_db(serialize)устарел. Вместо этого используйтеserialize_db_to_string().Класс PostgreSQL StringAgg устарел в пользу общедоступного класса
StringAgg.PostgreSQL
OrderableAggMixinустарел в пользу атрибутаorder_by, который теперь доступен в классеAggregate.Протокол по умолчанию в
urlizeиurlizetrncизменится с HTTP на HTTPS в Django 7.0. Установите для переходного параметраURLIZE_ASSUME_HTTPSзначениеTrue, чтобы включить использование HTTPS во время цикла выпуска Django 6.x.Переходная настройка
URLIZE_ASSUME_HTTPSустарела.Установка
ADMINSилиMANAGERSдля списка кортежей (имя, адрес) устарела. Вместо этого установите список строк адресов электронной почты. Джанго никогда не использовал часть имени. Чтобы включить имя, отформатируйте строку адреса как ``„«Name» <address>“` или используйте Pythonemail.utils.formataddr().Поддержка аргумента
orphans, превышающего или равного аргументуper_pageдляdjango.core.paginator.Paginatorиdjango.core.paginator.AsyncPaginator, устарела.Использование знака процента в псевдониме столбца или аннотации не рекомендуется.
Поддержка передачи устаревшего объекта электронной почты Python
MIMEBaseвEmailMessage.attach()(или включение одного из них в списоквложенийсообщения) устарела. Для сложных вложений, требующих дополнительных заголовков или параметров, переключитесь на современный API электронной почтыMIMEPart.Исключение django.core.mail.BadHeaderError устарело. Современная электронная почта Python выдает ошибку
ValueErrorдля заголовков электронной почты, содержащих запрещенные символы.Классы django.core.mail.SafeMIMEText и SafeMIMEMultipart устарели.
Недокументированные функции django.core.mail.forbid_multi_line_headers() и django.core.mail.message.sanitize_address() считаются устаревшими.
Функции удалены в версии 6.0¶
Эти функции достигли конца цикла устаревания и удалены в Django 6.0.
См. Функции, устаревшие в версии 5.0 для получения подробной информации об этих изменениях, в том числе о том, как прекратить использование этих функций.
Поддержка передачи позиционных аргументов в BaseConstraint удалена.
Средства визуализации переходных форм DjangoDivFormRenderer и Jinja2DivFormRenderer удалены.
BaseDatabaseOperations.field_cast_sql()удален.requestтребуется в сигнатуре подклассовModelAdmin.lookup_allowed().Поддержка вызова
format_html()без передачи аргументов или kwargs удалена.Схема по умолчанию для form.URLField изменилась с «http» на «https».
Переходный параметр FORMS_URLFIELD_ASSUME_HTTPS удален.
django.db.models.sql.datastructures.Joinбольше не возвращается кget_joining_columns().Метод
get_joining_columns()дляForeignObjectиForeignObjectRelудален.Метод ForeignObject.get_reverse_joining_columns() удален.
Поддержка cx_Oracle удалена.
Псевдоним ChoicesMeta для django.db.models.enums.ChoicesType удален.
Метод Prefetch.get_current_queryset() удален.
Метод get_prefetch_queryset() связанных менеджеров и дескрипторов удален.
get_prefetcher()иprefetch_related_objects()больше не возвращаются кget_prefetch_queryset().
См. Функции, устаревшие в версии 5.1 для получения подробной информации об этих изменениях, в том числе о том, как прекратить использование этих функций.
django.urls.register_converter()больше не позволяет переопределять существующие конвертеры.Методы ModelAdmin.log_deletion() и LogEntryManager.log_action() удалены.
Недокументированная функция django.utils.itercompat.is_iterable() и модуль django.utils.itercompat удалены.
Метод django.contrib.gis.geoip2.GeoIP2.coords() удален.
Метод django.contrib.gis.geoip2.GeoIP2.open() удален.
Поддержка передачи позиционных аргументов в Model.save() и Model.asave() удалена.
Удален установщик django.contrib.gis.gdal.OGRGeometry.coord_dim.
Аргумент ключевого слова
checkвCheckConstraintудален.Метод get_cache_name() в FieldCacheMixin удален.
Атрибут
OS_OPEN_FLAGSFileSystemStorageудален.