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

Поддержка Python 3 ¶

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

Тем не менее, мы пока называем эту поддержку «экспериментальной»: хотя она прошла обширное тестирование с помощью нашего автоматизированного набора тестов, она получила очень мало реальных тестов. Мы сделали все возможное, чтобы устранить ошибки, но мы не можем быть уверены, что охватили все возможные варианты использования Django.

Некоторые функции Django недоступны, потому что они зависят от стороннего программного обеспечения, которое еще не было перенесено на Python 3, в том числе:

• бэкэнд базы данных MySQL (зависит от MySQLdb)
• ImageField (зависит от PIL)
• LiveServerTestCase (зависит от Selenium WebDriver)

Кроме того, Django - это больше, чем просто веб-фреймворк; это экосистема подключаемых компонентов. На данный момент очень мало сторонних приложений было перенесено на Python 3, поэтому маловероятно, что в реальном приложении все его зависимости будут удовлетворены под Python 3.

Таким образом, мы рекомендуем не использовать Django 1.5 в производственной среде под Python 3. Вместо этого используйте эту возможность, чтобы начать перенос приложений на Python 3. Если вы являетесь автором подключаемого компонента, мы рекомендуем вам начать перенос прямо сейчас.

Мы планируем предложить первоклассную, готовую к работе поддержку Python 3 в нашем следующем выпуске, Django 1.6.

Настраиваемая модель пользователя ¶

В Django 1.5 теперь вы можете использовать свою собственную модель в качестве хранилища пользовательских данных. Если вашему проекту требуется имя пользователя, содержащее более 30 символов, или если вы хотите сохранить имена пользователей в формате, отличном от имени / фамилии, или вы хотите поместить информацию о пользовательском профиле в свой объект «Пользователь», вы можете это сделать.

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

Дополнительную информацию см. В документации по пользовательским моделям .

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

У метода Model.save()есть новый аргумент ключевого слова update_fields. Используя этот аргумент, можно сохранить только выбранный список полей модели. Это может быть полезно по соображениям производительности или при попытке избежать перезаписи одновременных изменений.

Отложенные экземпляры (загруженные с помощью .only()или .defer()) автоматически сохранят только загруженные поля. Если какое-либо поле установлено вручную после загрузки, это поле также будет обновлено при сохранении.

Смотрите Model.save()документацию для более подробной информации.

Кеширование связанных экземпляров модели ¶

При обходе отношений ORM избегает повторной выборки ранее загруженных объектов. Например, с моделями учебника:

>>> first_poll = Poll.objects.all()[0]
>>> first_choice = first_poll.choice_set.all()[0]
>>> first_choice.poll is first_poll
True

В Django 1.5 третья строка больше не запускает новый запрос SQL для выборки first_choice.poll; он был задан второй строкой.

Для взаимно-однозначных отношений обе стороны могут быть кэшированы. Для отношений "многие к одному" можно кэшировать только одну сторону связи. Это особенно полезно в сочетании с prefetch_related.

Явная поддержка потоковой передачи ответов ¶

До Django 1.5 можно было создать потоковый ответ, передав итератор в HttpResponse. Но это было ненадежно: любое промежуточное ПО, обращающееся к content атрибуту, преждевременно потребляло бы итератор.

Теперь вы можете явно сгенерировать потоковый ответ с новым StreamingHttpResponseклассом. Этот класс предоставляет streaming_contentатрибут, который является итератором.

Поскольку у StreamingHttpResponseнего нет content атрибута, промежуточное ПО, которому требуется доступ к содержимому ответа, должно проверять потоковую передачу ответов и вести себя соответствующим образом.

{% verbatim %}тег шаблона ¶

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

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

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

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

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

GeoDjango ¶

• LineStringи MultiLineStringGEOS объекты теперь поддерживают interpolate()и project()методы (так называемые линейные ссылки).
• Это wkbи hexсвойство GEOSGeometryобъектов сохраняет размерность Z.
• Добавлена ​​поддержка PostGIS 2.0 и прекращена поддержка GDAL <1.5.

Новые уроки ¶

Дополнения к документации включают обновленный Учебник 3 и новый учебник по тестированию . В новом разделе «Расширенные учебные пособия» предлагается Как писать многоразовые приложения, а также пошаговое руководство для новых участников в разделе « Написание вашего первого патча для Django» .

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

Django 1.5 также включает несколько небольших улучшений, на которые стоит обратить внимание:

• Шаблон двигатель теперь интерпретирует True, Falseи Noneкак объекты , соответствующие Python.

• django.utils.timezoneпредоставляет помощника для преобразования известных значений даты и времени между часовыми поясами. Смотрите localtime().

• Общие представления поддерживают запросы OPTIONS.

• Команды управления больше не запускаются SystemExitпри вызове кодом из call_command(). Любое исключение, вызванное командой (в основном CommandError), распространяется.

  Более того, когда вы выводите ошибки или сообщения в своих пользовательских командах, теперь вы должны использовать self.stdout.write('message')и self.stderr.write('error')(см. Примечание о выводе команд управления ).

• Команда dumpdataуправления выводит по одной строке за раз, предотвращая ошибки нехватки памяти при выгрузке больших наборов данных.

• В местном стиле для Канады «pq» был добавлен к допустимым кодам для Квебека. Это старое сокращение.

• Приемник декоратор теперь может подключаться к более чем один сигналу путем подачи списка сигналов.

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

• QuerySet.bulk_create()теперь имеет аргумент batch_size. По умолчанию размер batch_size не ограничен, за исключением SQLite, где один пакет ограничен, так что 999 параметров на запрос не превышаются.

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

• Django теперь предоставляет обработчик аутентификации mod_wsgi .

• Теперь QuerySet.delete() и Model.delete()в некоторых случаях можно использовать ускоренный путь. Быстрый путь позволяет выполнять меньше запросов и извлекать меньше объектов в память. См. QuerySet.delete()Подробности.

• Экземпляр ResolverMatchсохраняется в запросе как resolver_match.

• По умолчанию все лесозаготовительные сообщения , достигающие djangoрегистратор , когда DEBUGесть Trueпосылаются на консоль (если не переопределять регистратора в вашей LOGGINGустановки).

• При использовании RequestContextтеперь можно просматривать разрешения с помощью шаблонов.{% if 'someapp.someperm' in perms %}

• Это больше не требуется иметь 404.htmlи 500.htmlшаблоны в корневом каталоге шаблонов. Django выдаст несколько основных сообщений об ошибках для обеих ситуаций, когда эти шаблоны не найдены. По-прежнему рекомендуется предоставлять эти шаблоны, чтобы пользователи могли видеть красивые страницы с ошибками.

• django.contrib.authпредоставляет новый сигнал, который излучается всякий раз, когда пользователю не удается успешно войти в систему. Видеть user_login_failed

• Новая опция игнорирует данные для полей, которые больше не существуют.loaddata --ignorenonexistent

• assertXMLEqual()а assertXMLNotEqual()новые утверждения позволяют проверять равенство содержимого XML на семантическом уровне, не обращая внимания на синтаксические различия (пробелы, порядок атрибутов и т. д.).

• RemoteUserMiddleware теперь принудительно завершает сеанс, когда заголовок REMOTE_USER исчезает во время того же сеанса браузера.

• Кэш на основе сеанса бэкенд может хранить данные сеанса в кэше не по умолчанию.

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

• Во время настройки журналирования Django включены подробные предупреждения об устаревании, и предупреждения фиксируются в системе журналирования. Записанные в журнал предупреждения маршрутизируются через consoleобработчик журналирования, который по умолчанию требует, DEBUGчтобы он имел значение True для создания вывода. В результате DeprecationWarnings должны выводиться на консоль в средах разработки, как это было в версиях Python <2.7.

• API для django.contrib.admin.ModelAdmin.message_user()метода был изменен, чтобы принимать дополнительные аргументы, добавляя возможности, аналогичные django.contrib.messages.add_message(). Это полезно для создания сообщений об ошибках от действий администратора.

• Фильтры списка администратора теперь можно настраивать для каждого запроса благодаря новому django.contrib.admin.ModelAdmin.get_list_filter()методу.

ALLOWED_HOSTSтребуется в производстве ¶

Новый ALLOWED_HOSTSпараметр проверяет Host заголовок запроса и защищает от атак с отравлением хоста. Этот параметр теперь требуется всякий раз , когда он DEBUGесть False, иначе он django.http.HttpRequest.get_host()будет повышаться SuspiciousOperation. Для получения дополнительных сведений см. Новую настройку.full documentation

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

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

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

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

Для согласованности с другими базовыми представлениями, основанными на дате, YearArchiveViewтеперь передается yearв контексте как, datetime.dateа не как строка. Если вы используете в своих шаблонах, вы должны заменить его на .{{ year }}{{ year|date:"Y" }}

next_yearа previous_yearтакже были добавлены в контекст. Они рассчитываются по allow_emptyи allow_future.

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

YearArchiveViewи MonthArchiveViewбыли задокументированы для обеспечения date_listсортировки по возрастанию в контексте, как и их предшественники, основанные на функциях, но на самом деле это было в порядке убывания. В 1.5 документальный порядок был восстановлен. Вы можете добавить (или удалить) reversedключевое слово при повторении date_listв шаблоне:

{% for date in date_list reversed %}

ArchiveIndexViewпо-прежнему предоставляет date_listв порядке убывания.

Контекст в TemplateView ¶

Для согласованности с дизайном других общих представлений словарь TemplateViewбольше не передается paramsв контекст, вместо этого передаются переменные из URLconf непосредственно в контекст.

Неформальные данные в HTTP-запросах ¶

request.POSTбольше не будет включать в заголовок данные, отправленные через HTTP-запросы с типами содержимого, не зависящими от формы. В предыдущих версиях данные, отправленные с типами содержимого, отличными от multipart / form-data или application / x-www-form-urlencoded , по-прежнему будут представлены в request.POSTатрибуте. Разработчики, желающие получить доступ к необработанным данным POST для этих случаев, должны request.bodyвместо этого использовать атрибут.

request_finishedсигнал ¶

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

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

Запросы OPTIONS, PUT и DELETE в тестовом клиенте ¶

В отличие от GET и POST, эти HTTP-методы не реализуются веб-браузерами. Скорее, они используются в API, которые передают данные в различных форматах, таких как JSON или XML. Поскольку такие запросы могут содержать произвольные данные, Django не пытается декодировать их тело.

Однако тестовый клиент использовался для создания строки запроса для запросов OPTIONS и DELETE, как для GET, и тела запроса для запросов PUT, как для POST. Эта кодировка была произвольной и несовместимой с поведением Django при получении запросов, поэтому она была удалена в Django 1.5.

Если вы использовали dataпараметр в запросе OPTIONS или DELETE, вы должны преобразовать его в строку запроса и добавить к pathпараметру.

Если вы использовали dataпараметр в запросе PUT без a content_type, вы должны закодировать свои данные перед их передачей в тестовый клиент и установить content_typeаргумент.

Системная версия simplejsonбольше не используется ¶

Как объясняется ниже , Django 1.5 устарел django.utils.simplejsonв пользу встроенногоjson модуляPython 2.6. Теоретически это изменение безвредно. К сожалению, из-за несовместимости версийsimplejsonв некоторых случаях это может вызвать ошибки.

Функции, связанные с JSON, в Django 1.4 используются всегда django.utils.simplejson. Этот модуль на самом деле был:

• Системная версия simplejson, если она была доступна (т. Е. Работает), если она была более поздней, чем встроенная копия Django, или у нее были ускорения C, илиimport simplejson
• jsonМодуль из стандартной библиотеки, если она была доступна (то есть. Python 2.6 или выше), или
• Встроенная копия версии 2.0.7 оф simplejson.

В Django 1.5 эти функции используют jsonмодуль Python , основанный на версии 2.0.9 из simplejson.

Нет известных несовместимостей между копией Django версии 2.0.7 и копией Python версии 2.0.9. Однако есть некоторые несовместимости между другими версиями simplejson:

• Хотя simplejsonAPI задокументирован как всегда возвращающий строки Unicode, необязательная реализация C может возвращать байтовую строку. Это было исправлено в Python 2.7.
• simplejson.JSONEncoderполучил namedtuple_as_objectаргумент ключевого слова в версии 2.2.

Более подробная информация об этих несовместимостях доступна в билете №18023 .

В конечном итоге, если вы установили simplejsonи ваш код напрямую использует внутренние компоненты сериализации Django - например django.core.serializers.json.DjangoJSONEncoder, переключение с simplejsonна jsonможет нарушить ваш код. (Как правило, внутренние изменения не документируются; мы делаем здесь исключение.)

На данный момент разработчики Django считают, что использование jsonстандартной библиотеки дает самую надежную гарантию обратной совместимости. Они рекомендуют использовать его отныне.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Десериализатор XML не будет анализировать документы с DTD ¶

Чтобы предотвратить атаки типа «отказ в обслуживании», связанные со ссылками на внешние сущности и расширением сущностей, десериализатор модели XML теперь отказывается анализировать документы XML, содержащие DTD (определение DOCTYPE). Поскольку XML-сериализатор не выводит DTD, это не повлияет на типичное использование, только в тех случаях, когда пользовательские XML-документы передаются десериализатору модели Django.

Формы по умолчанию max_num¶

Значение (по умолчанию) Noneдля max_numаргумента фабрики набора форм больше не разрешает по умолчанию любое количество форм в наборе форм. Вместо этого, чтобы предотвратить атаки с истощением памяти, теперь по умолчанию установлено ограничение в 1000 форм. Этот предел можно увеличить, явно установив более высокое значение для max_num.

Разное ¶

• django.forms.ModelMultipleChoiceFieldтеперь возвращает пустое значение QuerySetкак пустое значение вместо пустого списка.
• int_to_base36()правильно поднимает a TypeErrorвместо ValueErrorнецелочисленных входов.
• slugifyШаблон фильтр теперь доступен в качестве стандартной функции Python в django.utils.text.slugify(). Точно так же remove_tagsдоступно по адресу django.utils.html.remove_tags().
• Загруженные файлы больше не создаются как исполняемые по умолчанию. Если вам нужно, чтобы они были исполняемыми, измените их FILE_UPLOAD_PERMISSIONSпод свои нужды. Новое значение по умолчанию 0o666(восьмеричное), а текущее значение umask сначала замаскировано.
• Эти поддерживаемые битовые операции по и . Эти операторы теперь доступны с использованием и . Удаление и было сделано для согласования с выражениями Q () и объединения, в котором операторы используются как логические операторы И и ИЛИ.F expressions&|.bitand().bitor()&|QuerySet
• В filter()вызове, когда он содержит поисковые запросы, охватывающие многозначные отношения, они не всегда повторно используют те же отношения, что и другие поисковые запросы в той же цепочке. Это было изменено, и теперь выражения F () всегда будут использовать те же отношения, что и другие поисковые запросы в одном и том же вызове.F expressionsfilter()
• Не csrf_tokenшаблонный тег больше не заключен в делах. Если вам нужна проверка HTML по сравнению со строгими DTD до HTML5, вы должны добавить вокруг него на своих страницах div.
• Библиотека шаблонных тегов adminmedia, которая содержала только устаревший тег шаблона , была удалена. Попытка загрузить его не удастся. Если ваши шаблоны все еще содержат эту строку, вы должны удалить ее.{% admin_media_prefix %}{% load adminmedia %}
• Из-за надзора за реализацией можно было использовать django.contrib.redirects без включения django.contrib.sites . Это больше не разрешено. Если вы используете django.contrib.redirects, убедитесь, что он INSTALLED_APPSсодержит django.contrib.sites.
• BoundField.label_tagтеперь ускользает от своего contentsаргумента. Чтобы избежать экранирования HTML, используйте django.utils.safestring.mark_safe()аргумент перед его передачей.
• Доступ к обратным однозначным отношениям, полученным через select_related()теперь, вызывает DoesNotExistвместо возврата None.

django.contrib.localflavor¶

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

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

django.contrib.markup¶

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

AUTH_PROFILE_MODULE¶

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

Вы по-прежнему можете определять модели профилей пользователей, которые имеют однозначное отношение к модели User - фактически, для многих приложений, которым необходимо связать данные с учетной записью пользователя, это будет подходящим шаблоном проектирования, которому следует следовать. Однако AUTH_PROFILE_MODULEнастройки и django.contrib.auth.models.User.get_profile()метод доступа к модели профиля пользователя больше не должны использоваться.

Потоковое поведение ¶HttpResponse

Django 1.5 не поддерживает возможность потоковой передачи ответа путем передачи итератора в HttpResponse. Если вы полагаетесь на это поведение, переключитесь на StreamingHttpResponse. См. Раздел Явная поддержка потоковых ответов выше.

В Django 1.7 и выше итератор будет немедленно использован HttpResponse.

django.utils.simplejson¶

Поскольку Django 1.5 отказывается от поддержки Python 2.5, теперь мы можем полагаться на то, что jsonмодуль доступен в стандартной библиотеке Python, поэтому мы удалили нашу собственную копию simplejson. Теперь вы должны импортировать json вместо django.utils.simplejson.

К сожалению, это изменение может иметь нежелательные побочные эффекты из-за несовместимости между версиями simplejson- см. Раздел об изменениях, несовместимых с предыдущими версиями . Если вы полагаетесь на функции, добавленные simplejsonпосле того, как он стал Python json, вам следует импортировать его simplejsonявно.

django.utils.encoding.StrAndUnicode¶

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

django.utils.itercompat.product¶

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

cleanupкоманда управления ¶

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

daily_cleanup.pyскрипт ¶

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

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

depthКлючевое слово аргумента в select_related()устарели. Вместо этого вы должны использовать имена полей.