期待 Django 6.0

2025 年 9 月 1 日
来源：https://buttondown.com/carlton/archive/looking-forward-to-django-60/

关于即将发布的 Django 6.0

这个夏天非常忙碌。Django 6.0 正逐渐成形，基本上已经就位。功能冻结（feature freeze）和 alpha 版本将在 9 月 17 日 到来，所以我今天想聊聊这件事。

即将到来的亮点

Python 3.12+

Django 6.x 系列的最低 Python 版本将是 Python 3.12。

有点不可思议，对吧？怎么已经 3.12 了？这还挺新的。我知道 Django 5.2 LTS 还有很长的维护周期，但我们已经可以开始用上那些新玩具了。

我觉得 Django 的 Python 支持策略大体上是合理的。但随着 Python（现在也不算“新”了）的年度发布节奏，Python 3.12 已进入其生命周期的安全维护阶段，因此已经不再被“推荐”使用。官方的 Python 版本状态里，只有 Python 3.13 目前是绿色标注（推荐）。我们“应该”已经在用它了，但我不禁觉得对大多数用户来说，这多少有点不现实。很多人（我猜）会一直待在旧版本，直到不得不升级。我也不想在这方面把大家推得太紧。

不过，我对新玩具还是很兴奋 🧸

核心内置 CSP

这次的头条功能必须是 在核心内置 Content Security Policy（CSP） 支持。

文档里是这么说的：

Content Security Policy (CSP) 是一种 Web 安全标准，通过限制内容加载来源来帮助防止内容注入攻击。它在全面的安全策略中扮演重要角色。

这是一种纵深防御：在正确转义等手段下你本来就能避免 XSS 等问题，但 CSP 允许你告诉浏览器“只从与当前页面同一主机加载脚本”，例如，这意味着就算意外混入了一个恶意的 <script> 标签，浏览器也会干脆拒绝从其它域加载该资源。

CSP 非常复杂。这是 Django 应该提供的那类“硬电池（hard battery）”的绝佳例子：我们不需要为所有可能的用例都提供每一个小工具（尤其是那些用户自己很容易实现、并可做成包的），但总有一些更难且更需要打磨的问题，确实需要我们提供那一层额外的质量保证。（我个人最喜欢的例子是 Django 的签名工具。我很高兴这些工具属于 Django 本身。）

第三方包 django-csp 多年来一直可用。把它纳入核心应能鼓励更多站点采用，也将其纳入 Django 的稳定性与兼容性保证之下。

这是一个大胜利。

django.tasks

在我写下这些的时候，这部分还没完全合并，但应该会在 alpha 发布前合并。django.tasks 的核心接口与“即时”后端会进入核心。这是 DEP 14 将后台任务引入 Django 的下一步。

用于“延迟任务”的实际数据库后端暂时仍将留在它的独立包里。目标是最终把它合并进来，但我们希望在并入 Django（并受制于较长的发布周期和严格的向后兼容保证）之前，能有空间进行迭代、确保稳定性。

django-tasks 在 Wagtail 里已经用了将近一年。我并不担心它，反而更兴奋看到它在稳步推进。我们可以快，但慢慢来才是王道。

我很想看看现有的队列包——它们众多，而这正是 DEP 的出发点——是否会基于 django.tasks API 提供适配器。这就是我的期望。

template-partials

不过，我最期待的是把 django-template-partials 合并进核心。我在 Django 4.2 时开始做 django-template-partials，并在 Edinburgh 的 DjangoCon Europe 上介绍过。当时我就说，这东西是该进核心的时候了——不管是“partials 本身”，还是沿着同一路子的其他方案。

社区采用非常出色。我们经历了几轮快速反馈，此后它基本上就很稳定了。

今年夏天我在 Google Summer of Code（GSoC） 指导了 Farhan Ali Raza，他把 template-partials 做得非常棒，已经为进核心做好准备。

如果你还没看过，建议读一下 HTMX 的《Template Fragments》文章。当我刚开始这个新项目（刚从 Fellow 角色退下来）时，我就知道我需要这个。我在用 HTMX，而模板 partials 允许你从主模板里只选择一个小片段来渲染用于 AJAX 风格的请求。

新的文档给了一个“用户详情”的示例：

{% partialdef user-info %}
    <div id="user-info-">
        <h3></h3>
        <p></p>
    </div>
{% endpartialdef %}

（Buttondown 的预览似乎不太喜欢这个例子。如果没渲染出来，请点进文档链接看。更新：用 verbatim 标签修好了 👊）

我喜欢这个例子，因为它展示了 partials 的组织性角色。你可以在定义处内联渲染 partials。但很多时候，partial 的内容会变得相当复杂。这种情况下，把它提取到文件的顶部或底部会很舒服，让主模板保持为一个易于扫描的骨架。这能让模板的结构更加清晰。

我做过一个 Alpine.js 表单示例，也展示了我如何用 template-partials 来自定义 Django 表单和字段模板。

通常你会希望用一点 JS 根据用户输入为某个表单字段添加行为。有了 partials，我可以把字段模板设置为一个特定的 partial，而这个 partial 就在与主表单模板同一个文件里（主表单模板本身也可以是一个 partial，且经常就是这样）：

template_name = "user_form.html#bio-field"

`

诸如多字段交互、在表单上持有状态等情况，将表单以及所有字段模板都放在同一个文件里会极大释放你的工作效率。

点进去看看示例吧。

总之，我对 template-partials 进入核心无比兴奋。强烈 YES！💃

Google Summer of Code

多年来，GSoC 一直是 Django 的一大助力。组织起来需要不少工作，我们会收到大量质量一般的申请，但其中总有璀璨的宝石。 Jannis（就提交次数而言，Django 的历史第 2 号贡献者，同时也是 Anaconda 与 PSF 的明星）就是一位 GSoC 学生。 Sage（Django ORM 贡献者、现任 Wagtail 核心团队成员并全职参与 Wagtail）也是 GSoC 学生。

就我担任 Fellow 的那会儿来说，跨数据库的 JSONField 和 核心内置的 Redis 缓存后端 是最亮眼的 GSoC 产物，但按实例字段查找、在应用间迁移模型，等等（还有很多我一时想不全）也都是 GSoC 项目的结果。非常值得我们投入精力。

今年，Farhan 在把 django-template-partials 引入核心方面做得非常出色。这件事的复杂度刚好落在“我自己压在后备清单上一年多、短期也很难往前挪”的区间。毕竟它完全可以一直作为第三方包存在——并不一定非得合并。GSoC 学生的加入恰好给了那缺失的一把力。

总体上，我认为一个好的策略是：把 GSoC 项目指向生态里的第三方包，尤其是那些需要额外帮助或者我们考虑合并进核心的包。要达到 Django 本身要求的质量门槛（主要是边界情况处理）是困难的，需要专门的时间。因此，GSoC 项目就很适合。

似乎每年我们在凑项目想法和导师上都略显吃力。以第三方包为目标的项目通常范围更清晰，而且学生的加入也能给维护者一点动力来清 backlog。如果我们能把“把第三方包作为 GSoC 项目”的预期再推高一点，很可能就能在两端（Django 与生态）都起到帮助。

管理后台键盘快捷键

既然提到 GSoC，就再快速说一下今年另外一个你真的应该看一眼的项目：Rafey Khan 完成的 django-admin-keyshortcuts。 目标是在 Django Admin 中加入键盘快捷键。去看看吧：django-admin-keyshortcuts。

这个包非常简单：只需 pip install 一下，然后加入 INSTALLED_APPS，你就可以开始用了。

理想情况下，这最终会成为 Django Admin 本身的一部分。但作为第三方包的形式让你现在就能用起来，发现问题并反馈。 如果可以，在你的工作项目里试一试!