转自：OSC开源社区（ID：oschina2013)
Python 3.12.0 正式发布稳定版。
主要变化
- 更灵活的 f-string 解析 (PEP 701)
- 支持 buffer 协议 (PEP 688)
- 引入新的 debugging/profiling API (PEP 669)
- 支持具有单独全局解释器锁的独立子解释器 (PEP 684)
- 优化性能，例如 PEP 709 和对 BOLT 二进制优化器的支持，预计总体性能提高 5%
- 改进错误信息
- 支持 Linux perf 分析器在跟踪过程中报告 Python 函数名称
类型注释
- 为泛型类引入新的类型注释语法 (PEP 695)
- 为方法引入新的 override 装饰器 (PEP 698)
下面简单介绍值得关注的变化：
更灵活的 f-string 解析 (PEP 701)
新版取消了最初制定 f-strings 时制定的一些限制。经过这些变化，使得 f-strings 更加统一，成为一种可以直接整合到解析器中的正式化语法。这将会为终端用户和库开发者带来较大优势，同时也大大降低用于解析 f-strings 代码的维护成本。
最初设置 f-strings 限制是为了能够在不修改现有词法分析器的情况下将 f-strings 的解析实现到 CPython 中。但目前来看，这些限制反而带来了复杂性。比如：
>>> f'Magic wand: { bag['wand'] }'
^
SyntaxError: invalid syntax>>> f'Magic wand { bag['wand'] } string'
SyntaxError: f-string expression portion cannot include a backslash>>> f'''A complex trick: {
... bag['bag'] # recursive bags!
... }'''
SyntaxError: f-string expression part cannot include '#'# Ruby
"#{ "#{1+2}" }"
# JavaScript
`${`${1+2}`}`
# Swift
"("(1+2)")"
# C#
$"{$"{1+2}"}"Python 团队意识到，从语言用户的角度来看，这些限制没有任何意义，所以他们目前通过赋予 f-strings 字面量一个没有例外的常规语法，并使用专用的解析代码来实现它，从而消除这些限制。
f-strings 的另一个问题是，CPython 中的当前实现依赖于将 f-strings 标记化为 STRING 令牌，并对这些令牌进行后处理。这带来了以下问题：
f"{y:=3}" 并不是一个赋值表达式）。期待新 f-strings 能用得更顺心。
给每个子解释器创建 GIL (PEP 684)
PEP-684 由“香农计划”的作者 Eric Snow 提出，主要是给每个子解释器创建 GIL，允许 Python 实现真正的并行处理。
说到并行处理，目前 Python 3.12 尚未引入「no-GIL 构建」。
按照计划，Python 团队会在 Python 3.13 中将 no-GIL 构建添加为实验性构建模式。
