Python 3.3 的新功能

This article explains the new features in Python 3.3, compared to 3.2. Python 3.3 was released on September 29, 2012. For full details, see the changelog .

另请参阅

PEP 398 - Python 3.3 Release Schedule

摘要 – 发行亮点

新句法特征:

新的库模块:

新的内置特征:

Implementation improvements:

Significantly Improved Library Modules:

Security improvements:

  • Hash randomization is switched on by default.

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 Virtual Environments

PEP written by Carl Meyer; implementation by Carl Meyer and Vinay Sajip

PEP 420:隐式名称空间包

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

PEP written by Eric V. Smith; implementation by Eric V. Smith and Barry Warsaw

PEP 3118: New memoryview implementation and buffer protocol documentation

实现为 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 构建和 C API 变化 and Porting C code .

(Contributed by Stefan Krah in bpo-10181 )。

另请参阅

PEP 3118 - Revising the Buffer Protocol

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).

功能

Changes introduced by PEP 393 are the following:

  • 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' 和不 '\uDBFF' ;

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

  • 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 ).

  • The ./configure flag --with-wide-unicode 已被移除。

Performance and resource usage

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 written by Martin von Löwis; implementation by Torsten Becker and Martin von Löwis.

PEP 397: Python Launcher for Windows

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 - Python Launcher for Windows

PEP written by Mark Hammond and Martin v. Löwis; implementation by Vinay Sajip.

Launcher documentation: 用于 Windows 的 Python 启动器

Installer PATH modification: Finding the Python executable

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:

And the ConnectionError itself has finer-grained subclasses:

Thanks to the new exceptions, common usages of the errno can now be avoided. For example, the following code written for Python 3.2:

from errno import ENOENT, EACCES, EPERM
try:
    with open("document.txt") as f:
        content = f.read()
except IOError as err:
    if err.errno == ENOENT:
        print("document.txt file is missing")
    elif err.errno in (EACCES, EPERM):
        print("You are not allowed to read document.txt")
    else:
        raise