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

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

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

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

See the documentation on class-based generic views for more details. There is also a document to help you convert your function-based generic views to class-based views.

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

В Django 1.3 добавлена поддержка модуля logging от Python на уровне фреймворка. Это означает, что теперь вы можете легко настраивать и контролировать логирование в рамках вашего проекта Django. В собственный код Django также добавлен ряд обработчиков и вызовов протоколирования - в частности, письма с ошибками, отправляемые при ошибке сервера HTTP 500, теперь обрабатываются как активность протоколирования. Более подробную информацию смотрите в the documentation on Django’s logging interface.

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

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

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

Подробнее см. в reference documentation of the app или узнайте, как manage static files.

unittest2 поддержка¶

В Python 2.7 были внесены некоторые значительные изменения в библиотеку unittest, добавив несколько чрезвычайно полезных функций. Для того, чтобы каждый проект Django мог воспользоваться этими новыми возможностями, Django поставляется с копией unittest2, копией библиотеки Python 2.7 unittest, перенесенной для совместимости с 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 для настройки поведения при удалении ссылающегося объекта. Ранее удаление всегда происходило каскадно; теперь доступны следующие альтернативы: установить null, установить по умолчанию, установить в любое значение, защитить или ничего не делать.

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

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

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

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

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

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

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

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

TemplateResponse¶

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

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

Более подробную информацию см. в documentation о классе TemplateResponse.

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

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

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

Во-вторых, в API кэша были добавлены versioning, site-wide prefixing и transformation.

В-третьих, cache key creation был обновлен для учета строки запроса при запросах GET.

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

Более подробную информацию см. в разделе documentation on caching in Django.

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

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

GeoDjango¶

Набор тестов GeoDjango теперь включается при running the Django test suite с runtests.py при использовании spatial database backends.

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 в the sites framework.
• RequestFactory для подражания запросам в тестах.
• Новое тестовое утверждение – assertNumQueries() – упрощает тестирование активности базы данных, связанной с представлением.
• Поддержка поиска, охватывающего отношения в админке list_filter.
• Поддержка куки-файлов 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; однако из-за сообщений security issues, поступивших к нам, все запросы теперь подвергаются проверке CSRF. Обратитесь к the Django CSRF documentation за подробностями о том, как обрабатывать проверку CSRF в запросах AJAX.

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

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

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

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

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

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

Однако, из-за чувствительной природы паролей, Django 1.3 делает этот шаг автоматически; значение по умолчанию render_value теперь 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 теперь является виджетом по умолчанию для 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 таблица базы данных, используемая бэкендом базы данных для приложения sessions, не имела индекса на колонке expire_date. В результате, запросы к таблице сессий на основе даты - такие как запрос, необходимый для очистки старых сессий - были очень медленными, если сессий было много.

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

python manage.py sqlindexes sessions

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

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

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

If you want to restore the old behavior, simply put a PROFANITIES_LIST setting in your settings file that includes the words that you want to prohibit (see the commit that implemented this change if you want to see the list of words that was historically prohibited). However, if avoiding profanities is important to you, you would be well advised to seek out a better, less naive approach to the problem.

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

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

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

Обновления набора форм¶

В 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. Если вам требуется, чтобы данные существовали во время тестовых условий, вы должны либо вставить их с помощью test fixtures, либо с помощью метода setUp() вашего тестового случая.

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

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

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

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

Для переводимых литералов, встречающихся в коде JavaScript ('djangojs' gettext domain):

• Аналогично переводам домена 'django': Переопределение переводов, поставляемых с приложениями, с помощью параметра LOCALE_PATHS теперь возможно и для этого домена. Эти переводы имеют более высокий приоритет, чем переводы пакетов Python, переданные в представление javascript_catalog(). Пути, перечисленные первыми, имеют более высокий приоритет, чем те, которые перечислены позже.
• Переводы в подкаталоге locale> каталога project directory никогда не учитывались при переводе 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 save() как аргумент ключевого слова. Если вы используете это представление с пользовательской формой сброса пароля, то вам нужно убедиться, что метод вашей формы save() принимает этот аргумент ключевого слова.

mod_python поддержка¶

Библиотека mod_python не имела релизов с 2007 года и коммитов с 2008 года. Совет Apache Foundation проголосовал за исключение 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 test client возвращает Response объекты, аннотированные дополнительной информацией о тестировании. В версиях Django до 1.3 это включало атрибут template, содержащий информацию о шаблонах, отображаемых при генерации ответа: либо None, либо один объект Template, либо список объектов Template. Такое несоответствие возвращаемых значений (иногда список, иногда нет) делало атрибут сложным для работы.

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

DjangoTestRunner¶

В результате введения поддержки unittest2, возможности django.test.simple.DjangoTestRunner (включая fail-fast и завершение теста по 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.

Изменения в методах входа в систему администратора¶

In previous version the admin app defined login methods in multiple locations and ignored the almost identical implementation in the already used auth app. A side effect of this duplication was the missing adoption of the changes made in r12634 to support a broader set of characters for usernames.

В этом релизе механизм входа в систему администратора доработан таким образом, что вместо ручной проверки формы используется подкласс 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 (если он указан).