Kaydet (Commit) dfcfe133 authored tarafından Yury Selivanov's avatar Yury Selivanov

docs/whatsnew/3.5: Update peps section

Patch by Elvis Pranskevichus.
üst 050a143a
...@@ -5,6 +5,8 @@ ...@@ -5,6 +5,8 @@
:Release: |release| :Release: |release|
:Date: |today| :Date: |today|
:Author: Elvis Pranskevichus <elprans@gmail.com> (Editor)
.. Rules for maintenance: .. Rules for maintenance:
* Anyone can add text to this document. Do not spend very much time * Anyone can add text to this document. Do not spend very much time
...@@ -149,106 +151,206 @@ Please read on for a comprehensive list of user-facing changes. ...@@ -149,106 +151,206 @@ Please read on for a comprehensive list of user-facing changes.
PEP written by Carl Meyer PEP written by Carl Meyer
PEP 492 - Coroutines with async and await syntax New Features
------------------------------------------------ ============
The PEP added dedicated syntax for declaring :term:`coroutines <coroutine>`,
:keyword:`await` expressions, new asynchronous :keyword:`async for`
and :keyword:`async with` statements.
Example:: .. _whatsnew-pep-492:
async def read_data(db): PEP 492 - Coroutines with async and await syntax
async with db.transaction(): ------------------------------------------------
data = await db.fetch('SELECT ...')
PEP written and implemented by Yury Selivanov. :pep:`492` greatly improves support for asynchronous programming in Python
by adding :term:`awaitable objects <awaitable>`,
:term:`coroutine functions <coroutine function>`,
:term:`asynchronous iteration <asynchronous iterable>`,
and :term:`asynchronous context managers <asynchronous context manager>`.
Coroutine functions are declared using the new :keyword:`async def` syntax::
>>> async def coro():
... return 'spam'
Inside a coroutine function, a new :keyword:`await` expression can be used
to suspend coroutine execution until the result is available. Any object
can be *awaited*, as long as it implements the :term:`awaitable` protocol by
defining the :meth:`__await__` method.
PEP 492 also adds :keyword:`async for` statement for convenient iteration
over asynchronous iterables.
An example of a simple HTTP client written using the new syntax::
import asyncio
async def http_get(domain):
reader, writer = await asyncio.open_connection(domain, 80)
writer.write(b'\r\n'.join([
b'GET / HTTP/1.1',
b'Host: %b' % domain.encode('latin-1'),
b'Connection: close',
b'', b''
]))
async for line in reader:
print('>>>', line)
writer.close()
loop = asyncio.get_event_loop()
try:
loop.run_until_complete(http_get('example.com'))
finally:
loop.close()
Similarly to asynchronous iteration, there is a new syntax for asynchronous
context managers::
>>> import asyncio
>>> async def coro1(lock):
... print('coro1: waiting for lock')
... async with lock:
... print('coro1: holding the lock')
... await asyncio.sleep(1)
... print('coro1: releasing the lock')
...
>>> async def coro2(lock):
... print('coro2: waiting for lock')
... async with lock:
... print('coro2: holding the lock')
... await asyncio.sleep(1)
... print('coro2: releasing the lock')
...
>>> loop = asyncio.get_event_loop()
>>> lock = asyncio.Lock()
>>> coros = asyncio.gather(coro1(lock), coro2(lock), loop=loop)
>>> loop.run_until_complete(coros)
coro1: waiting for lock
coro1: holding the lock
coro2: waiting for lock
coro1: releasing the lock
coro2: holding the lock
coro2: releasing the lock
>>> loop.close()
Note that both :keyword:`async for` and :keyword:`async with` can only
be used inside a coroutine function declared with :keyword:`async def`.
Coroutine functions are intended to be ran inside a compatible event loop,
such as :class:`asyncio.Loop`.
.. seealso:: .. seealso::
:pep:`492` -- Coroutines with async and await syntax :pep:`492` -- Coroutines with async and await syntax
PEP written and implemented by Yury Selivanov.
PEP 461 - Formatting support for bytes and bytearray PEP 465 - A dedicated infix operator for matrix multiplication
---------------------------------------------------- --------------------------------------------------------------
This PEP proposes adding % formatting operations similar to Python 2's ``str`` :pep:`465` adds the ``@`` infix operator for matrix multiplication.
type to :class:`bytes` and :class:`bytearray`. Currently, no builtin Python types implement the new operator, however, it
can be implemented by defining :meth:`__matmul__`, :meth:`__rmatmul__`,
and :meth:`__imatmul__` for regular, reflected, and in-place matrix
multiplication. The semantics of these methods is similar to that of
methods defining other infix arithmetic operators.
Examples:: Matrix multiplication is a notably common operation in many fields of
mathematics, science, engineering, and the addition of ``@`` allows writing
cleaner code::
>>> b'Hello %s!' % b'World' >>> S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)
b'Hello World!'
>>> b'x=%i y=%f' % (1, 2.5)
b'x=1 y=2.500000'
Unicode is not allowed for ``%s``, but it is accepted by ``%a`` (equivalent of An upcoming release of NumPy 1.10 will add support for the new operator::
``repr(obj).encode('ascii', 'backslashreplace')``)::
>>> b'Hello %s!' % 'World'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: %b requires bytes, or an object that implements __bytes__, not 'str'
>>> b'price: %a' % '10€'
b"price: '10\\u20ac'"
.. seealso:: >>> import numpy
:pep:`461` -- Adding % formatting to bytes and bytearray >>> x = numpy.ones(3)
>>> x
array([ 1., 1., 1.])
>>> m = numpy.eye(3)
>>> m
array([[ 1., 0., 0.],
[ 0., 1., 0.],
[ 0., 0., 1.]])
PEP 465 - A dedicated infix operator for matrix multiplication >>> x @ m
-------------------------------------------------------------- array([ 1., 1., 1.])
This PEP proposes a new binary operator to be used for matrix multiplication,
called ``@``. (Mnemonic: ``@`` is ``*`` for mATrices.)
.. seealso:: .. seealso::
:pep:`465` -- A dedicated infix operator for matrix multiplication :pep:`465` -- A dedicated infix operator for matrix multiplication
PEP written by Nathaniel J. Smith; implemented by Benjamin Peterson.
PEP 448 - Additional Unpacking Generalizations PEP 448 - Additional Unpacking Generalizations
---------------------------------------------- ----------------------------------------------
This PEP proposes extended usages of the ``*`` iterable unpacking :pep:`448` extends the allowed uses of the ``*`` iterable unpacking
operator and ``**`` dictionary unpacking operators operator and ``**`` dictionary unpacking operator. It is now possible
to allow unpacking in more positions, an arbitrary number of to use an arbitrary number of unpackings in function calls::
times, and in additional circumstances. Specifically,
in function calls, in comprehensions and generator expressions, and >>> print(*[1], *[2], 3, *[4, 5])
in displays. 1 2 3 4 5
Function calls are proposed to support an arbitrary number of >>> def fn(a, b, c, d):
unpackings rather than just one:: ... print(a, b, c, d)
...
>>> print(*[1], *[2], 3) >>> fn(**{'a': 1, 'c': 3}, **{'b': 2, 'd': 4})
1 2 3 1 2 3 4
>>> dict(**{'x': 1}, y=2, **{'z': 3})
{'x': 1, 'y': 2, 'z': 3}
Unpacking is proposed to be allowed inside tuple, list, set, Similarly, tuple, list, set, and dictionary displays allow multiple
and dictionary displays:: unpackings::
>>> *range(4), 4 >>> *range(4), 4
(0, 1, 2, 3, 4) (0, 1, 2, 3, 4)
>>> [*range(4), 4] >>> [*range(4), 4]
[0, 1, 2, 3, 4] [0, 1, 2, 3, 4]
>>> {*range(4), 4} >>> {*range(4), 4, *(5, 6, 7)}
{0, 1, 2, 3, 4} {0, 1, 2, 3, 4, 5, 6, 7}
>>> {'x': 1, **{'y': 2}} >>> {'x': 1, **{'y': 2}}
{'x': 1, 'y': 2} {'x': 1, 'y': 2}
In dictionaries, later values will always override earlier ones:: .. seealso::
:pep:`448` -- Additional Unpacking Generalizations
PEP written by Joshua Landau; implemented by Neil Girdhar,
Thomas Wouters, and Joshua Landau.
PEP 461 - % formatting support for bytes and bytearray
------------------------------------------------------
>>> {'x': 1, **{'x': 2}} PEP 461 adds % formatting to :class:`bytes` and :class:`bytearray`, aiding in
{'x': 2} handling data that is a mixture of binary and ASCII compatible text. This
feature also eases porting such code from Python 2.
>>> {**{'x': 2}, 'x': 1} Examples::
{'x': 1}
>>> b'Hello %s!' % b'World'
b'Hello World!'
>>> b'x=%i y=%f' % (1, 2.5)
b'x=1 y=2.500000'
Unicode is not allowed for ``%s``, but it is accepted by ``%a`` (equivalent of
``repr(obj).encode('ascii', 'backslashreplace')``)::
>>> b'Hello %s!' % 'World'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: %b requires bytes, or an object that implements __bytes__, not 'str'
>>> b'price: %a' % '10€'
b"price: '10\\u20ac'"
.. seealso:: .. seealso::
:pep:`448` -- Additional Unpacking Generalizations :pep:`461` -- Adding % formatting to bytes and bytearray
PEP written by Ethan Furman; implemented by Neil Schemenauer and
Ethan Furman.
PEP 484 - Type Hints PEP 484 - Type Hints
...@@ -261,8 +363,8 @@ where annotations are not available. ...@@ -261,8 +363,8 @@ 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::
def greeting(name: str) -> str: def greeting(name: str) -> str:
return 'Hello ' + name return 'Hello ' + name
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 ``Any`` which is consistent with (i.e. assignable to and from) all
...@@ -270,8 +372,10 @@ types. ...@@ -270,8 +372,10 @@ types.
.. seealso:: .. seealso::
* :pep:`484` -- Type Hints
* :mod:`typing` module documentation * :mod:`typing` module documentation
* :pep:`484` -- Type Hints
PEP written by Guido van Rossum, Jukka Lehtosalo, and Łukasz Langa;
implemented by Guido van Rossum.
PEP 471 - os.scandir() function -- a better and faster directory iterator PEP 471 - os.scandir() function -- a better and faster directory iterator
...@@ -282,12 +386,10 @@ to the standard library. Additionally, :func:`os.walk` is now ...@@ -282,12 +386,10 @@ 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 :func:`os.scandir`, which speeds it up by 3-5 times
on POSIX systems and by 7-20 times on Windows systems. on POSIX systems and by 7-20 times on Windows systems.
PEP and implementation written by Ben Hoyt with the help of Victor Stinner.
.. seealso:: .. seealso::
:pep:`471` -- os.scandir() function -- a better and faster directory :pep:`471` -- os.scandir() function -- a better and faster directory iterator
iterator PEP written and implemented by Ben Hoyt with the help of Victor Stinner.
PEP 475: Retry system calls failing with EINTR PEP 475: Retry system calls failing with EINTR
...@@ -357,12 +459,11 @@ not raise an exception: ...@@ -357,12 +459,11 @@ not raise an exception:
* :func:`signal.sigtimedwait`, :func:`signal.sigwaitinfo` * :func:`signal.sigtimedwait`, :func:`signal.sigwaitinfo`
* :func:`time.sleep` * :func:`time.sleep`
PEP and implementation written by Charles-François Natali and Victor Stinner,
with the help of Antoine Pitrou (the french connection).
.. seealso:: .. seealso::
: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
Victor Stinner, with the help of Antoine Pitrou (the french connection).
PEP 479: Change StopIteration handling inside generators PEP 479: Change StopIteration handling inside generators
...@@ -378,12 +479,11 @@ be used:: ...@@ -378,12 +479,11 @@ be used::
Without a ``__future__`` import, a :exc:`PendingDeprecationWarning` will be Without a ``__future__`` import, a :exc:`PendingDeprecationWarning` will be
raised. raised.
PEP written by Chris Angelico and Guido van Rossum. Implemented by
Chris Angelico, Yury Selivanov and Nick Coghlan.
.. seealso:: .. seealso::
:pep:`479` -- Change StopIteration handling inside generators :pep:`479` -- Change StopIteration handling inside generators
PEP written by Chris Angelico and Guido van Rossum. Implemented by
Chris Angelico, Yury Selivanov and Nick Coghlan.
PEP 486: Make the Python Launcher aware of virtual environments PEP 486: Make the Python Launcher aware of virtual environments
...@@ -397,6 +497,7 @@ environment will be used. ...@@ -397,6 +497,7 @@ environment will be used.
.. seealso:: .. seealso::
:pep:`486` -- Make the Python Launcher aware of virtual environments :pep:`486` -- Make the Python Launcher aware of virtual environments
PEP written and implemented by Paul Moore.
PEP 488: Elimination of PYO files PEP 488: Elimination of PYO files
...@@ -414,6 +515,7 @@ has an updated API to help with this change. ...@@ -414,6 +515,7 @@ has an updated API to help with this change.
.. seealso:: .. seealso::
:pep:`488` -- Elimination of PYO files :pep:`488` -- Elimination of PYO files
PEP written and implemented by Brett Cannon.
PEP 489: Multi-phase extension module initialization PEP 489: Multi-phase extension module initialization
...@@ -429,7 +531,10 @@ rather than being restricted to ASCII. ...@@ -429,7 +531,10 @@ rather than being restricted to ASCII.
.. seealso:: .. seealso::
:pep:`488` -- Multi-phase extension module initialization :pep:`489` -- Multi-phase extension module initialization
PEP written by Petr Viktorin, Stefan Behnel, and Nick Coghlan;
implementation by Petr Viktorin.
PEP 485: A function for testing approximate equality PEP 485: A function for testing approximate equality
---------------------------------------------------- ----------------------------------------------------
...@@ -442,6 +547,9 @@ close is determined according to given absolute and relative tolerances. ...@@ -442,6 +547,9 @@ close is determined according to given absolute and relative tolerances.
.. seealso:: .. seealso::
:pep:`485` -- A function for testing approximate equality :pep:`485` -- A function for testing approximate equality
PEP written by Christopher Barker; implemented by Chris Barker and
Tal Einat.
Other Language Changes Other Language Changes
====================== ======================
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment