Django 1.3 发行说明

2011 年 3 月 23 日

欢迎使用 Django 1.3！

经过近一年的开发，Django 1.3 包含了相当多的新特性以及大量错误修复和对现有特性的改进。这些发行说明涵盖了 1.3 中的新功能，以及从 Django 1.2 或更旧版本升级时您需要注意的一些向后不兼容更改。

概览

Django 1.3 的重点主要是解决较小的、长期存在的功能请求，但这并没有阻止一些相当重要的新功能登陆，包括：

用于编写基于类的视图的框架。
内置支持使用 Python 的日志记录工具。
Contrib 支持轻松处理静态文件。
Django 的测试框架现在支持（并附带一个副本） unittest2 库。

在可能的情况下，我们会根据我们的 API 稳定性策略策略以向后兼容的方式引入新功能。由于此政策，Django 1.3 开始弃用某些功能。

Python兼容性

Django 1.2 的发布以 Django 的 Python 兼容性政策的第一次转变而著称；在 Django 1.2 之前，Django 支持 Python 2.3 以上的任何 2.x 版本。从 Django 1.2 开始，最低要求提高到 Python 2.4。

Django 1.3 继续支持 Python 2.4，但将是支持 Python 2.4 的最后一个 Django 发布系列；从 Django 1.4 开始，支持的最低 Python 版本为 2.5。一份概述我们弃用 Python 2.x 和迁移到 Python 3.x 的完整时间表的文档将在 Django 1.3 发布后不久发布。

Django 1.3 中的新功能

基于类的视图

Django 1.3 添加了一个框架，允许您将类用作视图。这意味着您可以从一组方法中组合一个视图，这些方法可以被子类化和覆盖以提供数据的通用视图，而无需编写太多代码。

提供了所有旧的基于函数的通用视图的类似物，以及一个完全通用的视图基类，可以用作可重用应用程序的基础，可以轻松扩展。

有关更多详细信息，请参阅有关基于类的通用视图的文档。还有一个文档可以帮助您将您的基于函数的通用视图转换为基于类的视图。

日志记录

Django 1.3 为 Python 的 logging 模块添加了框架级支持。这意味着您现在可以轻松地配置和控制日志记录作为 Django 项目的一部分。许多日志处理程序和日志调用也已添加到 Django 自己的代码中——最值得注意的是，在 HTTP 500 服务器错误上发送的错误电子邮件现在作为日志活动处理。有关详细信息，请参阅 Django 日志记录接口上的文档。

扩展静态文件处理

Django 1.3 附带了一个新的 contrib 应用程序 - django.contrib.staticfiles - 以帮助开发人员处理呈现完整网页所需的静态媒体文件（图像、CSS、JavaScript 等）。

在以前的 Django 版本中，通常将静态资产与用户上传的文件一起放在 :setting:`MEDIA_ROOT` 中，并在 :setting:`MEDIA_URL` 中提供它们. 引入 staticfiles 应用程序的部分目的是为了更轻松地将静态文件与用户上传的文件分开。静态资产现在应该位于您的应用程序的 static/ 子目录或 :setting:`STATICFILES_DIRS` 中列出的其他静态资产目录中，并将在 :setting:`STATIC_URL 中提供`。

详情请参阅应用程序的参考文档或了解如何管理静态文件。

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 参数以自定义删除引用对象时的行为。以前，删除总是级联的；可用的替代方法现在包括设置空值、设置默认值、设置为任何值、保护或什么都不做。

有关更多信息，请参阅 on_delete 文档。

可翻译字符串的上下文标记和注释

对于含义不明确的翻译字符串，您现在可以使用 pgettext 函数来指定字符串的上下文。

而如果你只是想为译者添加一些信息，你也可以在源代码中添加特殊的译者注释。

有关更多信息，请参阅上下文标记和译员注释。

内置模板标签的改进

对 Django 的内置模板标签进行了许多改进：

:ttag:`include` 标签现在接受 with 选项，允许您为包含的模板指定上下文变量
:ttag:`include` 标签现在接受 only 选项，允许您从包含的上下文中排除当前上下文
:ttag:`with` 标签现在允许您在单个 :ttag:`with` 块中定义多个上下文变量。
:ttag:`load` 标签现在接受 from 参数，允许您从库中加载单个标签或过滤器。

模板响应

有时允许装饰器或中间件在视图构造响应 之后修改响应 是有益的。例如，您可能想要更改所使用的模板，或将附加数据放入上下文中。

但是，在构造基本 HttpResponse 之后，您无法（轻松）修改它的内容。为了克服这个限制，Django 1.3 添加了一个新的 TemplateResponse 类。与基本的 HttpResponse 对象不同，TemplateResponse 对象保留了视图提供的模板和上下文的详细信息以计算响应。响应的最终输出在需要时才计算，在响应过程的后期。

有关更多详细信息，请参阅 TemplateResponse 类上的文档。

缓存更改

Django 1.3 引入了对 Django 缓存基础结构的多项改进。

首先，Django 现在支持多个命名缓存。与 Django 1.2 引入对多个数据库连接的支持相同，Django 1.3 允许您使用新的 :setting:`CACHES` 设置来定义多个命名缓存连接。

其次，缓存API增加了版本化、全站前缀和转换。

第三，缓存密钥创建已更新，以在GET请求中考虑请求查询字符串。

最后，对 pylibmc 的支持已添加到 memcached 缓存后端。

有关更多详细信息，请参阅有关 Django 中缓存的文档。

非活动用户的权限

如果您提供自定义身份验证后端，并将 supports_inactive_user 设置为 True，则不活动的 User 实例将检查后端的权限。这对于进一步集中权限处理很有用。有关更多详细信息，请参阅身份验证文档。

吉奥姜戈

当使用空间数据库后端时运行带有 runtests.py 的 Django 测试套件时，现在包含 GeoDjango 测试套件。

:setting:`MEDIA_URL` 和 :setting:`STATIC_URL` 必须以斜线结尾

以前，:setting:`MEDIA_URL` 设置只需要一个尾部斜杠，如果它包含超出域名的后缀。

:setting:`MEDIA_URL` 和新的 :setting:`STATIC_URL` 设置现在需要 '，只要它不为空。这确保了在模板中组合路径的一致方式。

提供两种设置中的任何一个而没有尾部斜杠的项目设置现在将引发 PendingDeprecationWarning。

在 Django 1.4 中，同样的条件将引发 DeprecationWarning，而在 Django 1.5 中将引发 ImproperlyConfigured 异常。

其他一切

Django 1.1 和 1.2 为 Django 添加了很多重要的项目，比如多数据库支持、模型验证和基于会话的消息框架。然而，这种对大功能的关注是以牺牲许多小功能为代价的。

为了弥补这一点，Django 1.3 开发过程的重点是添加许多较小的、长期存在的功能请求。这些包括：

用于访问和操作站点框架中当前站点对象的改进工具。
用于模拟测试中的请求的 RequestFactory。
新的测试断言 - assertNumQueries() - 使测试与视图关联的数据库活动变得更加容易。
支持在管理员的 list_filter 中查找跨越关系。
支持 HttpOnly cookie。
mail_admins() 和 mail_managers() 现在支持轻松地将 HTML 内容附加到邮件中。
EmailMessage 现在支持抄送。
错误电子邮件现在包含调试服务器错误页面的更多详细信息和格式。
simple_tag() 现在接受 takes_context 参数，使得编写需要访问模板上下文的简单模板标签变得更加容易。
新的 render() 快捷方式——默认情况下提供 RequestContext 的 django.shortcuts.render_to_response() 的替代方法。
支持在检索或更新数据库值时将 F 表达式与 timedelta 值结合使用。

1.3 中向后不兼容的变化

CSRF 验证现在适用于 AJAX 请求

在 Django 1.2.5 之前，Django 的 CSRF-prevention 系统免除了 AJAX 请求的 CSRF 验证；由于向我们报告的安全问题，然而，所有请求现在都经过 CSRF 验证。有关如何在 AJAX 请求中处理 CSRF 验证的详细信息，请参阅 Django CSRF 文档。

管理界面中的受限过滤器

在 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 的可清除默认小部件

除了 FileInput 之外，Django 1.3 现在还包含一个 ClearableFileInput 表单小部件。 ClearableFileInput 渲染一个复选框以清除该字段的值（如果该字段有值且不是必需的）； FileInput 没有提供从 FileField 清除现有文件的方法。

ClearableFileInput 现在是 FileField 的默认小部件，因此包括 FileField 在内的现有表单没有分配自定义小部件将需要考虑渲染表单输出中可能的额外复选框。

要返回之前的渲染（无法清除 FileField），请使用 FileInput 小部件代替 ClearableFileInput。例如，在假设的 Document 模型的 ModelForm 中，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 列上没有索引。因此，如果有大量会话，会话表上基于日期的查询（例如清除旧会话所需的查询）将非常缓慢。

如果您有一个使用数据库会话后端的现有项目，则无需执行任何操作来适应此更改。但是，如果您手动将新索引添加到会话表中，您可能会获得显着的性能提升。可以通过运行 sqlindexes 管理命令找到将添加索引的 SQL：

python manage.py sqlindexes sessions

没有更多调皮的话

Django 历史上提供（并强制执行）了一份脏话列表。评论应用程序已强制执行此脏话列表，防止人们提交包含这些脏话之一的评论。

不幸的是，用于实现此脏话列表的技术非常幼稚，并且容易出现斯肯索普问题。改进内置过滤器来解决这个问题需要付出巨大的努力，而且由于自然语言处理不是 Web 框架的正常领域，我们通过将禁用词列表设为空列表来“修复”这个问题。

如果您想恢复旧的行为，只需在您的设置文件中放置一个 PROFANITIES_LIST 设置，其中包含您要禁止的词（如果您想请参阅历史上被禁止的单词列表）。但是，如果避免亵渎对您来说很重要，那么我们建议您寻找一种更好的、不那么幼稚的方法来解决这个问题。

地方风味变化

Django 1.3 对本地风格引入了以下向后不兼容的更改：

加拿大（ca）——“纽芬兰和拉布拉多”省的省代码已更新为“NL”，而不是旧的“NF”。此外，育空地区的省代码已更正为“YT”，而不是“YK”。
印度尼西亚 (id) – 省“Nanggroe Aceh Darussalam (NAD)”已从省名单中删除，取而代之的是新的官方名称“Aceh (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'&lt;bound method User.get_full_name of &lt;...

这已在 Django 1.3 中解决 - 两种情况下的结果都是 u'Joe Bloggs'。尽管之前的行为对于为 Web 设计人员设计的模板语言没有用处，并且从未被刻意支持，但此更改可能会破坏某些模板。

使用自定义 SQL 加载测试中的初始数据

Django 提供了一个自定义 SQL 钩子，作为一种将手工编写的 SQL 注入数据库同步过程的方法。此自定义 SQL 的可能用途之一是将数据插入数据库。如果您的自定义 SQL 包含 INSERT 语句，则每次同步数据库时都会执行这些插入。这包括运行测试套件时创建的任何测试数据库的同步。

然而，在测试 Django 1.3 的过程中，发现这个功能从来没有像宣传的那样完全有效。使用不支持事务的数据库后端时，或使用 TransactionTestCase 时，使用自定义 SQL 插入的数据在测试过程中将不可见。

不幸的是，没有办法在不引入向后不兼容的情况下纠正这个问题。与将 SQL 插入的初始数据保持在不确定状态不同，Django 现在强制执行由自定义 SQL 插入的数据在测试期间不可见的策略。

此更改仅影响测试过程。作为 syncdb 过程的一部分，您仍然可以使用自定义 SQL 将数据加载到生产数据库中。如果您需要在测试条件下存在数据，则应使用测试装置或使用测试用例的 setUp() 方法插入数据。

更改了翻译加载的优先级

已经完成了简化、合理化和正确记录 Django 在运行时使用的算法来从磁盘上找到的不同翻译构建翻译的工作，即：

对于 Python 代码和模板中的可翻译文字（'django' gettext 域）：

:setting:`INSTALLED_APPS` 设置中列出的应用程序包含的翻译优先级已更改。为了提供与现在也使用此类设置（模板等）的 Django 其他部分一致的行为，在构建将可用的翻译时，首先列出的应用程序比后面列出的应用程序具有更高的优先级。
现在可以使用 :setting:`LOCALE_PATHS` 设置覆盖应用程序附带的翻译，其翻译现在比 :setting:`INSTALLED_APPS` 应用程序的翻译具有更高的优先级. 此设置中列出的值之间的相对优先级也已修改，因此首先列出的路径比后面列出的路径具有更高的优先级。
包含设置的目录的 locale 子目录通常与 项目目录重合并被称为 ，在此版本中作为翻译源已被弃用。（这些翻译的优先级介于应用程序和 :setting:`LOCALE_PATHS` 翻译之间）。请参阅本文档的相应的已弃用功能部分。

对于 JavaScript 代码中的可翻译文字（'djangojs' gettext 域）：

与 'django' 域翻译类似：现在也可以为此域使用 :setting:`LOCALE_PATHS` 设置覆盖应用程序附带的翻译。这些翻译比传递给 javascript_catalog() 视图的 Python 包的翻译具有更高的优先级。首先列出的路径比后面列出的路径具有更高的优先级。
在 项目目录 的 locale 子目录下的翻译从未被考虑到 JavaScript 翻译，并且考虑到此类位置的弃用而保持相同的情况。

交易管理

当使用托管事务时——也就是说，除了默认的自动提交模式之外——当一个事务被标记为“脏”时很重要。脏事务由 commit_on_success 装饰器或 django.middleware.transaction.TransactionMiddleware 提交，commit_manually 强制它们显式关闭；干净的事务“获得通过”，这意味着当连接关闭时，它们通常会在请求结束时回滚。

在 Django 1.3 之前，事务只有在 Django 意识到其中执行了修改操作时才会被标记为脏；也就是说，要么保存了某个模型，执行了一些批量更新或删除，要么用户明确调用了 transaction.set_dirty()。在 Django 1.3 中，当执行 any 数据库操作时，事务被标记为脏。

由于此更改，您不再需要在执行原始 SQL 或使用数据修改 SELECT 时显式设置事务脏。但是，您 do 需要明确关闭任何使用 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() 方法接受此关键字参数。

1.3 中弃用的功能

Django 1.3 弃用了早期版本中的一些功能。这些功能仍受支持，但将在接下来的几个发布周期中逐步淘汰。

利用以下任何功能的代码将在 Django 1.3 中引发 PendingDeprecationWarning。默认情况下，此警告是静默的，但可以使用 Python 的 warnings 模块打开，或者通过运行带有 -Wd 或 -Wall 标志的 Python。

在 Django 1.4 中，这些警告会变成 DeprecationWarning，也就是 not 静默。在 Django 1.5 中将完全删除对这些功能的支持。

也可以看看

有关更多详细信息，请参阅文档 Django 的发布过程和我们的弃用时间表。

mod_python 支持

mod_python 库自 2007 年以来没有发布过，自 2008 年以来没有提交过。 Apache 基金会董事会投票决定从其版本控制存储库中的活动项目集中删除 mod_python，其主要开发人员已将所有努力转向更轻、更薄、更稳定和更灵活的 mod_wsgi 后端。

如果您当前正在使用 mod_python 请求处理程序，您应该使用另一个请求处理程序重新部署您的 Django 项目。 mod_wsgi是Django项目推荐的请求处理程序，但也支持FastCGI。 Django 1.5 中将删除对 mod_python 部署的支持。

基于函数的通用视图

由于引入了基于类的通用视图，Django 提供的基于函数的通用视图已被弃用。以下模块及其包含的视图已被弃用：

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

测试客户端响应 template 属性

Django 的测试客户端返回 Response 对象，并带有额外的测试信息。在 1.3 之前的 Django 版本中，这包括 template 属性，其中包含有关生成响应时呈现的模板的信息：无、单个 Template 对象或 Template[ X218X] 对象。返回值（有时是列表，有时不是）的这种不一致使得该属性难以使用。

在 Django 1.3 中 template 属性被弃用，取而代之的是新的 templates 属性，它始终是一个列表，即使它只有一个元素或没有元素。

DjangoTestRunner

由于引入了对 unittest2 的支持，django.test.simple.DjangoTestRunner 的功能（包括快速失败和 Ctrl-C 测试终止）已变得多余。鉴于这种冗余，DjangoTestRunner 已经变成了一个空的占位符类，并将在 Django 1.5 中完全删除。

更改为 url 和 ssi

大多数模板标签将允许您将常量或变量作为参数传递——例如：

{% extends "base.html" %}

允许您将基本模板指定为常量，但如果您有一个包含值 base.html 的上下文变量 templ：

{% 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 库和语法。

对管理员登录方法的更改

在以前的版本中，admin 应用程序在多个位置定义了登录方法，并忽略了已使用的 auth 应用程序中几乎相同的实现。这种重复的副作用是没有采用 r12634 中所做的更改，以支持更广泛的用户名字符集。

此版本重构了管理员的登录机制，以使用 AuthenticationForm 的子类，而不是手动表单验证。以前未记录的方法 'django.contrib.admin.sites.AdminSite.display_login_form' 已被删除，以支持新的 login_form 属性。

reset 和 sqlreset 管理命令

这些命令已被弃用。 flush 和 sqlflush 命令可用于删除所有内容。您还可以手动使用 ALTER TABLE 或 DROP TABLE 语句。

吉奥姜戈

基于函数的 :setting:`TEST_RUNNER` 之前用于执行 GeoDjango 测试套件 django.contrib.gis.tests.run_gis_tests，已被基于类的运行器 django.contrib.gis.tests.GeoDjangoTestSuiteRunner 弃用。
以前，当 GDAL 不可用时，调用 transform() 将无声无息地执行任何操作。现在，一个 GEOSException 被正确地引发来指示可能有错误的应用程序代码。现在，如果在几何体的 SRID 小于 0 或 None 时调用 transform()，则会发出警告。

CZBirthNumberField.clean

以前这个字段的 clean() 方法接受第二个性别参数，允许进行更强大的验证检查，但是由于这个参数实际上永远不能从 Django 表单机制传递，所以现在正在等待弃用。

CompatCookie

以前，django.http 暴露了一个未记录的 CompatCookie 类，它是围绕标准库 SimpleCookie 的错误修复包装器。随着修复程序向上游移动，现在已弃用 - 您应该使用 from django.http import SimpleCookie 代替。

加载项目级翻译

此版本的 Django 开始弃用过程，以便在运行时执行的翻译构建过程中包含位于所谓的 项目路径 下的翻译。 :setting:`LOCALE_PATHS` 设置可用于相同的任务，方法是将文件系统路径添加到 locale 目录中，该目录包含对该设置值的项目级转换。

该决定的理由：

项目路径一直是一个松散定义的概念（实际上，用于定位项目级翻译的目录是包含settings模块的目录）并且框架的其他部分已经转移到停止使用它作为运行时资产位置的参考。
当部署场景比基本场景更复杂时，检测 locale 子目录往往会失败。例如当设置模块是目录时，它会失败（票号 #10765）。
存在潜在的奇怪的开发和部署时问题，例如当将项目目录添加到 Python 路径时 project_dir/locale/ 子目录可能会生成虚假错误消息（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 类和 PermLookupDict 支持类也被移到了 django.contrib.auth.context_processors。新类在功能上与旧版本相同；只有模块位置发生了变化。

移除 XMLField

当 Django 首次发布时，Django 包含一个 XMLField，它可以对任何字段输入执行自动 XML 验证。但是，自 1.0 版本之前的 newforms 引入以来，此验证功能尚未执行。因此，当前实现的 XMLField 在功能上与简单的 TextField 没有区别。

出于这个原因，Django 1.3 快速跟踪了 XMLField 的弃用——而不是两个版本的弃用，XMLField 将在 Django 1.4 中完全删除。

更新代码以适应此更改很容易——只需将 XMLField 的所有用法替换为 TextField，并删除 schema_path 关键字参数（如果已指定）。

Django 1.3 发行说明 — Django 文档

Django 1.3 发行说明

概览

Python兼容性

Django 1.3 中的新功能

基于类的视图

日志记录

扩展静态文件处理

unittest2 支持

事务上下文管理器

可配置的删除级联

可翻译字符串的上下文标记和注释

内置模板标签的改进

模板响应

缓存更改

非活动用户的权限

吉奥姜戈

:setting:`MEDIA_URL` 和 :setting:`STATIC_URL` 必须以斜线结尾

其他一切

1.3 中向后不兼容的变化

CSRF 验证现在适用于 AJAX 请求

管理界面中的受限过滤器

删除模型不会删除关联文件

PasswordInput 默认呈现行为

FileField 的可清除默认小部件

数据库会话表上的新索引

没有更多调皮的话

地方风味变化

表单集更新

模板中的可调用对象

使用自定义 SQL 加载测试中的初始数据

更改了翻译加载的优先级

交易管理

不为非活动用户重置密码

密码重置视图现在接受 from_email

1.3 中弃用的功能

mod_python 支持

基于函数的通用视图

测试客户端响应 template 属性

DjangoTestRunner

更改为 url 和 ssi

对管理员登录方法的更改

reset 和 sqlreset 管理命令

吉奥姜戈

CZBirthNumberField.clean

CompatCookie

加载 项目级 翻译

PermWrapper 移至 django.contrib.auth.context_processors

移除 XMLField

加载项目级翻译