Python 3.3 有什麼新功能

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

也參考

PEP 398 - Python 3.3 發佈時程

發布重點摘要

新增語法特性：

新的函式庫模組：

  • faulthandler (helps debugging low-level crashes)

  • ipaddress (high-level objects representing IP addresses and masks)

  • lzma (compress data using the XZ / LZMA algorithm)

  • unittest.mock (replace parts of your system under test with mock objects)

  • venv (Python virtual environments, as in the popular virtualenv package)

新的內建功能：

實作改進：

顯著改進的函式庫模組：

安全性改進：

  • 預設情況下，雜湊隨機化處於打開狀態。

Please read on for a comprehensive list of user-facing changes.

PEP 405：虛擬環境

Virtual environments help create separate Python setups while sharing a system-wide base install, for ease of maintenance. Virtual environments have their own set of private site packages (i.e. locally installed libraries), and are optionally segregated from the system-wide site packages. Their concept and implementation are inspired by the popular virtualenv third-party package, but benefit from tighter integration with the interpreter core.

This PEP adds the venv module for programmatic access, and the pyvenv script for command-line access and administration. The Python interpreter checks for a pyvenv.cfg, file whose existence signals the base of a virtual environment's directory tree.

也參考

PEP 405 - Python 虛擬環境

由 Carl Meyer 撰寫 PEP；由 Carl Meyer 與 Vinay Sajip 實作

PEP 420: Implicit Namespace Packages

Native support for package directories that don't require __init__.py marker files and can automatically span multiple path segments (inspired by various third party approaches to namespace packages, as described in PEP 420)

也參考

PEP 420 - Implicit Namespace Packages

由 Eric V. Smith 撰寫 PEP；由 Eric V. Smith 和 Barry Warsaw 實施

PEP 3118: New memoryview implementation and buffer protocol documentation

The implementation of PEP 3118 has been significantly improved.

The new memoryview implementation comprehensively fixes all ownership and lifetime issues of dynamically allocated fields in the Py_buffer struct that led to multiple crash reports. Additionally, several functions that crashed or returned incorrect results for non-contiguous or multi-dimensional input have been fixed.

The memoryview object now has a PEP-3118 compliant getbufferproc() that checks the consumer's request type. Many new features have been added, most of them work in full generality for non-contiguous arrays and arrays with suboffsets.

The documentation has been updated, clearly spelling out responsibilities for both exporters and consumers. Buffer request flags are grouped into basic and compound flags. The memory layout of non-contiguous and multi-dimensional NumPy-style arrays is explained.

功能

  • All native single character format specifiers in struct module syntax (optionally prefixed with '@') are now supported.

  • With some restrictions, the cast() method allows changing of format and shape of C-contiguous arrays.

  • Multi-dimensional list representations are supported for any array type.

  • Multi-dimensional comparisons are supported for any array type.

  • One-dimensional memoryviews of hashable (read-only) types with formats B, b or c are now hashable. (Contributed by Antoine Pitrou in bpo-13411.)

  • Arbitrary slicing of any 1-D arrays type is supported. For example, it is now possible to reverse a memoryview in O(1) by using a negative step.

API 變更

  • The maximum number of dimensions is officially limited to 64.

  • The representation of empty shape, strides and suboffsets is now an empty tuple instead of None.

  • Accessing a memoryview element with format 'B' (unsigned bytes) now returns an integer (in accordance with the struct module syntax). For returning a bytes object the view must be cast to 'c' first.

  • memoryview comparisons now use the logical structure of the operands and compare all array elements by value. All format strings in struct module syntax are supported. Views with unrecognised format strings are still permitted, but will always compare as unequal, regardless of view contents.

  • For further changes see Build and C API Changes and Porting C code.

（由 Stefan Krah 在 bpo-10181 中貢獻。）

也參考

PEP 3118 - 修訂緩衝協定

PEP 393: Flexible String Representation

The Unicode string type is changed to support multiple internal representations, depending on the character with the largest Unicode ordinal (1, 2, or 4 bytes) in the represented string. This allows a space-efficient representation in common cases, but gives access to full UCS-4 on all systems. For compatibility with existing APIs, several representations may exist in parallel; over time, this compatibility should be phased out.

On the Python side, there should be no downside to this change.

On the C API side, PEP 393 is fully backward compatible. The legacy API should remain available at least five years. Applications using the legacy API will not fully benefit of the memory reduction, or - worse - may use a bit more memory, because Python may have to maintain two versions of each string (in the legacy format and in the new efficient storage).

功能性

PEP 393 引入的更改如下：

  • Python now always supports the full range of Unicode code points, including non-BMP ones (i.e. from U+0000 to U+10FFFF). The distinction between narrow and wide builds no longer exists and Python now behaves like a wide build, even under Windows.

  • With the death of narrow builds, the problems specific to narrow builds have also been fixed, for example:

    • len() now always returns 1 for non-BMP characters, so len('\U0010FFFF') == 1;

    • surrogate pairs are not recombined in string literals, so '\uDBFF\uDFFF' != '\U0010FFFF';

    • indexing or slicing non-BMP characters returns the expected value, so '\U0010FFFF'[0] now returns '\U0010FFFF' and not '\uDBFF';

    • all other functions in the standard library now correctly handle non-BMP code points.

  • The value of sys.maxunicode is now always 1114111 (0x10FFFF in hexadecimal). The PyUnicode_GetMax() function still returns either 0xFFFF or 0x10FFFF for backward compatibility, and it should not be used with the new Unicode API (see bpo-13054).

  • ./configure 旗標 --with-wide-unicode 已被刪除。

性能和資源使用情況

The storage of Unicode strings now depends on the highest code point in the string:

  • pure ASCII and Latin1 strings (U+0000-U+00FF) use 1 byte per code point;

  • BMP strings (U+0000-U+FFFF) use 2 bytes per code point;

  • non-BMP strings (U+10000-U+10FFFF) use 4 bytes per code point.

The net effect is that for most applications, memory usage of string storage should decrease significantly - especially compared to former wide unicode builds - as, in many cases, strings will be pure ASCII even in international contexts (because many strings store non-human language data, such as XML fragments, HTTP headers, JSON-encoded data, etc.). We also hope that it will, for the same reasons, increase CPU cache efficiency on non-trivial applications. The memory usage of Python 3.3 is two to three times smaller than Python 3.2, and a little bit better than Python 2.7, on a Django benchmark (see the PEP for details).

也參考

PEP 393 - Flexible String Representation

PEP 由 Martin von Löwis 撰寫；由 Torsten Becker 和 Martin von Löwis 實作。

PEP 397：適用於 Windows 的 Python 啟動器

The Python 3.3 Windows installer now includes a py launcher application that can be used to launch Python applications in a version independent fashion.

This launcher is invoked implicitly when double-clicking *.py files. If only a single Python version is installed on the system, that version will be used to run the file. If multiple versions are installed, the most recent version is used by default, but this can be overridden by including a Unix-style "shebang line" in the Python script.

The launcher can also be used explicitly from the command line as the py application. Running py follows the same version selection rules as implicitly launching scripts, but a more specific version can be selected by passing appropriate arguments (such as -3 to request Python 3 when Python 2 is also installed, or -2.6 to specifically request an earlier Python version when a more recent version is installed).

In addition to the launcher, the Windows installer now includes an option to add the newly installed Python to the system PATH. (Contributed by Brian Curtin in bpo-3561.)

也參考

PEP 397 - 適用於 Windows 的 Python 啟動器

由 Mark Hammond 和 Martin v. Löwis 撰寫 PEP；由 Vinay Sajip 實作。

啟動器文件：Python 安裝管理員

Installer PATH modification: Python 安裝管理員

PEP 3151: Reworking the OS and IO exception hierarchy

The hierarchy of exceptions raised by operating system errors is now both simplified and finer-grained.

You don't have to worry anymore about choosing the appropriate exception type between OSError, IOError, EnvironmentError, WindowsError, mmap.error, socket.error or select.error. All these exception types are now only one: OSError. The other names are kept as aliases for compatibility reasons.

Also, it is now easier to catch a specific error condition. Instead of inspecting the errno attribute (or args[0]) for a particular constant from the errno module, you can catch the adequate OSError subclass. The available subclasses are the following: