What’s New In Python 3.7¶
- Editor:
Elvis Pranskevichus <elvis@magic.io>
This article explains the new features in Python 3.7, compared to 3.6. Python 3.7 was released on June 27, 2018. For full details, see the changelog.
Summary – Release Highlights¶
New syntax features:
PEP 563, postponed evaluation of type annotations.
Backwards incompatible syntax changes:
New library modules:
New built-in features:
PEP 553, the new
breakpoint()function.
Python data model improvements:
PEP 562, customization of access to module attributes.
PEP 560, core support for typing module and generic types.
the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.
Significant improvements in the standard library:
The
asynciomodule has received new features, significant usability and performance improvements.The
timemodule gained support for functions with nanosecond resolution.
CPython implementation improvements:
Avoiding the use of ASCII as a default text encoding:
PEP 552, deterministic .pycs
PEP 565, improved
DeprecationWarninghandling
C API improvements:
PEP 539, new C API for thread-local storage
Documentation improvements:
PEP 545, Python documentation translations
New documentation translations: Japanese, French, and Korean.
This release features notable performance improvements in many areas. The Optimizations section lists them in detail.
For a list of changes that may affect compatibility with previous Python releases please refer to the Porting to Python 3.7 section.
New Features¶
PEP 563: Postponed Evaluation of Annotations¶
The advent of type hints in Python uncovered two glaring usability issues with the functionality of annotations added in PEP 3107 and refined further in PEP 526:
annotations could only use names which were already available in the current scope, in other words they didn’t support forward references of any kind; and
annotating source code had adverse effects on startup time of Python programs.
Both of these issues are fixed by postponing the evaluation of
annotations. Instead of compiling code which executes expressions in
annotations at their definition time, the compiler stores the annotation
in a string form equivalent to the AST of the expression in question.
If needed, annotations can be resolved at runtime using
typing.get_type_hints(). In the common case where this is not
required, the annotations are cheaper to store (since short strings
are interned by the interpreter) and make startup time faster.
Usability-wise, annotations now support forward references, making the following syntax valid:
class C:
@classmethod
def from_string(cls, source: str) -> C:
...
def validate_b(self, obj: B) -> bool:
...
class B:
...
Since this change breaks compatibility, the new behavior needs to be enabled
on a per-module basis in Python 3.7 using a __future__ import:
from __future__ import annotations
It will become the default in Python 3.10.
See also
- PEP 563 – Postponed evaluation of annotations
PEP written and implemented by Łukasz Langa.
PEP 538: Legacy C Locale Coercion¶
An ongoing challenge within the Python 3 series has been determining a sensible default strategy for handling the “7-bit ASCII” text encoding assumption currently implied by the use of the default C or POSIX locale on non-Windows platforms.
PEP 538 updates the default interpreter command line interface to
automatically coerce that locale to an available UTF-8 based locale as
described in the documentation of the new PYTHONCOERCECLOCALE
environment variable. Automatically setting LC_CTYPE this way means that
both the core interpreter and locale-aware C extensions (such as
readline) will assume the use of UTF-8 as the default text encoding,
rather than ASCII.
The platform support definition in PEP 11 has also been updated to limit full text handling support to suitably configured non-ASCII based locales.
As part of this change, the default error handler for stdin and
stdout is now surrogateescape (rather than strict) when
using any of the defined coercion target locales (currently C.UTF-8,
C.utf8, and UTF-8). The default error handler for stderr
continues to be backslashreplace, regardless of locale.
Locale coercion is silent by default, but to assist in debugging potentially
locale related integration problems, explicit warnings (emitted directly on
stderr) can be requested by setting PYTHONCOERCECLOCALE=warn.
This setting will also cause the Python runtime to emit a warning if the
legacy C locale remains active when the core interpreter is initialized.
While PEP 538’s locale coercion has the benefit of also affecting extension
modules (such as GNU readline), as well as child processes (including those
running non-Python applications and older versions of Python), it has the
downside of requiring that a suitable target locale be present on the running
system. To better handle the case where no suitable target locale is available
(as occurs on RHEL/CentOS 7, for example), Python 3.7 also implements
PEP 540: Forced UTF-8 Runtime Mode.
See also
- PEP 538 – Coercing the legacy C locale to a UTF-8 based locale
PEP written and implemented by Nick Coghlan.
PEP 540: Forced UTF-8 Runtime Mode¶
The new -X utf8 command line option and PYTHONUTF8
environment variable can be used to enable the Python UTF-8 Mode.
When in UTF-8 mode, CPython ignores the locale settings, and uses the
UTF-8 encoding by default. The error handlers for sys.stdin and
sys.stdout streams are set to surrogateescape.
The forced UTF-8 mode can be used to change the text handling behavior in an embedded Python interpreter without changing the locale settings of an embedding application.
While PEP 540’s UTF-8 mode has the benefit of working regardless of which
locales are available on the running system, it has the downside of having no
effect on extension modules (such as GNU readline), child processes running
non-Python applications, and child processes running older versions of Python.
To reduce the risk of corrupting text data when communicating with such
components, Python 3.7 also implements PEP 540: Forced UTF