Python 3.7 有什么新变化 - 新功能

PEP 563：推迟对注释的评估

Python中类型提示的出现揭示了两个明显的可用性问题 具有 PEP 3107 中添加的注释功能并进行了优化 在 PEP 526 中进一步：

注释只能使用在 当前范围，换句话说，它们不支持前向引用 任何类型的;和

注释源代码对 Python 的启动时间有不利影响 程序。

这两个问题都可以通过推迟评估 附注。而不是编译在 注释在其定义时，编译器存储注释 以等效于相关表达式的 AST 的字符串形式。 如果需要，可以在运行时使用 typing.get_type_hints（） 解析注释。在通常情况下，这不是 必需，注释的存储成本更低（因为短字符串 由口译员扣留），并加快启动时间。

在可用性方面，注释现在支持前向引用，使 以下语法有效：

class C:
    @classmethod
    def from_string(cls, source: str) -> C:
        ...

    def validate_b(self, obj: B) -> bool:
        ...

class B:
    ...

由于此更改破坏了兼容性，因此需要启用新行为 在 Python 3.7 中使用__future__导入的每个模块：

from __future__ import annotations

它将成为 Python 3.10 中的默认值。

参见
PEP 563 – 推迟对注释的评估
PEP由Łukasz Langa编写和实施。

PEP 538：旧版 C 区域设置强制

Python 3 系列中一个持续的挑战是确定一个明智的 处理“7 位 ASCII”文本编码假设的默认策略 目前在非 Windows 上使用默认的 C 或 POSIX 语言环境所暗示 平台。

PEP 538 将默认解释器命令行界面更新为 自动将该区域设置强制转换为可用的基于 UTF-8 的区域设置，作为 在新的 PYTHONCOERCECLOCALE 环境变量的文档中进行了描述。自动设置这种方式意味着 核心解释器和区域设置感知 C 扩展（如 readline）都将假定使用 UTF-8 作为默认文本编码， 而不是 ASCII。LC_CTYPE

PEP 11 中的平台支持定义也已更新，以限制 全文处理支持适当配置的非基于 ASCII 的区域设置。

作为此更改的一部分，stdin 和 stdout 的默认错误处理程序现在（而不是 ）在 使用任何定义的强制目标区域设置（当前为 、 和 ）。stderr 的默认错误处理程序仍然是 ，而不考虑区域设置。surrogateescapestrictC.UTF-8C.utf8UTF-8backslashreplace

默认情况下，区域设置强制是无提示的，但可能有助于调试 与区域设置相关的集成问题，可以通过设置 请求显式警告（直接在 stderr 上发出）。 此设置还会导致 Python 运行时发出警告，如果 初始化核心解释器时，旧版 C 语言环境将保持活动状态。PYTHONCOERCECLOCALE=warn

虽然 PEP 538 的区域设置强制也会影响扩展 模块（如 GNU），以及子进程（包括那些 运行非 Python 应用程序和旧版本的 Python），它具有 要求在运行中存在合适的目标区域设置的缺点 系统。为了更好地处理没有合适的目标区域设置可用的情况 （例如，在RHEL / CentOS 7上发生），Python 3.7也实现了PEP540：强制UTF-8运行时模式。readline

参见
PEP 538 – 将旧版 C 语言环境强制转换为基于 UTF-8 的语言环境
PEP由Nick Coghlan编写和实施。

PEP 540：强制 UTF-8 运行时模式

新的 -X 命令行选项和 PYTHONUTF8 环境变量可用于启用 CPython UTF-8 模式。utf8

在 UTF-8 模式下，CPython 忽略区域设置，并使用 默认情况下为 UTF-8 编码。sys.stdin 和 sys.stdout 流的错误处理程序设置为 。surrogateescape

强制 UTF-8 模式可用于更改 嵌入式 Python 解释器，无需更改 的区域设置。 嵌入应用程序。

虽然 PEP 540 的 UTF-8 模式具有无论哪种模式都可以工作的好处 语言环境在正在运行的系统上可用，它的缺点是没有 对扩展模块（如 GNU）的影响，子进程正在运行 非 Python 应用程序，以及运行旧版本 Python 的子进程。 为了降低与此类文本数据通信时损坏文本数据的风险 组件，Python 3.7 还实现了 PEP 540：强制 UTF-8 运行时模式）。readline

默认情况下，当区域设置为 或 时，将启用 UTF-8 模式，并且 PEP 538 语言环境强制功能无法将其更改为基于 UTF-8 的 替代（无论该故障是由于设置、正在设置还是缺少合适的目标区域设置）。CPOSIXPYTHONCOERCECLOCALE=0LC_ALL

参见
PEP 540 – 添加新的 UTF-8 模式
PEP由Victor Stinner 编写和实施

PEP 553：内置breakpoint()

Python 3.7 包含新的内置断点 （） 函数，如 一种简单而一致的方法来进入 Python 调试器。

内置调用 sys.breakpointhook（）。默认情况下， 后者导入 PDB 然后调用 ，但通过绑定到您选择的函数，可以 输入任何调试器。此外，环境变量 PYTHON断点可以设置为调试器的可调用对象 选择。设置为完全禁用内置 .breakpoint()pdb.set_trace()sys.breakpointhook()breakpoint()PYTHONBREAKPOINT=0breakpoint()

参见
PEP 553 – 内置断点（）
由Barry Warsaw编写和实施的PEP

PEP 539：用于线程本地存储的新 C API

虽然 Python 为线程本地存储支持提供了 C API;现有的线程本地存储 （TLS） API 用于表示跨所有平台的 TLS 密钥。这还没有 对于官方支持的平台来说，这通常是一个问题，但这不是 符合POSIX标准，在任何实际意义上也不便携。int

PEP 539 通过提供新的线程特定存储 （TSS） 来改变这一点 CPython 的 API，取代了 CPython 解释器中的现有 TLS API，同时弃用现有的 应用程序接口。TSS API 使用新的类型Py_tss_t而不是表示 TSS 密钥 - 一种不透明的类型，其定义可能取决于 基础 TLS 实现。因此，这将允许建立CPython 在以无法安全的方式定义本机 TLS 密钥的平台上 投射到 。intint

请注意，在以无法定义本机 TLS 密钥的方式定义的平台上 被安全地转换为，现有TLS API的所有功能都将是 无操作并立即返回失败。这清楚地表明旧的 API 在无法可靠使用的平台上不受支持，并且没有 将努力增加这种支持。int

参见
PEP 539 – CPython 中用于线程本地存储的新 C-API
PEP由Erik M. Bray撰写;山本雅之实施。

PEP 562：自定义对模块属性的访问

Python 3.7 允许在模块上定义 getattr（） 并将调用 每当找不到模块属性时。现在还允许在模块上定义 dir（）。

这可能有用的一个典型示例是模块属性弃用 和延迟加载。

参见
PEP 562 – 模块和__getattr____dir__
PEP由Ivan Levkivskyi编写和实施

PEP 564：具有纳秒分辨率的新时间函数

现代系统中时钟的分辨率可能超过有限的精度 由 time.time（） 函数返回的浮点数 及其变体。为避免精度损失，PEP 564 增加了六个新的 时间模块现有计时器函数的“纳秒”变体：

time.clock_gettime_ns（）

time.clock_settime_ns（）

time.monotonic_ns（）

time.perf_counter_ns（）

time.process_time_ns（）

time.time_ns（）

新函数以整数值的形式返回纳秒数。

测量表明，在Linux和Windows上，time.time_ns（）的分辨率是 大约是 Time.Time（） 的 3 倍。

参见
PEP 564 – 添加具有纳秒分辨率的新时间函数
PEP由Victor Stinner 编写和实施

PEP 565：在 中显示弃用警告__main__

弃用警告的默认处理已更改，以便 默认情况下，这些警告再次显示，但仅当代码 触发它们直接在__main__模块中运行。结果， 单个文件脚本的开发人员和以交互方式使用 Python 的开发人员应该 再次开始看到他们使用的 API 的弃用警告，但是 导入的应用程序、库和框架触发的弃用警告 默认情况下，模块将继续隐藏。

由于此更改，标准库现在允许开发人员选择 在三种不同的弃用警告行为之间：

未来警告：默认始终显示，建议用于警告 旨在供应用程序最终用户查看（例如，对于已弃用的应用程序 配置设置）。

弃用警告：默认情况下仅在__main__和何时显示 运行测试，建议用于其他 Python 看到的警告 版本升级可能导致行为更改或 错误。

挂起弃用警告：默认情况下仅在运行时显示 测试，适用于将来的版本升级将更改 警告类别为弃用警告或未来警告。

以前，DeprecationWarning 和 PendingDeprecationWarning 仅在运行测试时可见，这意味着开发人员主要 编写单个文件脚本或交互式使用 Python 可能会感到惊讶 通过中断他们使用的 API 中的更改。

参见
PEP 565 – 在 中显示弃用警告__main__
PEP由Nick Coghlan编写和实施

PEP 560：模块和泛型类型的核心支持typing

最初，PEP 484的设计方式是不会对核心CPython解释器进行任何更改。现在，社区广泛使用了类型提示和键入模块，因此删除了此限制。 PEP引入了两个特殊的方法__class_getitem__（）和，这些方法现在被大多数类和特殊的 键入中的构造。结果，各种操作的速度 类型最多增加 7 倍，泛型类型可以在没有 元类冲突，以及类型模块中几个长期存在的错误是 固定。mro_entries

参见
PEP 560 – 对键入模块和泛型类型的核心支持
PEP由Ivan Levkivskyi编写和实施

PEP 552：基于哈希的 .pyc 文件

Python传统上检查字节码缓存文件的最新性 （即文件）通过比较源元数据（上次修改的时间戳 和大小），源元数据保存在缓存文件头中，当它 生成。虽然有效，但这种无效方法有其缺点。什么时候 文件系统时间戳太粗糙，Python 可能会错过源代码更新，导致 用户困惑。此外，在缓存文件中具有时间戳是 构建可重现性和存在问题 基于内容的构建系统。.pyc

PEP 552 扩展了 pyc 格式，以允许源文件的哈希 用于失效而不是源时间戳。此类文件是 称为“基于哈希”。默认情况下，Python 仍然使用基于时间戳的失效 并且不会在运行时生成基于哈希的文件。可以使用py_compile或编译生成基于哈希的文件。.pyc.pyc.pyc

基于哈希的文件有两种变体：选中和未选中。蟒 根据相应的源验证已检查的基于哈希的文件 文件，但对于未经检查的基于哈希的 pyC，不会这样做。猖獗 基于哈希的文件是环境性能优化的有用方法 其中 Python 外部的系统（例如，构建系统）负责 使文件保持最新。.pyc.pyc.pyc.pyc

有关详细信息，请参阅缓存字节码失效。

参见
PEP 552 – 确定性 pyc
PEP由Benjamin Peterson编写和实施

PEP 545：Python 文档翻译

PEP 545描述了创建和维护Python的过程 文档翻译。

添加了三个新翻译：

日语：https://docs.python.org/ja/

法语： https://docs.python.org/fr/

韩语： https://docs.python.org/ko/

参见
PEP 545 – Python 文档翻译
PEP由Julien Palard，Inada Naoki和 维克多·斯廷纳。

开发运行时模式：-X 开发

新的 -X 命令行选项或新的 PYTHONDEVMODE 环境变量可用于启用 CPython的发展模式。在开发模式下，CPython 执行 默认情况下，成本太高而无法启用的其他运行时检查。 有关效果的完整说明，请参阅 -X 文档 的这种模式。devdev