Примечания к выпуску 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. Вы также должны задокументировать любые особенности модели 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 и MultiLineString GEOS объекты теперь поддерживают 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 :

• Хотя simplejson API задокументирован как всегда возвращающий строки 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.

Email проверка на неудавшемся администратор входа ¶

До 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 expressions filter()
• Не 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() now, вызывает 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() устарели. Вместо этого вы должны использовать имена полей.