Python 3.4 有什麼新功能

作者:

R. David Murray <rdmurray@bitdance.com> （編輯者）

本文介紹了 Python 3.4 與 3.3 相比多了哪些新功能。Python 3.1 已於 2014 年 3 月 16 日發布。完整詳情請見 changelog。

也參考

PEP 429 - Python 3.4 發佈時程

發布重點摘要

新增語法特性：

• Python 3.4 沒有新增任何新的語法特性。

其他新特性：

• pip should always be available (PEP 453).

• Newly created file descriptors are non-inheritable (PEP 446).

• command line option for isolated mode (bpo-16499).

• improvements in the handling of codecs that are not text encodings (multiple issues).

• A ModuleSpec Type for the Import System (PEP 451). (Affects importer authors.)

• The marshal format has been made more compact and efficient (bpo-16475).

新的函式庫模組：

• asyncio: 新的用於非同步 IO 的臨時 API (PEP 3156)。

• ensurepip: 初始建置 pip 安裝程式 (PEP 453)。

• enum: 支援列舉型別 (PEP 435)。

• pathlib: 物件導向檔案系統路徑 (PEP 428)。

• selectors: High-level and efficient I/O multiplexing, built upon the select module primitives (part of PEP 3156).

• statistics: A basic numerically stable statistics library (PEP 450).

• tracemalloc: 追蹤 Python 記憶體配置 (PEP 454)。

顯著改進的函式庫模組：

• Single-dispatch generic functions in functools (PEP 443).

• 新的 pickle 協定 4 (PEP 3154)。

• multiprocessing 現在有一個選項可以避免在 Unix 上使用 os.fork (bpo-8713)。

• email has a new submodule, contentmanager, and a new Message subclass (EmailMessage) that simplify MIME handling (bpo-18891).

• The inspect and pydoc modules are now capable of correct introspection of a much wider variety of callable objects, which improves the output of the Python help() system.

• ipaddress 模組 API 已宣告為穩定版本

安全性改進：

• Secure and interchangeable hash algorithm (PEP 456).

• Make newly created file descriptors non-inheritable (PEP 446) to avoid leaking file descriptors to child processes.

• 用於隔離模式的新命令列選項 (bpo-16499)。

• multiprocessing now has an option to avoid using os.fork on Unix. spawn and forkserver are more secure because they avoid sharing data with child processes.

• multiprocessing child processes on Windows no longer inherit all of the parent's inheritable handles, only the necessary ones.

• 新的 hashlib.pbkdf2_hmac() 函式提供了基於密碼的 PKCS#5 密鑰生成函式 2。

• ssl 對 TLSv1.1 和 TLSv1.2 的支援。

• Retrieving certificates from the Windows system cert store support for ssl.

• Server-side SNI (Server Name Indication) support for ssl.

• The ssl.SSLContext class has a lot of improvements.

• All modules in the standard library that support SSL now support server certificate verification, including hostname matching (ssl.match_hostname()) and CRLs (Certificate Revocation lists, see ssl.SSLContext.load_verify_locations()).

CPython 實作改進：

• Safe object finalization (PEP 442).

• Leveraging PEP 442, in most cases module globals are no longer set to None during finalization (bpo-18214).

• Configurable memory allocators (PEP 445).

• Argument Clinic (PEP 436).

Please read on for a comprehensive list of user-facing changes, including many other smaller improvements, CPython optimizations, deprecations, and potential porting issues.

新增功能

PEP 453: Explicit Bootstrapping of PIP in Python Installations

Bootstrapping pip By Default

The new ensurepip module (defined in PEP 453) provides a standard cross-platform mechanism to bootstrap the pip installer into Python installations and virtual environments. The version of pip included with Python 3.4.0 is pip 1.5.4, and future 3.4.x maintenance releases will update the bundled version to the latest version of pip that is available at the time of creating the release candidate.

By default, the commands pipX and pipX.Y will be installed on all platforms (where X.Y stands for the version of the Python installation), along with the pip Python package and its dependencies. On Windows and in virtual environments on all platforms, the unversioned pip command will also be installed. On other platforms, the system wide unversioned pip command typically refers to the separately installed Python 2 version.

The pyvenv command line utility and the venv module make use of the ensurepip module to make pip readily available in virtual environments. When using the command line utility, pip is installed by default, while when using the venv module API installation of pip must be requested explicitly.

For CPython source builds on POSIX systems, the make install and make altinstall commands bootstrap pip by default. This behaviour can be controlled through configure options, and overridden through Makefile options.

On Windows and Mac OS X, the CPython installers now default to installing pip along with CPython itself (users may opt out of installing it during the installation process). Window users will need to opt in to the automatic PATH modifications to have pip available from the command line by default, otherwise it can still be accessed through the Python launcher for Windows as py -m pip.

As discussed in the PEP platform packagers may choose not to install these commands by default, as long as, when invoked, they provide clear and simple directions on how to install them on that platform (usually using the system package manager).

備註

To avoid conflicts between parallel Python 2 and Python 3 installations, only the versioned pip3 and pip3.4 commands are bootstrapped by default when ensurepip is invoked directly - the --default-pip option is needed to also request the unversioned pip command. pyvenv and the Windows installer ensure that the unqualified pip command is made available in those environments, and pip can always be invoked via the -m switch rather than directly to avoid ambiguity on systems with multiple Python installations.

文件更動

As part of this change, the 安裝 Python 模組 and 發布 Python 模組 sections of the documentation have been completely redesigned as short getting started and FAQ documents. Most packaging documentation has now been moved out to the Python Packaging Authority maintained Python Packaging User Guide and the documentation of the individual projects.

However, as this migration is currently still incomplete, the legacy versions of those guides remaining available as 用 setuptools 建置 C 與 C++ 擴充套件 and 用 setuptools 建置 C 與 C++ 擴充套件.

也參考

PEP 453 -- Explicit bootstrapping of pip in Python installations

PEP written by Donald Stufft and Nick Coghlan, implemented by Donald Stufft, Nick Coghlan, Martin von Löwis and Ned Deily.

PEP 446: Newly Created File Descriptors Are Non-Inheritable

PEP 446 makes newly created file descriptors non-inheritable. In general, this is the behavior an application will want: when launching a new process, having currently open files also open in the new process can lead to all sorts of hard to find bugs, and potentially to security issues.

However, there are occasions when inheritance is desired. To support these cases, the following new functions and methods are available: