whatsnew/3.5 More edits

Patch by Elvis Praskevichus.  (+ issue #25070)
This commit is contained in:
Yury Selivanov 2015-09-12 17:50:58 -04:00
parent 46a8b40ca8
commit 95fd26bc01
1 changed files with 168 additions and 48 deletions

View File

@ -73,11 +73,14 @@ New syntax features:
* :pep:`465`, a new matrix multiplication operator: ``a @ b``. * :pep:`465`, a new matrix multiplication operator: ``a @ b``.
* :pep:`448`, additional unpacking generalizations. * :pep:`448`, additional unpacking generalizations.
New library modules: New library modules:
* :mod:`typing`: :ref:`Type Hints <whatsnew-pep-484>` (:pep:`484`).
* :mod:`zipapp`: :ref:`Improving Python ZIP Application Support * :mod:`zipapp`: :ref:`Improving Python ZIP Application Support
<whatsnew-zipapp>` (:pep:`441`). <whatsnew-zipapp>` (:pep:`441`).
New built-in features: New built-in features:
* ``bytes % args``, ``bytearray % args``: :pep:`461` - Adding ``%`` formatting * ``bytes % args``, ``bytearray % args``: :pep:`461` - Adding ``%`` formatting
@ -100,6 +103,7 @@ New built-in features:
* New :exc:`StopAsyncIteration` exception. (Contributed by * New :exc:`StopAsyncIteration` exception. (Contributed by
Yury Selivanov in :issue:`24017`. See also :pep:`492`.) Yury Selivanov in :issue:`24017`. See also :pep:`492`.)
CPython implementation improvements: CPython implementation improvements:
* When the ``LC_TYPE`` locale is the POSIX locale (``C`` locale), * When the ``LC_TYPE`` locale is the POSIX locale (``C`` locale),
@ -114,32 +118,32 @@ CPython implementation improvements:
* Builtin and extension modules are now initialized in a multi-phase process, * Builtin and extension modules are now initialized in a multi-phase process,
which is similar to how Python modules are loaded. (:pep:`489`). which is similar to how Python modules are loaded. (:pep:`489`).
Significantly improved library modules:
* :class:`collections.OrderedDict` is now implemented in C, which makes it Significant improvements in standard library:
4 to 100 times faster. (Contributed by Eric Snow in :issue:`16991`.)
* You may now pass bytes to the :mod:`tempfile` module's APIs and it will * :class:`collections.OrderedDict` is now
return the temporary pathname as :class:`bytes` instead of :class:`str`. :ref:`implemented in C <whatsnew-ordereddict>`, which makes it
It also accepts a value of ``None`` on parameters where only str was 4 to 100 times faster.
accepted in the past to do the right thing based on the types of the
other inputs. Two functions, :func:`gettempdirb` and
:func:`gettempprefixb`, have been added to go along with this.
This behavior matches that of the :mod:`os` APIs.
(Contributed by Gregory P. Smith in :issue:`24230`.)
* :mod:`ssl` module gained support for Memory BIO, which decouples SSL * :mod:`ssl` module gained
protocol handling from network IO. (Contributed by Geert Jansen in :ref:`support for Memory BIO <whatsnew-sslmemorybio>`, which decouples SSL
:issue:`21965`.) protocol handling from network IO.
* :mod:`traceback` has new lightweight and convenient to work with * :mod:`traceback` module has been significantly
classes :class:`~traceback.TracebackException`, :ref:`enhanced <whatsnew-traceback>` for improved
:class:`~traceback.StackSummary`, and :class:`~traceback.FrameSummary`. performance and developer convenience.
(Contributed by Robert Collins in :issue:`17911`.)
* The new :func:`os.scandir` function provides a
:ref:`better and significantly faster way <whatsnew-pep-471>`
of directory traversal.
* :func:`functools.lru_cache` has been largely
:ref:`reimplemented in C <whatsnew-lrucache>`, yielding much better
performance.
* The new :func:`subprocess.run` function provides a
:ref:`streamlined way to run subprocesses <whatsnew-subprocess>`.
* Most of :func:`functools.lru_cache` machinery is now implemented in C.
(Contributed by Matt Joiner, Alexey Kachayev, and Serhiy Storchaka
in :issue:`14373`.)
Security improvements: Security improvements:
@ -152,6 +156,7 @@ Security improvements:
against potential injection attacks. (Contributed by Antoine Pitrou against potential injection attacks. (Contributed by Antoine Pitrou
in :issue:`22796`.) in :issue:`22796`.)
Windows improvements: Windows improvements:
* A new installer for Windows has replaced the old MSI. * A new installer for Windows has replaced the old MSI.
@ -160,6 +165,7 @@ Windows improvements:
* Windows builds now use Microsoft Visual C++ 14.0, and extension modules * Windows builds now use Microsoft Visual C++ 14.0, and extension modules
should use the same. should use the same.
Please read on for a comprehensive list of user-facing changes, including many Please read on for a comprehensive list of user-facing changes, including many
other smaller improvements, CPython optimizations, deprecations, and potential other smaller improvements, CPython optimizations, deprecations, and potential
porting issues. porting issues.
@ -238,7 +244,7 @@ context managers. The following script::
finally: finally:
loop.close() loop.close()
will print:: will output::
coro 2: waiting for lock coro 2: waiting for lock
coro 2: holding the lock coro 2: holding the lock
@ -352,22 +358,29 @@ unpackings::
PEP 461 - % formatting support for bytes and bytearray PEP 461 - % formatting support for bytes and bytearray
------------------------------------------------------ ------------------------------------------------------
PEP 461 adds % formatting to :class:`bytes` and :class:`bytearray`, aiding in PEP 461 adds support for ``%``
handling data that is a mixture of binary and ASCII compatible text. This :ref:`interpolation operator <bytes-formatting>` to :class:`bytes`
feature also eases porting such code from Python 2. and :class:`bytearray`.
While interpolation is usually thought of as a string operation, there are
cases where interpolation on ``bytes`` or ``bytearrays`` make sense, and the
work needed to make up for this missing functionality detracts from the
overall readability of the code. This issue is particularly important when
dealing with wire format protocols, which are often a mixture of binary
and ASCII compatible text.
Examples:: Examples::
>>> b'Hello %s!' % b'World' >>> b'Hello %b!' % b'World'
b'Hello World!' b'Hello World!'
>>> b'x=%i y=%f' % (1, 2.5) >>> b'x=%i y=%f' % (1, 2.5)
b'x=1 y=2.500000' b'x=1 y=2.500000'
Unicode is not allowed for ``%s``, but it is accepted by ``%a`` (equivalent of Unicode is not allowed for ``%b``, but it is accepted by ``%a`` (equivalent of
``repr(obj).encode('ascii', 'backslashreplace')``):: ``repr(obj).encode('ascii', 'backslashreplace')``)::
>>> b'Hello %s!' % 'World' >>> b'Hello %b!' % 'World'
Traceback (most recent call last): Traceback (most recent call last):
File "<stdin>", line 1, in <module> File "<stdin>", line 1, in <module>
TypeError: %b requires bytes, or an object that implements __bytes__, not 'str' TypeError: %b requires bytes, or an object that implements __bytes__, not 'str'
@ -375,6 +388,9 @@ Unicode is not allowed for ``%s``, but it is accepted by ``%a`` (equivalent of
>>> b'price: %a' % '10€' >>> b'price: %a' % '10€'
b"price: '10\\u20ac'" b"price: '10\\u20ac'"
Note that ``%s`` and ``%r`` conversion types, although supported, should
only be used in codebases that need compatibility with Python 2.
.. seealso:: .. seealso::
:pep:`461` -- Adding % formatting to bytes and bytearray :pep:`461` -- Adding % formatting to bytes and bytearray
@ -387,9 +403,17 @@ Unicode is not allowed for ``%s``, but it is accepted by ``%a`` (equivalent of
PEP 484 - Type Hints PEP 484 - Type Hints
-------------------- --------------------
This PEP introduces a provisional module to provide these standard Function annotation syntax has been a Python feature since version 3.0
definitions and tools, along with some conventions for situations (:pep:`3107`), however the semantics of annotations has been left undefined.
where annotations are not available.
Experience has shown that the majority of function annotation
uses were to provide type hints to function parameters and return values. It
became evident that it would be beneficial for Python users, if the
standard library included the base definitions and tools for type annotations.
:pep:`484` introduces a :term:`provisional module <provisional api>` to
provide these standard definitions and tools, along with some conventions
for situations where annotations are not available.
For example, here is a simple function whose argument and return type For example, here is a simple function whose argument and return type
are declared in the annotations:: are declared in the annotations::
@ -397,9 +421,14 @@ are declared in the annotations::
def greeting(name: str) -> str: def greeting(name: str) -> str:
return 'Hello ' + name return 'Hello ' + name
While these annotations are available at runtime through the usual
:attr:`__annotations__` attribute, *no automatic type checking happens at
runtime*. Instead, it is assumed that a separate off-line type checker will
be used for on-demand source code analysis.
The type system supports unions, generic types, and a special type The type system supports unions, generic types, and a special type
named ``Any`` which is consistent with (i.e. assignable to and from) all named :class:`~typing.Any` which is consistent with (i.e. assignable to
types. and from) all types.
.. seealso:: .. seealso::
@ -407,6 +436,8 @@ types.
* :pep:`484` -- Type Hints * :pep:`484` -- Type Hints
PEP written by Guido van Rossum, Jukka Lehtosalo, and Łukasz Langa; PEP written by Guido van Rossum, Jukka Lehtosalo, and Łukasz Langa;
implemented by Guido van Rossum. implemented by Guido van Rossum.
* :pep:`483` -- The Theory of Type Hints
PEP written by Guido van Rossum
.. _whatsnew-pep-471: .. _whatsnew-pep-471:
@ -416,8 +447,14 @@ PEP 471 - os.scandir() function -- a better and faster directory iterator
:pep:`471` adds a new directory iteration function, :func:`os.scandir`, :pep:`471` adds a new directory iteration function, :func:`os.scandir`,
to the standard library. Additionally, :func:`os.walk` is now to the standard library. Additionally, :func:`os.walk` is now
implemented using :func:`os.scandir`, which speeds it up by 3-5 times implemented using ``os.scandir()``, which makes it 3 to 5 times faster
on POSIX systems and by 7-20 times on Windows systems. on POSIX systems and 7 to 20 times faster on Windows systems. This is
largely achieved by greatly reducing the number of calls to :func:`os.stat`
required to walk a directory tree.
Additionally, ``os.scandir()`` returns an iterator, as opposed to returning
a list of file names, which improves memory efficiency when iterating
over very large directories.
.. seealso:: .. seealso::
@ -430,14 +467,39 @@ on POSIX systems and by 7-20 times on Windows systems.
PEP 475: Retry system calls failing with EINTR PEP 475: Retry system calls failing with EINTR
---------------------------------------------- ----------------------------------------------
:pep:`475` adds support for automatic retry of system calls failing with A :py:data:`~errno.EINTR` error code is returned whenever a system call, that
:py:data:`~errno.EINTR`: this means that user code doesn't have to deal with is waiting for I/O, is interrupted by a signal. Previously, Python would
``EINTR`` or :exc:`InterruptedError` manually, and should make it more robust raise :exc:`InterruptedError` in such case. This meant that, when writing a
against asynchronous signal reception. Python application, the developer had two choices:
Examples of functions which are now retried when interrupted by a signal #. Ignore the ``InterruptedError``.
instead of raising :exc:`InterruptedError` if the Python signal handler does #. Handle the ``InterruptedError`` and attempt to restart the interrupted
not raise an exception: system call at every call site.
The first option makes an application fail intermittently.
The second option adds a large amount of boilerplate that makes the
code nearly unreadable. Compare::
print("Hello World")
and::
while True:
try:
print("Hello World")
break
except InterruptedError:
continue
:pep:`475` implements automatic retry of system calls on
``EINTR``. This removes the burden of dealing with ``EINTR``
or :exc:`InterruptedError` in user code in most situations and makes
Python programs, including the standard library, more robust. Note that
the system call is only retried if the signal handler does not raise an
exception.
Below is a list of functions which are now retried when interrupted
by a signal:
* :func:`open`, :func:`os.open`, :func:`io.open`; * :func:`open`, :func:`os.open`, :func:`io.open`;
@ -476,7 +538,7 @@ not raise an exception:
:pep:`475` -- Retry system calls failing with EINTR :pep:`475` -- Retry system calls failing with EINTR
PEP and implementation written by Charles-François Natali and PEP and implementation written by Charles-François Natali and
Victor Stinner, with the help of Antoine Pitrou (the french connection). Victor Stinner, with the help of Antoine Pitrou (the French connection).
.. _whatsnew-pep-479: .. _whatsnew-pep-479:
@ -484,15 +546,27 @@ not raise an exception:
PEP 479: Change StopIteration handling inside generators PEP 479: Change StopIteration handling inside generators
-------------------------------------------------------- --------------------------------------------------------
:pep:`479` changes the behavior of generators: when a :exc:`StopIteration` The interaction of generators and :exc:`StopIteration` in Python 3.4 and
earlier was somewhat surprising, and could conceal obscure bugs. Previously,
``StopIteration`` raised accidentally inside a generator function was
interpreted as the end of the iteration by the loop construct driving the
generator.
:pep:`479` changes the behavior of generators: when a ``StopIteration``
exception is raised inside a generator, it is replaced with a exception is raised inside a generator, it is replaced with a
:exc:`RuntimeError`. To enable the feature a ``__future__`` import should :exc:`RuntimeError` before it exits the generator frame. The main goal of
be used:: this change is to ease debugging in the situation where an unguarded
:func:`next` call raises ``StopIteration`` and causes the iteration controlled
by the generator to terminate silently. This is particularly pernicious in
combination with the ``yield from`` construct.
This is a backwards incompatible change, so to enable the new behavior,
a :term:`__future__` import is necessary::
from __future__ import generator_stop from __future__ import generator_stop
Without a ``__future__`` import, a :exc:`PendingDeprecationWarning` will be Without a ``__future__`` import, a :exc:`PendingDeprecationWarning` will be
raised. raised whenever a ``StopIteration`` exception is raised inside a generator.
.. seealso:: .. seealso::
@ -641,6 +715,18 @@ The :class:`~argparse.ArgumentParser` class now allows to disable
Steven Bethard, paul j3 and Daniel Eriksson in :issue:`14910`.) Steven Bethard, paul j3 and Daniel Eriksson in :issue:`14910`.)
asyncio
-------
Since :mod:`asyncio` module is :term:`provisional <provisional api>`,
all changes introduced in Python 3.5 have also been backported to Python 3.4.x.
Notable changes in :mod:`asyncio` module since Python 3.4.0:
* The proactor event loop now supports SSL.
(Contributed by Antoine Pitrou and Victor Stinner in :issue:`22560`.)
bz2 bz2
--- ---
@ -681,6 +767,8 @@ interpreter. (Contributed by Claudiu Popa in :issue:`17442`.)
collections collections
----------- -----------
.. _whatsnew-ordereddict:
The :class:`~collections.OrderedDict` class is now implemented in C, which The :class:`~collections.OrderedDict` class is now implemented in C, which
makes it 4 to 100 times faster. (Contributed by Eric Snow in :issue:`16991`.) makes it 4 to 100 times faster. (Contributed by Eric Snow in :issue:`16991`.)
@ -886,6 +974,8 @@ descriptors in addition to file-like objects.
functools functools
--------- ---------
.. _whatsnew-lrucache:
Most of :func:`~functools.lru_cache` machinery is now implemented in C, making Most of :func:`~functools.lru_cache` machinery is now implemented in C, making
it significantly faster. (Contributed by Matt Joiner, Alexey Kachayev, and it significantly faster. (Contributed by Matt Joiner, Alexey Kachayev, and
Serhiy Storchaka in :issue:`14373`.) Serhiy Storchaka in :issue:`14373`.)
@ -1355,6 +1445,8 @@ a :func:`~collections.namedtuple`. (Contributed by Claudiu Popa in
ssl ssl
--- ---
.. _whatsnew-sslmemorybio:
Memory BIO Support Memory BIO Support
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
@ -1463,6 +1555,8 @@ in particular :func:`reversed` iteration and slice indexing.
Jessica McKellar, and Serhiy Storchaka in :issue:`13583`.) Jessica McKellar, and Serhiy Storchaka in :issue:`13583`.)
.. _whatsnew-subprocess:
subprocess subprocess
---------- ----------
@ -1482,7 +1576,7 @@ A new :func:`~sys.set_coroutine_wrapper` function allows setting a global
hook that will be called whenever a :term:`coroutine object <coroutine>` hook that will be called whenever a :term:`coroutine object <coroutine>`
is created by an :keyword:`async def` function. A corresponding is created by an :keyword:`async def` function. A corresponding
:func:`~sys.get_coroutine_wrapper` can be used to obtain a currently set :func:`~sys.get_coroutine_wrapper` can be used to obtain a currently set
wrapper. Both functions are :term:`provisional <provisional package>`, wrapper. Both functions are :term:`provisional <provisional api>`,
and are intended for debugging purposes only. (Contributed by Yury Selivanov and are intended for debugging purposes only. (Contributed by Yury Selivanov
in :issue:`24017`.) in :issue:`24017`.)
@ -1556,6 +1650,8 @@ module which makes no permanent changes to environment variables.
(Contributed by Zachary Ware in :issue:`20035`.) (Contributed by Zachary Ware in :issue:`20035`.)
.. _whatsnew-traceback:
traceback traceback
--------- ---------
@ -1883,6 +1979,16 @@ function or module names. Introduced by :pep:`492` in Python 3.5, they will
become proper keywords in Python 3.7. become proper keywords in Python 3.7.
Deprecated Python Behavior
--------------------------
Raising :exc:`StopIteration` inside a generator will now generate a silent
:exc:`PendingDeprecationWarning`, which will become a non-silent deprecation
warning in Python 3.6 and will trigger a :exc:`RuntimeError` in Python 3.7.
See :ref:`PEP 479: Change StopIteration handling inside generators <whatsnew-pep-479>`
for details.
Unsupported Operating Systems Unsupported Operating Systems
----------------------------- -----------------------------
@ -1982,6 +2088,20 @@ Porting to Python 3.5
This section lists previously described changes and other bugfixes This section lists previously described changes and other bugfixes
that may require changes to your code. that may require changes to your code.
Changes in Python behavior
--------------------------
* Due to an oversight, earlier Python versions erroneously accepted the
following syntax::
f(1 for x in [1], *args)
f(1 for x in [1], **kwargs)
Python 3.5 now correctly raises a :exc:`SyntaxError`, as generator
expressions must be put in parentheses if not a sole argument to a function.
Changes in the Python API Changes in the Python API
------------------------- -------------------------