2011年3月23日
欢迎来到Django 1.3！
近一年的制作过程中，Django1.3包含了相当多的 new features 以及对现有功能的大量错误修复和改进。这些发行说明涵盖了1.3中的新功能，以及一些 backwards-incompatible changes 从django 1.2或更旧版本升级时，您需要注意。
Django 1.3的重点主要是解决较小的、长期存在的功能请求，但这并没有阻止一些相当重要的新功能着陆，包括：
写作框架 class-based views .
Django的测试框架现在支持（并附带一个副本） the unittest2 library .
在可能的情况下，根据 our API stability policy 政策。根据该政策，Django 1.3 begins the deprecation process for some features .
Django1.2的发布是因为在Django的Python兼容性策略上有了第一个转变；在Django1.2之前，Django支持2.3以上的任何2.x版本的Python。从Django 1.2开始，最低要求提高到了python 2.4。
Django1.3继续支持python 2.4，但它将是最终的Django发布系列；从Django1.4开始，支持的python最低版本将是2.5。在django 1.3发布后不久，我们将发布一份文档，概述我们对python 2.x的弃用和迁移到python 3.x的完整时间表。
Django1.3添加了一个框架，允许您使用类作为视图。这意味着您可以用一组方法组成一个视图，这些方法可以被子类化和重写，以提供通用的数据视图，而不必编写太多的代码。
已经提供了所有基于函数的通用视图的类似物，以及一个完全通用的视图基类，该类可以作为可重用应用程序的基础，可以轻松扩展。
看见 the documentation on class-based generic views 了解更多详细信息。还有一份文件可以帮助你 convert your function-based generic views to class-based views 。
Django 1.3增加了对Python的框架级支持 logging 模块。这意味着您现在可以轻松地在Django项目中配置和控制日志记录。许多日志记录处理程序和日志记录调用也被添加到Django自己的代码中--最值得注意的是，在HTTP500服务器错误上发送的错误电子邮件现在被作为日志记录活动处理。看见 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 支持¶Python2.7引入了对 unittest 库，添加了一些非常有用的功能。为了确保每个Django项目都能从这些新特性中受益，Django附带了 unittest2 ，一份Python2.7的副本 unittest 库，向后移植以兼容Python2.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 用于在删除被引用对象时自定义行为的参数。以前，删除总是层叠的；现在可用的替代方法包括set null、set default、set to any value、protect或do nothing。
有关详细信息，请参阅 on_delete 文档。
对于含义不明确的翻译字符串，现在可以使用 pgettext 函数指定字符串的上下文。
如果您只想为翻译人员添加一些信息，也可以在源代码中添加特殊的翻译人员注释。
有时允许修饰器或中间件修改响应是有益的。 之后 它是由视图构建的。例如，您可能希望更改所使用的模板，或者将其他数据放入上下文中。
但是，您不能（轻松）修改 HttpResponse 建成后。为了克服这一限制，Django1.3增加了一个新的 TemplateResponse 类。不同于基本 HttpResponse 对象， TemplateResponse 对象保留视图提供的用于计算响应的模板和上下文的详细信息。响应的最终输出直到在响应过程的后面需要时才会计算出来。
有关详细信息，请参阅 documentation 上 TemplateResponse 类。
Django1.3介绍了对Django缓存基础设施的几项改进。
首先，Django现在支持多个命名缓存。正如Django1.2引入了对多个数据库连接的支持一样，Django1.3允许您使用新的 CACHES 定义多个命名缓存连接的设置。
其次， versioning ， site-wide prefixing 和 transformation 已添加到缓存API。
第三， cache key creation 已更新以考虑请求查询字符串 GET 请求。
最后，支持 pylibmc 已添加到memcached缓存后端。
有关详细信息，请参阅 documentation on caching in Django .
如果提供一个自定义身份验证后端 supports_inactive_user 设置为 True 不活跃的 User 实例将检查后端的权限。这对于进一步集中权限处理很有用。见 authentication docs 了解更多详细信息。
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添加了许多重要的项目，比如多数据库支持、模型验证和基于会话的消息框架。然而，这种对大特性的关注是以许多小特性为代价的。
为了弥补这一点，Django1.3开发过程的重点是添加许多较小的、长期存在的特性请求。这些包括：
改进了访问和操作电流的工具 Site 中的对象 the sites framework .
A 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 检索或更新数据库值时的值。
在Django 1.2.5之前，由于 security issues 但是，向我们报告， all 请求现在接受CSRF验证。查阅 the Django CSRF documentation 有关如何在Ajax请求中处理CSRF验证的详细信息。
在django 1.2.5之前，django管理接口允许对任何模型字段或关系进行过滤，而不仅仅是在 list_filter --通过查询字符串操作。但是，由于报告给我们的安全问题，管理员中的查询字符串查找参数必须用于中指定的字段或关系。 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))
Django 1.3现在包括 ClearableFileInput 表单小部件 FileInput . ClearableFileInput 使用复选框呈现以清除字段的值（如果字段具有值且不是必需的）； FileInput 不提供清除现有文件的方法 FileField .
ClearableFileInput 现在是 FileField ，因此现有形式包括 FileField 如果不指定自定义小部件，则需要考虑呈现表单输出中可能存在的额外复选框。
返回到上一个渲染（没有清除 FileField ）使用 FileInput 小部件代替 ClearableFileInput . 例如，在 ModelForm 对于一个假设 Document 模型与A 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 . 改进内置的过滤器来解决这个问题需要很大的努力，而且由于自然语言处理不是Web框架的正常领域，我们已经通过将禁止词列表变为空列表来“修复”这个问题。
如果您想恢复旧的行为，只需将一个 PROFANITIES_LIST 设置文件中包含要禁止的单词的设置(请参阅 commit that implemented this change 如果您想查看历史上禁止使用的单词列表)。然而，如果避免亵渎对你来说很重要，你最好找一个更好的、不那么天真的方法来解决这个问题。
Django 1.3对本地口味进行了以下向后不兼容的更改：
加拿大（CA）-“纽芬兰和拉布拉多”省已将其省代码更新为“nl”，而不是旧的“nf”。此外，育空地区的省代码改为“YT”，而不是“YK”。
印度尼西亚（ID）--省“Nanggroe Aceh Darussalam（NAD）”已从省列表中删除，取而代之的是新的官方名称“Aceh（ACE）”。
美利坚合众国（美国）--使用的“州”列表 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' . 虽然以前的行为对于为Web设计器设计的模板语言没有用处，并且从未被有意支持，但这种更改可能会破坏某些模板。
Django提供了一个定制的SQL钩子，作为将手工制作的SQL注入数据库同步过程的一种方法。此自定义SQL的一个可能用途是将数据插入数据库。如果自定义SQL包含 INSERT 语句，这些插入将在每次同步数据库时执行。这包括在运行测试套件时创建的任何测试数据库的同步。
然而，在测试django 1.3的过程中，发现这个特性从未像广告中那样完全起作用。当使用不支持事务的数据库后端时，或者使用TransactionTestCase时，使用自定义SQL插入的数据在测试过程中将不可见。
不幸的是，没有办法在不引入向后不兼容的情况下纠正这个问题。Django现在强制执行由自定义SQL插入的数据将 not 测试时可见。
此更改只影响测试过程。您仍然可以使用自定义SQL将数据作为 syncdb 过程。如果您需要在测试条件期间存在数据，您应该使用 test fixtures 或使用 setUp() 测试用例的方法。
已经完成了简化、合理化和正确记录Django在运行时使用的算法，以从磁盘上找到的不同翻译构建翻译，即：
用于在python代码和模板中找到的可翻译文本 ('django' GetText域）：
中列出的应用程序中包含的翻译优先级 INSTALLED_APPS 设置已更改。为了提供与Django其他部分一致的行为，这些部分现在也使用这种设置（模板等），在构建将要提供的翻译时，首先列出的应用程序的优先级高于后面列出的应用程序。
现在可以通过使用 LOCALE_PATHS 设置其翻译的优先级高于 INSTALLED_APPS 应用。此设置中列出的值之间的相对优先级也已修改，因此首先列出的路径的优先级高于后面列出的路径。
这个 locale 包含设置的目录的子目录，通常与 项目目录 在本版本中被弃用为翻译源。（这些翻译的优先级介于应用程序和 LOCALE_PATHS 翻译）。见 corresponding deprecated features section 本文件。
对于在javascript代码中找到的可翻译文本 ('djangojs' GetText域）：
类似于 'django' 域翻译：通过使用 LOCALE_PATHS 现在也可以对此域进行设置。这些翻译的优先级高于传递给 javascript_catalog() 查看。首先列出的路径优先于后面列出的路径。
翻译 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() 方法接受此关键字参数。
Django1.3不推荐早期版本的一些功能。这些特性仍然受到支持，但将在接下来的几个发布周期中逐步淘汰。
利用以下任何功能的代码将引发 PendingDeprecationWarning 在Django 1.3。默认情况下，此警告将保持沉默，但可以使用python的 warnings 模块，或者使用 -Wd 或 -Wall 标识。
在Django 1.4中，这些警告将成为 DeprecationWarning ，这就是 not 沉默。在Django 1.5中，对这些功能的支持将被完全删除。
参见
有关详细信息，请参阅文档 Django's release process 以及我们的 deprecation timeline .
mod_python 支持¶这个 mod_python 自2007年以来，库还没有发布版本，自2008年以来也没有提交。阿帕奇基金会投票决定取消 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 用额外的测试信息注释的对象。在1.3之前的Django版本中，这包括 template 包含生成响应时呈现的模板信息的属性：无，单个 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' %}
实现旧行为的标记已被弃用，在Django1.5中，旧行为将被新行为替换。为了确保与Django的未来版本兼容，应修改现有模板以使用新的 future 库和语法。
在以前的版本中，管理应用程序在多个位置定义了登录方法，并忽略了已经使用的auth应用程序中几乎相同的实现。这种重复的副作用是遗漏了对 r12634 以支持更广泛的用户名字符集。
此版本将重构管理员的登录机制以使用 AuthenticationForm 而不是手动表单验证。以前未记录的方法 'django.contrib.admin.sites.AdminSite.display_login_form' 为了一个新的 login_form 属性。
reset 和 sqlreset 管理命令¶这些命令已被弃用。这个 flush 和 sqlflush 命令可用于删除所有内容。您还可以手动使用alter table或drop table语句。
基于函数的 TEST_RUNNER 以前用于执行geodjango测试套件， django.contrib.gis.tests.run_gis_tests ，对于基于类的运行程序已弃用， django.contrib.gis.tests.GeoDjangoTestSuiteRunner .
以前，调用 transform() 当gdal不可用时，将静默不做任何事情。现在，A GEOSException 正确提升以指示可能的错误应用程序代码。如果 transform() 当几何体的SRID小于0或 None .
CZBirthNumberField.clean¶以前此字段的 clean() 方法接受了第二个gender参数，该参数允许进行更强大的验证检查，但是由于该参数实际上无法从django表单机制中传递，因此它现在正等待弃用。
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 moved to 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 关键字参数（如果已指定）。
12月 18, 2023