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

Представления на основе классов ¶

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

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

Дополнительные сведения см. В документации по универсальным представлениям на основе классов . Существует также документ, который поможет вам преобразовать общие представления на основе функций в представления на основе классов .

Ведение журнала ¶

В Django 1.3 добавлена ​​поддержка logging модуля Python на уровне инфраструктуры . Это означает, что теперь вы можете легко настраивать и контролировать ведение журнала как часть вашего проекта Django. В собственный код Django также был добавлен ряд обработчиков журналов и вызовов журналирования - в первую очередь, сообщения об ошибках, отправленные при ошибке сервера HTTP 500, теперь обрабатываются как действия журналирования. См. Документацию по интерфейсу журналирования Django для получения более подробной информации.

Расширенная обработка статических файлов ¶

Django 1.3 поставляется с новым приложением contrib django.contrib.staticfiles - чтобы помочь разработчикам обрабатывать статические мультимедийные файлы (изображения, CSS, JavaScript и т. Д.), Необходимые для рендеринга веб-страницы.

В предыдущих версиях Django было принято размещать статические ресурсы MEDIA_ROOT вместе с загруженными пользователем файлами и обслуживать их оба в MEDIA_URL . Частично цель внедрения staticfiles приложения - упростить хранение статических файлов отдельно от файлов, загруженных пользователем. Статические ресурсы теперь должны находиться в static/ подкаталогах ваших приложений или в других каталогах статических ресурсов, перечисленных в STATICFILES_DIRS , и будут обслуживаться в STATIC_URL .

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

unittest2 поддержка ¶

Python 2.7 внес в unittest библиотеку несколько важных изменений , добавив несколько чрезвычайно полезных функций. Чтобы гарантировать, что каждый проект Django может воспользоваться этими новыми функциями, Django поставляется с копией unittest2 , копией unittest библиотеки Python 2.7 , перенесенной для совместимости с Python 2.4.

Для доступа к этой библиотеке Django предоставляет django.utils.unittest псевдоним модуля. Если вы используете Python 2.7 или установили его unittest2 локально, Django сопоставит псевдоним с установленной версией unittest библиотеки. В противном случае Django будет использовать собственную версию unittest2 .

Чтобы воспользоваться этим псевдонимом, просто используйте:

from django.utils import unittest

везде, где вы исторически использовали:

import unittest

Если вы хотите продолжать использовать базовую unittest библиотеку, вы можете - вы просто не получите ни одной из хороших новых unittest2 функций.

Менеджеры контекста транзакции ¶

Пользователи Python 2.5 и выше теперь могут использовать функции управления транзакциями в качестве менеджеров контекста. Например:

with transaction.autocommit():
    # ...

Настраиваемый каскад удаления ¶

ForeignKey и OneToOneField теперь примите on_delete аргумент для настройки поведения при удалении указанного объекта. Раньше удаления всегда выполнялись каскадно; доступные альтернативы теперь включают установку нуля, установку по умолчанию, установку любого значения, защиту или бездействие.

Для получения дополнительной информации см. on_delete Документацию.

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

Для строк перевода с неоднозначным значением теперь можно использовать pgettext функцию, чтобы указать контекст строки.

И если вы просто хотите добавить некоторую информацию для переводчиков, вы также можете добавить специальные комментарии переводчика в источник.

Дополнительные сведения см. В разделе Контекстные маркеры и комментарии для переводчиков .

Улучшения встроенных тегов шаблонов ¶

Во встроенные теги шаблонов Django был внесен ряд улучшений:

• include Теперь тег принимает with параметр, позволяющий указать переменный контекст к прилагаемому шаблону
• include Тег теперь принимает only параметр, что позволяет исключить текущий контекст из включенного контекста
• with Теперь тег позволяет определить несколько переменных контекста в одном with блоке.
• Теперь load тег принимает from аргумент, позволяющий загружать один тег или фильтр из библиотеки.

TemplateResponse ¶

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

Однако вы не можете (легко) изменить содержимое базового файла HttpResponse после его создания. Чтобы преодолеть это ограничение, Django 1.3 добавляет новый TemplateResponse класс. В отличие от базовых HttpResponse объектов, TemplateResponse объекты сохраняют детали шаблона и контекста, которые были предоставлены представлением для вычисления ответа. Окончательный результат ответа не вычисляется до тех пор, пока он не понадобится позже в процессе ответа.

Подробнее см. Документацию по TemplateResponse классу.

Кеширование изменений ¶

В Django 1.3 было внесено несколько улучшений в инфраструктуру кэширования Django.

Во-первых, Django теперь поддерживает несколько именованных кешей. Так же, как Django 1.2 представил поддержку нескольких подключений к базе данных, Django 1.3 позволяет вам использовать новый CACHES параметр для определения нескольких именованных подключений к кешу.

Во- вторых, управление версиями , на веб-узле префиксов и преобразования , которые были добавлены в API кэша.

В-третьих, создание ключа кэша было обновлено, чтобы учитывать строку запроса запроса при GET запросах.

Наконец, в бэкэнд кеширования memcached была добавлена поддержка pylibmc .

Подробнее см. В документации по кешированию в Django .

Разрешения для неактивных пользователей ¶

Если вы предоставите настраиваемый бэкэнд аутентификации, для которого supports_inactive_user установлено значение True , неактивный User экземпляр будет проверять бэкэнд на наличие разрешений. Это полезно для дальнейшей централизации обработки разрешений. См. Дополнительную информацию в документации по аутентификации .

GeoDjango ¶

Набор тестов GeoDjango теперь включен при запуске набора тестов Django с runtests.py использованием бэкэндов пространственной базы данных .

MEDIA_URL и STATIC_URL должен заканчиваться косой чертой ¶

Раньше для этого MEDIA_URL параметра требовалась косая черта в конце, только если он содержал суффикс помимо имени домена.

Теперь для новой настройки требуется завершающая косая черта, если она не пуста. Это гарантирует, что существует единообразный способ комбинирования путей в шаблонах.MEDIA_URL STATIC_URL

Настройки проекта, которые предоставляют любую из обеих настроек без косой черты в конце, теперь будут вызывать расширение PendingDeprecationWarning .

В Django 1.4 возникнет это же условие DeprecationWarning , а в Django 1.5 возникнет ImproperlyConfigured исключение.

Все остальное ¶

Django 1.1 и 1.2 добавили в Django множество важных элементов, таких как поддержка нескольких баз данных, проверка модели и структура сообщений на основе сеансов. Однако сосредоточение внимания на больших функциях произошло за счет множества более мелких функций.

Чтобы компенсировать это, в процессе разработки Django 1.3 основное внимание уделялось добавлению множества небольших, давно существующих запросов на функции. Это включает:

• Улучшенные инструменты для доступа и управления текущим Site объектом в структуре сайтов .
• А RequestFactory для издевательства над запросами в тестах.
• Новое тестовое утверждение assertNumQueries() - упрощающее тестирование активности базы данных, связанной с представлением.
• Поддержка поиска, охватывающего отношения в админке list_filter .
• Поддержка файлов cookie HttpOnly .
• mail_admins() и mail_managers() теперь поддерживают легкое добавление HTML-содержимого к сообщениям.
• EmailMessage теперь поддерживает CC.
• Сообщения об ошибках теперь содержат больше подробностей и форматирования страницы ошибок сервера отладки.
• simple_tag() теперь принимает takes_context аргумент, что упрощает написание простых тегов шаблона, требующих доступа к контексту шаблона.
• Новый render() ярлык - альтернатива django.shortcuts.render_to_response() предоставлению RequestContext по умолчанию.
• Поддержка комбинирования со значениями при извлечении или обновлении значений базы данных.F expressions timedelta

Проверка CSRF теперь применяется к запросам AJAX ¶

До Django 1.2.5 система предотвращения CSRF в Django исключала запросы AJAX из проверки CSRF; однако из-за проблем с безопасностью, о которых нам сообщили, все запросы теперь проходят проверку CSRF. Обратитесь к документации Django CSRF для получения подробной информации о том, как обрабатывать проверку CSRF в запросах AJAX.

Ограниченные фильтры в интерфейсе администратора ¶

До Django 1.2.5 административный интерфейс Django позволял фильтровать любые поля или отношения модели, а не только те, которые указаны в, list_filter посредством манипуляции со строкой запроса. Однако из-за проблем безопасности, о которых нам сообщили, аргументы поиска строки запроса в админке должны быть для полей или отношений, указанных в list_filter или date_hierarchy .

Удаление модели не приводит к удалению связанных файлов ¶

В более ранних версиях Django, когда экземпляр модели, содержащий a, FileField был удален, FileField он сам также удалял файл из внутреннего хранилища. Это открыло двери для нескольких сценариев потери данных, включая откат транзакций и полей в разных моделях, ссылающихся на один и тот же файл. В Django 1.3, когда модель будет удалена в FileField «S delete() метод не будет вызван. Если вам нужно очистить потерянные файлы, вам нужно будет обработать это самостоятельно (например, с помощью специальной команды управления, которую можно запускать вручную или по расписанию, чтобы запускать периодически, например, cron).

Поведение рендеринга по умолчанию PasswordInput ¶

PasswordInput Форма виджет, предназначенный для использования с полями формой , которые представляют пароли, принимает булево аргумент ключевого слова , render_value указывающее , следует ли отправить его обратно данные в браузер при отображении отправленной формы с ошибками. До Django 1.3 этот аргумент по умолчанию True был равен, что означало, что отправленный пароль будет отправлен обратно в браузер как часть формы. Разработчики, которые хотели добавить немного дополнительной безопасности, исключив это значение из повторно отображаемой формы, могли создать экземпляр PasswordInput передачи render_value=False .

Однако из-за секретности паролей Django 1.3 выполняет этот шаг автоматически; значение по умолчанию render_value - now False , и разработчики, которые хотят, чтобы значение пароля возвращалось браузеру при отправке с ошибками (предыдущее поведение), должны теперь явно указать это. Например:

class LoginForm(forms.Form):
    username = forms.CharField(max_length=100)
    password = forms.CharField(widget=forms.PasswordInput(render_value=True))

Очищаемый виджет по умолчанию для FileField ¶

Django 1.3 теперь включает ClearableFileInput виджет формы в дополнение к FileInput . ClearableFileInput отображает с флажком для очистки значения поля (если поле имеет значение и не является обязательным); FileInput не предоставляет никаких средств для очистки существующего файла от FileField .

ClearableFileInput теперь виджет по умолчанию для a FileField , поэтому существующие формы, в том числе FileField без назначения настраиваемого виджета, должны будут учитывать возможный дополнительный флажок в выводе визуализированной формы.

Чтобы вернуться к предыдущей визуализации (без возможности очистки FileField ), используйте FileInput виджет вместо ClearableFileInput . Например, в ModelForm гипотетической Document модели с FileField именем document :

from django import forms
from myapp.models import Document

class DocumentForm(forms.ModelForm):
    class Meta:
        model = Document
        widgets = {'document': forms.FileInput}

Новый индекс таблицы сеансов базы данных ¶

До Django 1.3 таблица базы данных, используемая серверной частью базы данных для приложения сеансов , не имела индекса в expire_date столбце. В результате запросы к таблице сеансов на основе даты, такие как запрос, необходимый для очистки старых сеансов, будут очень медленными, если сеансов будет много.

Если у вас есть существующий проект, который использует серверную часть сеанса базы данных, вам не нужно ничего делать, чтобы учесть это изменение. Однако вы можете значительно повысить производительность, если вручную добавите новый индекс в сеансовую таблицу. SQL, который добавит индекс, можно найти, выполнив команду sqlindexes администратора:

python manage.py sqlindexes sessions

Больше никаких непристойных слов ¶

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

К сожалению, метод, использованный для реализации этого списка ненормативной лексики, был крайне наивен и склонен к проблеме Сканторпа . Улучшение встроенного фильтра для устранения этой проблемы потребует значительных усилий, а поскольку обработка естественного языка не является обычной областью веб-фреймворка, мы «исправили» проблему, сделав список запрещенных слов пустым.

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

Изменения местного вкуса ¶

Django 1.3 вносит следующие обратно несовместимые изменения в локальные разновидности:

• Канада (ca) - Код провинции «Ньюфаундленд и Лабрадор» был изменен на «NL», а не на более старый «NF». Кроме того, код провинции Юкон был изменен на «YT» вместо «YK».
• Индонезия (id) - Провинция «Нанггро Ачех Даруссалам (НАД)» была удалена из списка провинций в пользу нового официального названия «Ачех (ACE)».
• Соединенные Штаты Америки (США) - список «штатов», используемых в США, USStateField был расширен за счет включения почтовых индексов вооруженных сил. Это обратно несовместимо, если вы рассчитывали USStateField не включать их.

Обновления FormSet ¶

В Django 1.3 FormSet поведение создания немного изменено. Исторически класс не делал различия между непередаваемыми данными и пустым словарем. Это несовместимо с поведением в других частях платформы. Начиная с версии 1.3, если вы перейдете в пустой словарь FormSet , поднимется ValidationError .

Например, с FormSet :

>>> class ArticleForm(Form):
...     title = CharField()
...     pub_date = DateField()
>>> ArticleFormSet = formset_factory(ArticleForm)

следующий код вызовет ValidationError :

>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']

если вам нужно создать пустой экземпляр FormSet , не передавайте данные и не используйте None :

>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)

Вызываемые в шаблонах ¶

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

>>> Template("{{ user.get_full_name }}").render(Context({'user': user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({'full_name': user.get_full_name}))
u'<bound method User.get_full_name of <...

Это было решено в Django 1.3 - результат будет в обоих случаях . Хотя предыдущее поведение было бесполезным для языка шаблонов, разработанного для веб-дизайнеров, и никогда не поддерживалось намеренно, возможно, что это изменение может нарушить работу некоторых шаблонов.u'Joe Bloggs'

Использование пользовательского SQL для загрузки исходных данных в тесты ¶

Django предоставляет настраиваемые обработчики SQL как способ внедрения вручную созданного SQL в процесс синхронизации базы данных. Одно из возможных применений этого пользовательского SQL - вставка данных в вашу базу данных. Если ваш пользовательский SQL содержит INSERT операторы, эти вставки будут выполняться каждый раз при синхронизации вашей базы данных. Это включает синхронизацию любых тестовых баз данных, которые создаются при запуске набора тестов.

Однако в процессе тестирования Django 1.3 было обнаружено, что эта функция никогда не работала полностью, как было заявлено. При использовании серверной части базы данных, не поддерживающей транзакции, или при использовании TransactionTestCase данные, вставленные с помощью пользовательского SQL, не будут видны в процессе тестирования.

К сожалению, не было способа исправить эту проблему, не внося обратную несовместимость. Вместо того, чтобы оставлять начальные данные, вставленные SQL, в неопределенном состоянии, Django теперь применяет политику, согласно которой данные, вставленные с помощью настраиваемого SQL, не будут видны во время тестирования.

Это изменение влияет только на процесс тестирования. Вы по-прежнему можете использовать собственный SQL для загрузки данных в производственную базу данных как часть syncdb процесса. Если вам необходимо, чтобы данные существовали в условиях тестирования, вы должны либо вставить их с помощью тестовых приспособлений , либо использовать setUp() метод вашего тестового примера.

Изменен приоритет загрузки перевода ¶

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

Для переводимых литералов в коде и шаблонах Python ( 'django' домен gettext):

• Изменены приоритеты переводов, включенных в приложения, перечисленные в INSTALLED_APPS настройке. Чтобы обеспечить поведение, согласованное с другими частями Django, которые теперь также используют такие настройки (шаблоны и т. Д.), При создании перевода, который будет доступен, приложения, перечисленные первыми, имеют более высокий приоритет, чем перечисленные позже.
• Теперь можно переопределить переводы, поставляемые с приложениями, с помощью LOCALE_PATHS параметра, переводы которого имеют более высокий приоритет, чем переводы INSTALLED_APPS приложений. Относительный приоритет среди значений, перечисленных в этом параметре, также был изменен, поэтому пути, указанные первыми, имеют более высокий приоритет, чем пути, перечисленные позже.
• locale Подкаталог каталога , содержащего параметры, которые обычно совпадает с и известен как каталог проекта является устаревшим в этом выпуске в качестве источника переводов. (приоритет этих переводов является промежуточным между заявками и LOCALE_PATHS переводами). См. Соответствующий раздел этого документа о устаревших функциях .

Для переводимых литералов, найденных в коде JavaScript ( 'djangojs' домен gettext):

• Аналогично 'django' переводам домена: переопределение переводов, поставляемых с приложениями, с помощью LOCALE_PATHS настройки теперь возможно и для этого домена. Эти переводы имеют более высокий приоритет, чем переводы пакетов Python, переданные в javascript_catalog() представление. Пути, указанные первыми, имеют более высокий приоритет, чем пути, перечисленные позже.
• Переводы в locale подкаталоге каталога проекта никогда не учитывались при переводах JavaScript и остаются в той же ситуации с учетом устаревания такого местоположения.

Управление транзакциями ¶

При использовании управляемых транзакций - то есть любого, кроме режима автоматической фиксации по умолчанию - важно, чтобы транзакция была помечена как «грязная». Грязные транзакции совершаются commit_on_success декоратором или объектом django.middleware.transaction.TransactionMiddleware , и commit_manually принудительно закрывают их явно; чистые транзакции «проходят проверку», что означает, что они обычно откатываются в конце запроса, когда соединение закрывается.

До Django 1.3 транзакции помечались как грязные только тогда, когда Django знал о выполняемой в них операции модификации; то есть либо была сохранена какая-то модель, либо было выполнено массовое обновление или удаление, либо был явно вызван пользователь transaction.set_dirty() . В Django 1.3 транзакция помечается как грязная при выполнении любой операции с базой данных.

В результате этого изменения вам больше не нужно явно устанавливать грязную транзакцию при выполнении необработанного SQL или использовании изменения данных SELECT . Тем не менее, вы делаете необходимость явно закрыть все только для чтения операций, которые управляются с помощью commit_manually() . Например:

@transaction.commit_manually
def my_view(request, name):
    obj = get_object_or_404(MyObject, name__iexact=name)
    return render_to_response('template', {'object':obj})

До Django 1.3 это работало без ошибок. Однако в Django 1.3 это вызовет ошибку, TransactionManagementError потому что операция чтения, которая извлекает MyObject экземпляр, оставляет транзакцию в грязном состоянии.

Без сброса пароля для неактивных пользователей ¶

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

Просмотр сброса пароля теперь поддерживает from_email ¶

django.contrib.auth.views.password_reset() Вид в настоящее время принимает from_email параметр, который передается в password_reset_form «S save() методу в качестве ключевого слова аргумента. Если вы используете это представление с настраиваемой формой сброса пароля, вам необходимо убедиться, что save() метод вашей формы принимает этот аргумент ключевого слова.

mod_python поддержка ¶

mod_python Библиотека не имела выпуск с 2007 года или фиксации с 2008 года плата Фонд Apache проголосовал за исключение mod_python из набора активных проектов в репозиториях управления версиями, и ее ведущий разработчик сместились все его усилия к более легкой, стройнее, более стабильная и гибкая mod_wsgi серверная часть.

Если вы в настоящее время используете mod_python обработчик запросов, вам следует повторно развернуть проекты Django, используя другой обработчик запросов. mod_wsgi - это обработчик запросов, рекомендованный проектом Django, но также поддерживается FastCGI. Поддержка mod_python развертывания будет удалена в Django 1.5.

Общие представления на основе функций ¶

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

• django.views.generic.create_update
• django.views.generic.date_based
• django.views.generic.list_detail
• django.views.generic.simple

template Атрибут ответа тестового клиента ¶

Тестовый клиент Django возвращает Response объекты, помеченные дополнительной тестовой информацией. В версиях Django до 1.3 он включал template атрибут, содержащий информацию о шаблонах, отображаемых при генерации ответа: либо None, либо отдельный Template объект, либо список Template объектов. Эта несогласованность в возвращаемых значениях (иногда список, иногда нет) затрудняла работу с атрибутом.

В Django 1.3 template атрибут устарел и заменен новым templates атрибутом, который всегда является списком, даже если он имеет только один элемент или ни одного элемента.

DjangoTestRunner ¶

В результате введения поддержки unittest2 функции django.test.simple.DjangoTestRunner (включая отказоустойчивость и завершение теста Ctrl-C) были сделаны избыточными. Ввиду этой избыточности DjangoTestRunner он был превращен в пустой класс-заполнитель и будет полностью удален в Django 1.5.

Изменения в url и ssi ¶

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

{% extends "base.html" %}

позволяет указать базовый шаблон как константу, но если у вас есть контекстная переменная templ , содержащая значение base.html :

{% extends templ %}

также законно.

Однако из-за исторической случайности url и ssi отличаются. Эти теги используют второй синтаксис без кавычек, но интерпретируют аргумент как константу. Это означает , что не представляется возможным использовать переменную контекста в качестве целевого объекта url и ssi метки.

Django 1.3 знаменует начало процесса исправления этой исторической аварии. Django 1.3 добавляет новую библиотеку шаблонов, future которая предоставляет альтернативные реализации тегов шаблонов url и ssi . Эта future библиотека реализует поведение, которое согласовывает обработку первого аргумента с обработкой всех других переменных. Итак, существующий шаблон, содержащий:

{% url sample %}

следует заменить на:

{% load url from future %}
{% url 'sample' %}

Теги, реализующие старое поведение, устарели, и в Django 1.5 старое поведение будет заменено новым. Чтобы обеспечить совместимость с будущими версиями Django, существующие шаблоны следует изменить для использования новых future библиотек и синтаксиса.

Изменения в способах входа в админку ¶

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

Этот выпуск изменяет механизм входа администратора для использования подкласса AuthenticationForm вместо проверки формы вручную. Ранее недокументированный метод 'django.contrib.admin.sites.AdminSite.display_login_form' был удален в пользу нового login_form атрибута.

reset и sqlreset команды управления ¶

Эти команды устарели. flush И sqlflush команды могут быть использованы для удаления всего. Вы также можете использовать операторы ALTER TABLE или DROP TABLE вручную.

GeoDjango ¶

• Функция на основе функций, TEST_RUNNER ранее использовавшаяся для выполнения набора тестов GeoDjango, django.contrib.gis.tests.run_gis_tests устарела для средства выполнения на основе классов django.contrib.gis.tests.GeoDjangoTestSuiteRunner .
• Раньше, transform() когда GDAL был недоступен , при вызове ничего не происходило. Теперь GEOSException правильно поднят, чтобы указать на возможный ошибочный код приложения. Теперь transform() появляется предупреждение, если оно вызывается, когда SRID геометрии меньше 0 или None .

CZBirthNumberField.clean ¶

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

CompatCookie ¶

Ранее django.http предоставлялся недокументированный CompatCookie класс, который являлся оболочкой для исправления ошибок стандартной библиотеки SimpleCookie . Поскольку исправления продвигаются вверх по течению, это теперь устарело - вы должны использовать вместо него.from django.http import SimpleCookie

Загрузка переводов на уровне проекта ¶

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

Обоснование этого решения:

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

• Обнаружение locale подкаталога имеет тенденцию к сбою, когда сценарий развертывания более сложен, чем базовый. например, он не работает, если модуль настроек является каталогом (билет № 10765).

• Существуют потенциальные странные проблемы во время разработки и развертывания, такие как тот факт, что project_dir/locale/ подкаталог может генерировать ложные сообщения об ошибках, когда каталог проекта добавляется в путь Python ( делает это), а затем он конфликтует с одноименным модулем стандартной библиотеки, это типичное предупреждающее сообщение:manage.py runserver

  /usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
  import locale, copy, os, re, struct, sys
  

• Это местоположение не было включено в процесс создания перевода для литералов JavaScript. Это устаревание устраняет такую ​​несогласованность.

PermWrapper переехал в django.contrib.auth.context_processors ¶

В Django 1.2 мы начали процесс изменения расположения auth контекстного процессора с django.core.context_processors на django.contrib.auth.context_processors . Однако PermWrapper класс поддержки был ошибочно исключен из этой миграции. В Django 1.3 PermWrapper класс также был перемещен django.contrib.auth.context_processors вместе с PermLookupDict классом поддержки. Новые классы функционально идентичны своим старым версиям; изменилось только расположение модуля.

Удаление XMLField ¶

Когда Django был впервые выпущен, Django включал XMLField автоматическую проверку XML для любого ввода поля. Однако эта функция проверки не выполнялась с момента появления newforms версии до версии 1.0. В результате XMLField реализованный в настоящее время функционально неотличим от простого TextField .

По этой причине Django 1.3 ускорил процесс прекращения поддержки XMLField - вместо устаревания двух выпусков XMLField он будет полностью удален в Django 1.4.

Это легко обновить код для размещения этого изменения - просто замените все использования XMLField с TextField , и удалить schema_path аргумент ключевого слова (если он указан).