Django 1.3 版本发行说明¶
2011 年 3 月 23 日
欢迎来到 Django 1.3 版本！
经过将近一年的努力，Django 1.3 包括了相当多的 新功能，以及对现有功能的大量错误修复和改进。这些发布说明涵盖了 1.3 中的新功能，以及从 Django 1.2 或更早版本升级时需要注意的一些 向后不兼容的更改。
概况¶
Django 1.3 的重点主要是解决较小的、长期存在的功能需求，但这并未阻止一些相当重要的新功能的实现，包括：
一个用于编写 基于类的视图 的框架。
内置支持 使用 Python 的日志记录工具。
为 静态文件的简单处理 提供的贡献支持。
Django 的测试框架现在支持（并随附了一份） unittest2 库。
在可能的情况下，新功能都按照 我们的 API 稳定性政策 以向后兼容的方式引入。由于这个政策，Django 1.3 开始了某些功能的弃用过程。
Python 兼容性¶
Django 1.2 的发布引人注目，因为它是 Django Python 兼容性政策的第一个变化；在 Django 1.2 之前，Django 支持从 2.3 到任何 2.x 版本的 Python 。从 Django 1.2 开始，最低要求提高到 Python 2.4 。
Django 1.3 继续支持 Python 2.4，但这将是最后一个支持该版本的 Django 发布系列；从 Django 1.4 开始，最低支持的 Python 版本将是 2.5 。在 Django 1.3 发布后不久，我们将发布一份详细说明废弃 Python 2.x 并转向 Python 3.x 的完整时间表的文档。
Django 1.3 新特性¶
基于类的视图¶
Django 1.3 添加了一个框架，允许您使用类作为视图。这意味着您可以使用一组方法组成一个视图，这些方法可以被子类化和重写，以提供数据的通用视图，而无需编写太多代码。
已经提供了所有旧的基于函数的通用视图的类似物，以及一个完全通用的视图基类，可以用作可重用应用程序的基础，这些应用程序可以很容易地扩展。
有关更多详细信息，请参阅 关于基于类的通用视图的文档。还有一份文档可以帮助您将 基于函数的通用视图转换为基于类的视图。
日志¶
Django 1.3 在框架级别添加了对 Python 的 logging 模块的支持。这意味着现在您可以轻松地在您的 Django 项目中配置和控制日志记录。此外，Django 的代码中还添加了许多日志处理程序和日志调用，最显著的是，在发生 HTTP 500 服务器错误时发送的错误邮件现在被处理为日志活动。有关更多详细信息，请参阅 关于 Django 日志记录接口的文档。
扩展静态文件处理¶
Django 1.3 随附了一个新的贡献应用程序 -- django.contrib.staticfiles -- 以帮助开发人员处理渲染完整网页所需的静态媒体文件（图像、CSS、JavaScript 等）。
在以前的 Django 版本中，通常会将静态资源与用户上传的文件一起放在 MEDIA_ROOT 中，并同时在 MEDIA_URL 上提供它们。引入 staticfiles 应用程序的部分目的是使将静态文件与用户上传的文件分开更加容易。现在，静态资源应该放在您的应用程序的 static/ 子目录中或在 STATICFILES_DIRS 中列出的其他静态资源目录中，并将在 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 参数，用于在引用的对象被删除时自定义行为。以前，删除操作总是级联的；现在可用的替代方案包括设置为 null、设置为默认值、设置为任何值、保护或不采取任何行动。
有关更多信息，请参阅 on_delete 的文档。
可翻译字符串的上下文标记和注释¶
对于具有模糊含义的翻译字符串，现在可以使用 pgettext 函数来指定字符串的上下文。
如果你只想为翻译者添加一些信息，你还可以在源代码中添加特殊的翻译者注释。
有关更多信息，请参阅 上下文标记 和 翻译者注释。
模板响应¶
有时允许装饰器或中间件在视图构建响应之后修改响应可能是有益的。例如，您可能希望更改所使用的模板，或将额外的数据放入上下文中。
然而，您不能（轻松地）在构建后修改基本的 HttpResponse 内容。为了克服这个限制，Django 1.3 添加了一个新的 TemplateResponse 类。与基本的 HttpResponse 对象不同，TemplateResponse 对象保留了视图提供的模板和上下文的详细信息，以计算响应。响应的最终输出直到后面的响应过程中才会计算。
有关更多详细信息，请参阅 TemplateResponse 类的 文档。
缓存更改¶
Django 1.3 引入了对 Django 缓存基础设施的若干改进。
首先，Django 现在支持多个命名缓存。与 Django 1.2 引入多个数据库连接支持的方式类似，Django 1.3 允许您使用新的 CACHES 设置来定义多个命名的缓存连接。
其次，缓存 API 中添加了 版本化、站点范围的前缀 和 转换 功能。
第三，已更新 缓存键创建，以考虑 GET 请求中的请求查询字符串。
最后，已经将对 pylibmc 的支持添加到了 memcached 缓存后端。
有关更多详细信息，请参阅 Django 中的缓存文档。
对非活跃用户的权限¶
如果您提供一个自定义的身份验证后端，并将 supports_inactive_user 设置为 True，则不活动的 User 实例将检查后端以获取权限。这对于进一步集中权限处理非常有用。有关更多详细信息，请参阅 身份验证文档。
GeoDjango¶
使用 空间数据库后端 来 运行 Django 测试套件 时，GeoDjango 测试套件现在已包含在 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 开发过程的重点是添加许多较小的、长期存在的功能需求。这些包括：
在测试中用于模拟请求的
RequestFactory。一个新的测试断言 --
assertNumQueries()-- 使得更容易测试与视图相关的数据库活动。在管理员的
list_filter中支持跨关系的查询。支持 HttpOnly cookies。
现在，
mail_admins()和mail_managers()支持轻松附加 HTML 内容到消息中。EmailMessage现在支持抄送 (CC)。错误邮件现在包含了更多关于调试服务器错误页面的详细信息和格式。
simple_tag()现在接受一个takes_context参数，这使得编写需要访问模板上下文的简单模板标签变得更加容易。一个新的
render()快捷方式 -- 作为django.shortcuts.render_to_response()的替代，默认提供一个RequestContext。支持在检索或更新数据库值时将
F 表达式与timedelta值组合使用。
1.3 中的向后不兼容更改¶
CSRF 验证现在适用于 AJAX 请求¶
在 Django 1.2.5 之前，Django 的 CSRF 预防系统豁免了 AJAX 请求的 CSRF 验证；然而，由于我们收到的有关 安全问题 的报告，现在 所有 请求都需要进行 CSRF 验证。请参考 Django CSRF 文档 以获取有关如何处理 AJAX 请求中的 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 的可清除默认小部件¶
Django 1.3 现在除了 FileInput 外还包括一个 ClearableFileInput 表单小部件。ClearableFileInput 渲染时包含一个清除字段值的复选框（如果字段有值且不是必需的）；而 FileInput 无法清除 FileField 中的现有文件。
ClearableFileInput 现在是 FileField 的默认小部件，因此包含 FileField 的现有表单如果没有分配自定义小部件，需要考虑在渲染的表单输出中可能会出现额外的复选框。
要返回到以前的渲染方式（不具备清除 FileField 的能力），可以在 ClearableFileInput 的位置使用 FileInput 小部件。例如，在假设有一个名为 document 的 FileField 的假设 Document 模型的 ModelForm 中：
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 设置（如果您想查看历史上被禁止的单词列表，请参考 实施这个更改的提交）。然而，如果避免粗话对您很重要，建议您寻找一个更好、不那么天真的解决方法来解决这个问题。
Localflavor 更改¶
Django 1.3 引入了以下对本地风格的向后不兼容的更改：
加拿大（ca）- 省份“纽芬兰与拉布拉多”已将其省份代码更新为“NL”，而不是较旧的“NF”。此外，育空地区的省份代码已更正为“YT”，而不是“YK”。
印度尼西亚（id）- 省份“ Nanggroe Aceh Darussalam (NAD)”已从省份列表中移除，转而使用新的官方名称“ Aceh (ACE)”。
美利坚合众国（us）-- 由
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设置来覆盖应用程序中附带的 JavaScript 代码的翻译。这些翻译的优先级高于传递给javascript_catalog()视图的 Python 包的翻译。首先列出的路径比后面列出的路径具有更高的优先级。位于 项目目录 的
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 的 save() 方法。如果您正在使用自定义密码重置表单与此视图，则需要确保您表单的 save() 方法接受这个关键字参数。
在 1.3 中被废弃的功能¶
Django 1.3 弃用了一些早期版本的功能。这些功能仍然受支持，但将在接下来的几个发布周期内逐步淘汰。
使用以下任何特性的代码将在 Django 1.3 中引发 PendingDeprecationWarning。默认情况下，此警告是静默的，但可以使用 Python 的 warnings 模块打开，或者通过在运行 Python 时使用 -Wd 或 -Wall 标志来打开。
在 Django 1.4 中，这些警告将变成 DeprecationWarning，它是 不 静默的。在 Django 1.5 中，将完全删除对这些特性的支持。
参见
有关更多详细信息，请参阅文档 Django 的发布流程 和我们的 弃用时间表。
mod_python 支持¶
mod_python 库自 2007 年以来没有发布过新版本，自 2008 年以来也没有提交。Apache 基金会董事会投票决定将 mod_python 从其版本控制存储库的活动项目集中删除，其主要开发人员已将所有工作重心转向了更轻巧、更稳定、更灵活的 mod_wsgi 后端。
如果您当前使用的是 mod_python 请求处理程序，您应该重新部署您的 Django 项目，使用其他请求处理程序。Django 项目推荐使用的请求处理程序是 mod_wsgi，但也支持 FastCGI。对于 mod_python 部署的支持将在 Django 1.5 中被移除。
基于函数的通用视图¶
由于引入了基于类的通用视图，Django 提供的基于函数的通用视图已被弃用。以下模块及其包含的视图已被弃用：
django.views.generic.create_updatedjango.views.generic.date_baseddjango.views.generic.list_detaildjango.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" %}
允许您将一个基本模板指定为常量，但如果您有一个包含值 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 库和语法。
管理员登录方法的更改¶
在之前的版本中，管理应用在多个位置定义了登录方法，并忽略了已经使用的 auth 应用中几乎相同的实现。这种重复的副作用是没有采用 r12634 中所做的更改，以支持更广泛的用户名字符集。
这个版本重构了管理界面的登录机制，使用了 AuthenticationForm 的子类来代替手动表单验证。以前未记录的方法 'django.contrib.admin.sites.AdminSite.display_login_form' 已被移除，改为使用新的 login_form 属性。
reset 和 sqlreset 管理命令¶
这些命令已经被弃用。可以使用 flush 和 sqlflush 命令来删除所有内容。您也可以手动使用 ALTER TABLE 或 DROP TABLE 语句。
GeoDjango¶
用于执行 GeoDjango 测试套件的函数式
TEST_RUNNER，以前称为django.contrib.gis.tests.run_gis_tests，已被弃用，取而代之的是基于类的运行器，django.contrib.gis.tests.GeoDjangoTestSuiteRunner。以前，调用
transform()在没有安装 GDAL 时会默默地什么也不做。现在，会引发一个GEOSException来指示可能存在问题的应用程序代码。如果在几何对象的 SRID 小于 0 或为None时调用transform()，则会引发警告。
CZBirthNumberField.clean¶
以前，这个字段的 clean() 方法接受第二个参数 gender，允许进行更强的验证检查，但由于这个参数实际上无法从 Django 表单机制中传递，因此它现在处于待弃用状态。
加载 项目级别 的翻译¶
Django 的这个版本开始了对在运行时进行的翻译构建过程中包含位于所谓的 项目路径 下的翻译的弃用过程。可以使用 LOCALE_PATHS 设置来执行相同的任务，只需将包含项目级别翻译的 locale 目录的文件系统路径添加到该设置的值中。
这个决定的理由：
项目路径 一直是一个宽泛定义的概念（实际上，用于定位项目级别翻译的目录是包含设置模块的目录），在框架的其他部分也已经有了不再将其作为运行时资源位置的参考的变化。
当部署场景比基本情况更复杂时，检测
locale子目录的功能往往会失败，例如，当设置模块是一个目录时（ticket #10765）。存在一些潜在的奇怪的开发和部署时的问题，比如在将项目目录添加到 Python 路径时（
manage.py runserver会这样做），project_dir/locale/子目录可能会生成虚假的错误消息，并且会与同名的标准库模块发生冲突，这是一个典型的警告消息：/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 关键字参数（如果已指定）。
