2013年2月26日
欢迎来到Django 1.5！
这些发行说明涵盖新功能以及一些向后不兼容更改，您需要知道从Django 1.4或更早版本升级时。我们还删除了一些功能，详情请参阅our deprecation plan，我们已开始针对某些功能的弃用流程。
Django 1.5中最大的新功能是可配置用户模型。在Django 1.5之前，想要使用Django的auth框架（django.contrib.auth）的应用程序被迫使用Django的“用户”定义。在Django 1.5中，您现在可以替换自己写的User模型。这可以是对现有User模型的简单扩展 - 例如，您可以添加Twitter或Facebook ID字段，或者您可以完全替换User为您的网站。
Django 1.5也是Python 3支持的第一个版本！我们将这个支持标记为“实验性”，因为我们还没有考虑它的生产准备，但一切都已到位，您可以开始将您的应用程序移植到Python 3。我们的下一个版本，Django 1.6，将支持Python 3没有保留。
Django 1.5中的其他值得注意的新功能包括：
只要有可能，我们就会尝试按照our API stability policy以向后兼容的方式引入新功能。但是，与以前的版本一样，Django 1.5附带了一些次要的向后不兼容的更改；从以前版本的Django升级的人应该仔细阅读该列表。
值得注意的一个已弃用的功能是转到“新式”url标记。在Django 1.3之前，解释了{％ url myview ％}不正确（Django认为"myview"是视图的文字名称，而不是名为myview的模板变量）。Django 1.3及以上版本介绍了来自 未来的{％ 负载 url ％}语法，以便在将myview视为变量时引入更正的行为。
结果是，如果您未从 使用{％ 加载 url 未来 ％}，您需要更改{％ url myview ％}到{％ url t15> ％}。If you were using {% load url from future %} you can simply remove that line under Django 1.5
Django 1.5需要Python 2.6.5或更高版本，但我们强烈推荐 Python 2.7.3或更高版本。支持Python 2.5及以下版本已被删除。
此更改应仅影响少数Django用户，因为目前大多数操作系统供应商都提供Python 2.6或更高版本作为其默认版本。如果你仍然使用Python 2.5，你需要坚持Django 1.4，直到你可以升级你的Python版本。根据our support policy，Django 1.4将继续接收安全支持，直到发布Django 1.6。
Django 1.5不在Jython最终版本上运行，因为Jython的最新版本目前不支持Python 2.6。但是，Jython目前提供了一个支持2.7版本的alpha版本，而Django 1.5支持该版本。
Django 1.5引入了对Python 3的支持 - 特别是Python 3.2及更高版本。这是以单个代码库的形式出现的；你不需要在Python 3上安装不同版本的Django。这意味着您可以编写仅针对Python 2（仅适用于Python 3）或支持这两个平台的单个应用程序的应用程序。
但是，我们现在将这种支持标记为“实验性”：虽然通过自动化测试套件接受了广泛的测试，但它的实际测试却很少。我们已尽最大努力消除错误，但我们不能确定我们涵盖了Django的所有可能的用途。
Django的一些功能不可用，因为它们依赖于尚未移植到Python 3的第三方软件，其中包括：
此外，Django不仅仅是一个Web框架；它是一个可插拔组件的生态系统。在这一点上，很少有第三方应用程序被移植到Python 3中，因此现实世界的应用程序不太可能在Python 3下满足所有的依赖关系。
因此，我们建议Django 1.5不能在Python 3的生产环境中使用。相反，请使用此机会开始porting applications to Python 3。如果您是可插拔组件的作者，我们建议您立即开始移植。
我们计划在我们的下一个版本Django 1.6中为Python 3提供一流的，生产就绪的支持。
在Django 1.5中，您现在可以使用自己的模型作为用户相关数据的存储。如果项目需要超过30个字符的用户名，或者要以不同于名/姓的格式存储用户名，或者要将自定义配置文件信息放到用户对象中，则现在可以这样做。
如果您有引用用户模型的第三方可重用应用程序，则可能需要对引用用户实例的方式进行一些更改。您还应记录应用程序依赖的用户模型的任何特定功能。
有关详细信息，请参阅自定义用户模型的documentation on custom User models
方法Model.save()有一个新的关键字参数update_fields。通过使用这个参数，可以只保存模型的字段的选择列表。这可能有助于性能原因或尝试避免覆盖并发更改时。
延迟实例（由.only()或.defer()加载的实例）将自动保存加载的字段。如果在加载后手动设置任何字段，该字段也将在保存时更新。
有关详细信息，请参阅Model.save()文档。
在Django 1.5之前，可以通过将迭代器传递到HttpResponse来创建流式响应。但这是不可靠的：访问content属性的任何中间件都会过早地使用迭代器。
现在，您可以使用新的StreamingHttpResponse类显式生成流式响应。此类公开了作为迭代器的streaming_content属性。
由于StreamingHttpResponse没有content属性，因此需要访问响应内容的中间件必须测试流响应并相应地进行操作。有关详细信息，请参阅process_response。
方法ContentTypeManager.get_for_model()和ContentTypeManager.get_for_models()分别有一个新的关键字参数for_concrete_model和for_concrete_models通过使用此参数传递False，现在可以检索与代理模型关联的ContentType。
在所有generic class-based views（或任何基于类的视图继承自ContextMixin）中，上下文字典包含一个view View实例。
对文档的补充包括修订的Tutorial 3和新的tutorial on testing。新的部分“高级教程”提供How to write reusable apps以及在Writing your first patch for Django编写第一个补丁的新贡献者的分步指南。
Django 1.5还包括几个小的改进值得注意：
模板引擎现在将True，False和None解释为相应的Python对象。
django.utils.timezone提供了在时区之间转换感知数据时间的帮助程序。请参阅localtime()。
通用视图支持OPTIONS请求。
当通过代码从call_command调用时，管理命令不再引发SystemExit。将传播由命令引发的任何异常（主要是CommandError）。
Moreover, when you output errors or messages in your custom commands, you should now use self.stdout.write('message') and self.stderr.write('error') (see the note on management commands output).
dumpdata管理命令一次输出一行，以防止转储大型数据集时出现内存不足错误。
在加拿大的localflavor中，“pq”被添加到魁北克的可接受代码中。这是一个老缩写。
receiver装饰器现在能够通过提供信号列表连接到多个信号。
在管理员中，您现在可以按组成员过滤用户。
QuerySet.bulk_create()现在有一个batch_size参数。默认情况下，batch_size是无限的，除了SQLite，其中单个批次被限制，以便不超过每个查询的999个参数。
LOGIN_URL和LOGIN_REDIRECT_URL设置现在还接受视图函数名称和named URL patterns。这允许您减少配置重复。有关详细信息，请参阅login_required()文档。
Django现在提供了一个mod_wsgi auth handler。
在某些情况下，QuerySet.delete()和Model.delete()现在可以采用快速路径。快速路径允许较少的查询和较少的对象提取到内存中。有关详细信息，请参见QuerySet.delete()。
ResolverMatch的实例作为resolver_match存储在请求中。
默认情况下，当DEBUG为True时，到达django记录器的所有日志消息都会发送到控制台（除非您重新定义LOGGING设置）。
使用RequestContext时，现在可以使用{％ if 'someapp.someperm' / t6> 在 perms ％}
不需要在根模板目录中拥有404.html和500.html模板。对于没有找到这些模板的情况，Django将输出一些基本的错误消息。当然，仍然建议提供这些模板作为良好的做法，以便向用户呈现漂亮的错误页面。
django.contrib.auth提供一个新的信号，每当用户无法成功登录时发出。请参见user_login_failed
loaddata管理命令现在支持--ignorenonexistent选项来忽略不再存在的字段的数据。
assertXMLEqual()和assertXMLNotEqual()新的断言允许您在语义层面测试XML内容的等同性，而无需处理语法差异（空格，属性顺序等））。
当REMOTE_USER标头在同一浏览器会话期间消失时，RemoteUserMiddleware现在强制注销。
cache-based session backend可以将会话数据存储在非默认缓存中。
现在可以在模型上创建多列索引。有关详细信息，请参阅index_together文档。
在Django的日志记录配置过程中，将启用弃用警告，并将警告捕获到日志记录系统中。记录的警告通过console日志处理程序进行路由，默认情况下要求DEBUG为True，以便生成输出。结果是，DeprecationWarnings应该按照他们在Python版本中的方式打印到开发环境中的控制台
django.contrib.admin.ModelAdmin.message_user()方法的API已修改为接受添加类似于django.contrib.messages.add_message()的功能的其他参数。这对从管理操作生成错误消息很有用。
管理员的列表过滤器现在可以根据新的django.contrib.admin.ModelAdmin.get_list_filter()方法进行自定义。
警告
除了本节中概述的更改外，请务必查看已删除的任何功能的deprecation plan。如果您没有在指定功能的弃用时间轴内更新代码，则其移除可能会显示为向后不兼容的更改。
新的ALLOWED_HOSTS设置会验证请求的Host头，并防止主机中毒攻击。只要DEBUG为False，或django.http.HttpRequest.get_host()将提高SuspiciousOperation有关新设置的详细信息，请参阅full documentation。
抽象模型能够定义自定义管理器，并且管理器will be inherited by any concrete models extending the abstract model的任何具体模型继承。但是，如果您尝试使用抽象模型在管理器上调用方法，则会出现异常。以前，该调用将被允许，但是一旦尝试任何数据库操作（通常来自数据库的“表不存在”错误）就会失败。
如果您在使用抽象类调用的管理器上具有功能，则应将该逻辑迁移到抽象类上的Python staticmethod或classmethod。
为了与其他基于日期的通用视图一致，YearArchiveView现在将year作为datetime.date而不是字符串传递到上下文中。If you are using {{ year }} in your templates, you must replace it with {{ year|date:"Y" }}.
还在上下文中添加了next_year和previous_year。它们根据allow_empty和allow_future计算。
YearArchiveView和MonthArchiveView被记录为在上下文中提供按升序排序的date_list，例如它们基于功能的前辈，但实际上降序。在1.5中，已记录的订单已恢复。当您在模板中的date_list上进行迭代时，您可能需要添加（或删除）reversed关键字：
{% for date in date_list reversed %}
ArchiveIndexView仍然按降序提供date_list。
为了与其他通用视图的设计保持一致，TemplateView不再将params字典传递到上下文中，而是将URLconf中的变量直接传递到上下文中。
request.POST将不再包含通过HTTP请求发布的数据，并在标题中包含非表单特定的内容类型。在以前的版本中，以multipart/form-data或application/x-www-form-urlencoded之外的内容类型发布的数据仍然会在request.POST属性。希望访问这些情况的原始POST数据的开发人员应改用request.body属性。
Django用于在视图函数返回响应时立即发送request_finished信号。这与streaming responses（延迟内容生成）交互不畅。
此信号现在在内容被WSGI网关完全使用后发送。如果依赖于在将响应内容发送到客户端之前触发的信号，这可能向后不兼容。如果您这样做，您应该考虑使用middleware。
注意
一些WSGI服务器和中间件在处理请求之后不总是在响应对象上调用close，最值得注意的是在1.2.6之前的uWSGI和到2.0.7的Sentry的错误报告中间件。在这些情况下，根本不发送request_finished信号。这可能导致空闲连接到数据库和内存缓存服务器。
与GET和POST不同，这些HTTP方法不是由Web浏览器实现的。相反，它们用于API，它以JSON或XML等各种格式传输数据。由于这样的请求可能包含任意数据，Django不会尝试解码其身体。
但是，测试客户端用于为OPTIONS和DELETE请求（如GET）构建查询字符串，并为PUT请求（如POST）请求主体。此编码是任意的，并与Django的行为，当它收到请求，因此它在Django 1.5中删除的行为不一致。
如果您在OPTIONS或DELETE请求中使用data参数，则必须将其转换为查询字符串，并将其附加到path参数。
如果您在没有content_type的PUT请求中使用data参数，则必须在将数据传递给测试客户端之前对其进行编码，并将content_type
As explained below，Django 1.5不建议使用django.utils.simplejson，而使用Python 2.6的内置json模块。在理论上，这种变化是无害的。不幸的是，由于simplejson的版本之间不兼容，它在某些情况下可能会触发错误。
Django 1.4中与JSON相关的功能始终使用django.utils.simplejson。这个模块实际上是：
在Django 1.5中，这些功能使用Python的json模块，它基于simplejson的2.0.9版本。
Django的2.0.7版本和Python的2.0.9版本之间没有已知的不兼容性。但是，simplejson的其他版本之间有一些不兼容：
有关这些不兼容性的详细信息，请参见机票＃18023。
The net result is that, if you have installed simplejson and your code uses Django’s serialization internals directly – for instance django.core.serializers.json.DjangoJSONEncoder, the switch from simplejson to json could break your code. （一般来说，内部的更改没有记录；我们在这里例外）。
在这一点上，Django的维护者相信使用标准库中的json提供了向后兼容性的最强保证。他们建议从现在开始使用它。
如果您已写入custom password hasher，则您的encode()，verify()或safe_summary()应接受Unicode参数（password，salt或encoded）。如果任何散列方法需要字节字符串，则可以使用force_bytes()实用程序对字符串进行编码。
使用object pagination时，Page对象的previous_page_number()和next_page_number()方法未检查返回的数字在现有页面范围内。它现在检查它，并且当数字太低或太高时引发InvalidPage异常。
PostgreSQL的autocommit选项没有像之前的广告一样工作。它为单个事务块工作，但在第一个块后，自动提交行为从未恢复。这个bug现在固定在1.5。虽然这只是一个错误修复，但值得检查您的应用程序行为，如果您与自动提交选项一起使用PostgreSQL。
如果响应的状态代码为500，Django的会话中间件将跳过保存会话数据。
在Django 1.5之前，如果您尝试登录管理界面并误使用您的电子邮件地址而不是您的用户名，管理界面将提供警告，告知您的电子邮件地址不是您的用户名。在Django 1.5中，引入custom User models需要删除此警告。这不会更改管理站点的登录行为；它仅影响在一种特定登录失败模式下显示的警告消息。
在对某些测试设置可能向后不兼容的测试执行中引入了一些更改：
以前，在TransactionTestCase中，测试数据库在之前截断。
为了能够以任何顺序运行单元测试，并确保它们始终彼此隔离，TransactionTestCase现在将在每次测试运行后重置数据库。
TransactionTestCase测试用于自动重置主键序列以及上述数据库刷新操作。
这已更改，因此没有序列隐式重置。这可能导致取决于硬编码的主键值的TransactionTestCase测试中断。
新的reset_sequences属性可用于强制可能需要它的TransactionTestCase的旧行为。
为了确保所有TestCase代码以干净的数据库开始，现在按照以下顺序执行测试：
这不应该导致任何问题，除非你有现有的doctest假设之前执行的一个TransactionTestCase留下一些数据库状态或单元测试依赖于在执行其他测试后保留的某种形式的状态。这种测试已经非常脆弱，现在必须改变为能够独立运行。
在表单验证之后，cleaned_data字典总是存在。当表单未验证时，它仅包含通过验证的字段。您应该使用is_valid()方法测试验证是否成功，而不是在表单上是否存在cleaned_data属性。
syncdb现在查询数据库路由器以确定是否创建内容类型（启用contenttypes时）和权限（启用auth时）目标数据库。以前，它在默认数据库中创建它们，即使使用--database选项指定了另一个数据库。
如果在多个数据库上使用syncdb，则应确保路由器只允许将内容类型和权限同步到其中一个数据库。有关详细信息，请参阅有关多个数据库的contrib应用程序behavior of contrib apps with multiple databases。
为了防止暴露于与外部实体引用和实体扩展相关的拒绝服务攻击，XML模型解序器现在拒绝解析包含DTD（DOCTYPE定义）的XML文档。由于XML序列化器不输出DTD，因此这不会影响典型的用法，只有将自定义创建的XML文档传递给Django的模型反序列化器。
对于formset工厂的max_num参数，None的（默认）值不再默认允许表单集中的任何数量的表单。相反，为了防止内存耗尽攻击，它现在默认为1000个表单的限制。可以通过为max_num显式设置较高的值来提高此限制。
localflavor contrib应用程序已拆分为单独的包。django.contrib.localflavor itself will be removed in Django 1.6, after an accelerated deprecation. 文档提供migration instructions。
新软件包可以在Github上找到on Github
markup contrib模块已被弃用，并将遵循加速淘汰计划。直接使用python标记库或第三方标记库是Django在框架中维护此功能的首选。
随着custom User models的引入，不再需要内置的机制来存储用户配置文件数据。
您仍然可以定义与用户模型具有一对一关系的用户配置文件模型 - 实际上，对于需要将数据与用户帐户相关联的许多应用程序，这将是一个适当的设计模式。但是，不应再使用AUTH_PROFILE_MODULE设置和用于访问用户配置文件模型的django.contrib.auth.models.User.get_profile()方法。
Django 1.5通过将迭代器传递到HttpResponse来废弃流式传输响应的功能。如果您依赖此行为，请切换到StreamingHttpResponse。请参阅上面的Explicit support for streaming responses。
在Django 1.7及以上版本中，迭代器将立即由HttpResponse消耗。
由于Django 1.5下降了对Python 2.5的支持，我们现在可以依赖于Python标准库中的json模块，因此我们删除了simplejson的副本。You should now import json instead of django.utils.simplejson.
不幸的是，由于simplejson版本之间不兼容，请参阅backwards-incompatible changes部分，此更改可能会产生不必要的副作用。如果你依赖于simplejson在Python的json之后添加的功能，则应该明确导入simplejson。
django.utils.encoding.StrAndUnicode mix-in已被弃用。定义__str__方法，并应用python_2_unicode_compatible()装饰器。
django.utils.itercompat.product函数已被弃用。请改用内置的itertools.product()。
cleanup管理命令已弃用，并被替换为clearsessions。
未归档的daily_cleanup.py脚本已被弃用。请改用clearsessions管理命令。
2015年5月13日