当前位置：首页 > news >正文

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

news 来源：原创 2024/4/26 1:05:26

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编写和实施