2011年3月23日
欢迎来到Django 1.3！
近一年来，Django 1.3包含了很多新功能以及大量的错误修复和对现有功能的改进。这些发行说明涵盖1.3中的新功能，以及一些向后兼容的更改，您需要知道从Django 1.2或更早版本升级时。
Django 1.3的重点主要是解决较小的，长期的功能请求，但这并没有阻止一些相当重要的新功能登陆，包括：
还有更多，当然；请参阅下面的新功能的覆盖范围，了解详细信息和详细信息。
只要有可能，根据our API stability policy策略，新功能将以向后兼容的方式引入。由于此政策，Django 1.3 开始对某些功能的弃用过程。
不幸的是，一些变化是真正的后向不兼容；在大多数情况下，这些是由于安全问题或错误，根本不能以任何其他方式修复。Django 1.3包括其中的一些，以及对它们的描述以及处理它们所需要的（次要的）修改，记录在以下向后兼容的更改列表中。
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添加了一个框架，允许你使用一个类作为视图。这意味着您可以从可以被子类化和覆盖的方法集合中构造一个视图，以提供数据的常见视图，而无需编写太多的代码。
已经提供了所有旧的基于功能的通用视图的模拟，以及可以被用作可以容易地扩展的可重用应用的基础的完全通用的视图基类。
有关详细信息，请参见the documentation on class-based generic views。还有一个文档可以帮助您将基于函数的通用视图转换为基于类的视图。
Django 1.3为Python的logging模块添加了框架级支持。这意味着您现在可以轻松地配置和控制日志作为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 assets should now go in static/ subdirectories of your apps or in other static assets directories listed in STATICFILES_DIRS, and will be served at STATIC_URL.
有关详情，请参阅应用程序的reference documentation of the app，或了解如何manage static files。
Python 2.7对unittest库引入了一些重大更改，添加了一些非常有用的功能。为了确保每个Django项目都能从这些新功能中受益，Django附带了一个unittest2的副本，这是一个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参数，以便在删除引用对象时自定义行为。以前，删除总是级联；可用的选项现在包括设置null，设置默认，设置为任何值，保护或不做任何操作。
有关详细信息，请参阅on_delete文档。
对于含有不明确含义的翻译字符串，您现在可以使用pgettext函数指定字符串的上下文。
如果您只想为翻译者添加一些信息，您还可以在源中添加特殊的翻译评论。
对Django的内置模板标签进行了一些改进：
有时，允许装饰器或中间件在视图构造的之后修改响应有时是有益的。例如，您可能想要更改所使用的模板，或将其他数据放入上下文中。
但是，在构建基本HttpResponse之后，您无法（轻松地）修改其内容。为了克服这个限制，Django 1.3添加了一个新的TemplateResponse类。与基本的HttpResponse对象不同，TemplateResponse对象保留了视图提供的计算响应的模板和上下文的详细信息。响应的最终输出不会计算，直到需要它，稍后在响应过程中。
有关详细信息，请参阅TemplateResponse类上的documentation。
Django 1.3看到了对Django的缓存基础设施的几个改进的介绍。
首先，Django现在支持多个命名缓存。以同样的方式，Django 1.2引入了对多个数据库连接的支持，Django 1.3允许您使用新的CACHES设置来定义多个命名的高速缓存连接。
其次，将versioning，site-wide prefixing和transformation添加到缓存API。
第三，cache key creation已经更新，以在GET请求上考虑请求查询字符串。
Finally, support for pylibmc has been added to the memcached cache backend.
有关详细信息，请参阅有关Django中缓存的documentation on caching in Django。
如果您提供的自定义验证后端的supports_inactive_user设置为True，则无效的User实例将检查后端的权限。这对于进一步集中权限处理是有用的。有关详细信息，请参阅authentication docs。
The GeoDjango test suite is now included when running the Django test suite with runtests.py when using spatial database backends.
以前，如果MEDIA_URL设置在域名后面包含后缀，则只需要一个尾部斜杠。
对于MEDIA_URL和新的STATIC_URL设置，只要不是空白，结尾斜线现在为必需。这确保了在模板中组合路径的一致方法。
提供这两种设置而没有尾部斜杠的项目设置现在将生成PendingDeprecationWarning。
在Django 1.4中，这个相同的条件会引发DeprecationWarning，而在Django 1.5中会引发ImproperlyConfigured异常。
Django 1.1和1.2向Django添加了很多大票项目，比如多数据库支持，模型验证和基于会话的消息框架。然而，这种对大功能的关注是以许多更小的功能为代价的。
为了弥补这一点，Django 1.3开发过程的重点是添加许多较小的，长期的功能请求。这些包括：
在Django 1.2.5之前，Django的CSRF预防系统免除了来自CSRF验证的AJAX请求；由于安全问题向我们报告，但是所有请求现在都要进行CSRF验证。有关如何在AJAX请求中处理CSRF验证的详细信息，请参阅the Django CSRF documentation。
在Django 1.2.5之前，Django管理界面允许通过查询字符串操作对任何模型字段或关系（不仅仅是在list_filter中指定的字段或关系）进行过滤。但是，由于向我们报告的安全问题，admin中的查询字符串查找参数必须是list_filter或date_hierarchy中指定的字段或关系。
在早期的Django版本中，当删除包含FileField的模型实例时，FileField会自动将其从后端存储中删除。这打开了几个数据丢失情况的大门，包括回滚事务和引用同一文件的不同模型上的字段。在Django 1.3中，当模型被删除时，不会调用FileField的delete()方法。如果您需要清除孤立文件，您需要自己处理（例如，使用自定义管理命令，可以手动运行或计划通过例如定期运行。cron）。
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))
除了FileInput，Django 1.3现在还包括一个ClearableFileInput表单小部件。ClearableFileInput使用复选框呈现，以清除字段的值（如果字段具有值并且不是必需的）； FileInput没有提供从FileField清除现有文件的方法。
ClearableFileInput现在是FileField的默认窗口小部件，因此包含FileField的现有窗体无需分配自定义窗口小部件，需要考虑可能的额外复选框在呈现的形式输出。
要返回到先前的呈现（无法清除FileField），请使用FileInput小部件替代ClearableFileInput。例如，对于具有FileField名为document的假设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 admin命令找到将添加索引的SQL：
python manage.py sqlindexes sessions
Django历来提供（并执行）一个亵渎行为的列表。评论应用程序强制执行此亵渎行为列表，阻止人们提交包含其中一个亵渎行为的评论。
不幸的是，用于实现这个亵渎名单的技术非常幼稚，容易出现Scunthorpe问题。改进内置过滤器来解决这个问题将需要大量的工作，并且由于自然语言处理不是web框架的正常域，我们通过使禁用词的列表为空列表来“修复”问题。
如果您想要恢复旧的行为，只需在设置文件中包含您要禁止的字词（参见提交，实现此更改），即可设置PROFANITIES_LIST if你想看到历史上被禁止的单词列表）。然而，如果避免亵渎对你很重要，你会被建议寻求一个更好，更幼稚的方法来解决这个问题。
Django 1.3引入了以下向后不兼容的更改到本地风格：
在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'。虽然以前的行为对于为网页设计师设计的模板语言没有用处，并且从未刻意支持，但有可能某些模板可能会被此更改打破。
Django提供了一个自定义SQL钩子作为一种将手工制作的SQL注入数据库同步过程的方法。此自定义SQL的一个可能的用途是将数据插入到数据库中。如果您的自定义SQL包含INSERT语句，那么每次数据库同步时都会执行这些插入。这包括在运行测试套件时创建的任何测试数据库的同步。
然而，在测试Django 1.3的过程中，发现这个功能从来没有完全如广告。当使用不支持事务的数据库后端或使用TransactionTestCase时，在测试过程中不会显示使用自定义SQL插入的数据。
不幸的是，没有办法纠正这个问题，而不引入后向不兼容性。与其将插入SQL的初始数据置于不确定状态，Django现在强制执行在测试期间可以看到由自定义SQL插入的数据不能显示的策略。
此更改只影响测试过程。您仍然可以使用自定义SQL作为syncdb进程的一部分将数据加载到生产数据库中。如果需要在测试条件期间存在数据，则应使用test fixtures或使用测试用例的setUp()方法插入数据。
已经做了工作来简化，合理化和正确地记录Django在运行时使用的算法，以从磁盘上找到的不同翻译构建翻译，即：
对于在Python代码和模板（'django' gettext domain）中找到的可翻译文字：
对于在JavaScript代码（'djangojs' gettext domain）中找到的可翻译文字：
当使用托管事务 - 即除默认自动提交模式之外的任何事务 - 当事务被标记为“脏”时，这是很重要的。事务由commit_on_success装饰器或django.middleware.transaction.TransactionMiddleware和commit_manually提交，强制它们被明确关闭；干净的事务“获得通过”，这意味着它们通常在连接关闭时在请求结束时回滚。
直到Django 1.3，事务只被标记为脏的当Django知道在其中执行的修改操作；也就是说，保存了一些模型，执行了一些批量更新或删除，或者用户显式调用了transaction.set_dirty()。在Django 1.3中，当执行任何数据库操作时，事务被标记为脏。
作为此更改的结果，您不再需要在执行原始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中，非活动用户将收到与不存在的帐户相同的消息。
django.contrib.auth.views.password_reset()视图现在接受from_email参数，该参数传递到password_reset_form的save()方法作为关键字参数。如果您要使用此自定义密码重置表单，那么您需要确保表单的save()方法接受此关键字参数。
Django 1.3不赞成早期版本的一些功能。这些功能仍然受支持，但将在接下来的几个发布周期中逐步淘汰。
利用以下任何功能的代码将在Django 1.3中生成PendingDeprecationWarning。默认情况下，此警告将保持沉默，但可以使用Python的warnings模块打开，或者使用-Wd或-Wall旗。
在Django 1.4中，这些警告将成为DeprecationWarning，这是不是沉默。在Django 1.5中对这些功能的支持将被完全删除。
也可以看看
有关详情，请参阅文档Django’s release process和我们的deprecation timeline。
mod_python库自2007年以来没有发布或自2008年以来的提交。The Apache Foundation board voted to remove mod_python from the set of active projects in its version control repositories, and its lead developer has shifted all of his efforts toward the lighter, slimmer, more stable, and more flexible mod_wsgi backend.
如果您目前正在使用mod_python请求处理程序，则应该使用其他请求处理程序重新部署Django项目。mod_wsgi是Django项目推荐的请求处理程序，但还支持FastCGI。将在Django 1.5中删除对mod_python部署的支持。
由于引入了基于类的通用视图，Django提供的基于函数的通用视图已被弃用。以下模块及其包含的视图已弃用：
Django的test client返回用额外测试信息注释的Response对象。在1.3之前的Django版本中，这包括一个template属性，其中包含有关在生成响应时呈现的模板的信息：无，单个Template对象或Template对象。返回值中的这种不一致（有时是列表，有时不是）使得属性难以使用。
在Django 1.3中，不建议使用template属性来支持新的templates属性，它总是一个列表，即使它只有一个元素或没有元素。
作为对unittest2的支持的结果，django.test.simple.DjangoTestRunner（包括fail-fast和Ctrl-C测试终止）的功能已经被冗余。鉴于这种冗余，DjangoTestRunner已经变成一个空的占位符类，并将在Django 1.5中完全删除。
大多数模板标签将允许你传入常量或变量作为参数 - 例如：
{% 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属性。
这些命令已被弃用。flush和sqlflush命令可用于删除所有内容。您还可以手动使用ALTER TABLE或DROP TABLE语句。
以前，该字段的clean()方法接受了第二个性别参数，允许进行更强大的验证检查，但是由于此参数实际上不能从Django表单机制传递，因此现在正在等待废弃。
以前，django.http公开了一个未记录的CompatCookie类，它是围绕标准库SimpleCookie的错误修复包装。由于修正正在向上游移动，因此现在已弃用 - 您应该使用从 django.http import SimpleCookie 。
此版本的Django启动弃用过程，以便在运行时执行的翻译构建过程中包含位于所谓的项目路径下的翻译。通过将文件系统路径添加到包含项目级别转换到该设置值的locale目录，可以将LOCALE_PATHS设置用于同一任务。
此决定的理由：
项目路径始终是一个宽松定义的概念（实际上，用于定位项目级别转换的目录是包含设置模块的目录），框架的其他部分已经发生了转变停止使用它作为运行时资产位置的参考。
当部署场景比基本场景更复杂时，检测locale子目录往往会失败。例如当设置模块是目录（故障单＃10765）时，它会失败。
存在潜在的奇怪的开发和部署时问题，例如当项目目录被添加到Python路径时，project_dir/locale/ subdir可以生成错误错误消息（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字面量的翻译构建过程中。此弃用删除了这种不一致。
在Django 1.2中，我们开始将auth上下文处理器的位置从django.core.context_processors更改为django.contrib.auth.context_processors但是，该迁移中错误地忽略了PermWrapper支持类。在Django 1.3中，PermWrapper类也已移至django.contrib.auth.context_processors以及PermLookupDict支持类。新类在功能上与它们的旧版本相同；只有模块位置已更改。
2015年5月13日