iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 448: Update from Joshua Landau.

This commit is contained in:
Berker Peksag 2015-02-02 15:31:33 +02:00
parent 50d36874be
commit dcb8279caf
1 changed files with 23 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
pep-0448.txt
View File

@ -16,11 +16,11 @@ Abstract
========
This PEP proposes extended usages of the ``*`` iterable unpacking
operator and ``**`` dictionary unpacking operator
operator and ``**`` dictionary unpacking operators
to allow unpacking in more positions, an arbitrary number of
times, and in additional circumstances. Specifically
in function calls, in comprehensions and generator expressions,
and in displays.
times, and in additional circumstances. Specifically,
in function calls, in comprehensions and generator expressions, and
in displays.
Function calls are proposed to support an arbitrary number of
unpackings rather than just one::
@ -42,8 +42,7 @@ and dictionary displays::
>>> {'x': 1, **{'y': 2}}
{'x': 1, 'y': 2}
In sets and dictionaries, this provides a concise overriding
notation::
In dictionaries, later values will always override earlier ones::
>>> {'x': 1, **{'x': 2}}
{'x': 2}
@ -124,7 +123,9 @@ list(my_range)`` which is now equivalent to just ``[*my_list,
The addition of unpacking to comprehensions is a logical extension.
It's usage will primarily be a neat replacement for ``[i for j in
2D_list for i in j]``, as the more readable ``[*l for l in 2D_list]``.
list_of_lists for i in j]``, as the more readable
``[*l for l in list_of_lists]``. The iterable version,
``(*l for l in list_of_lists)``, replaces ``itertools.chain.from_iterable``.
Other uses are possible, but expected to occur rarely.
@ -143,7 +144,7 @@ follow ``*`` unpackings.
Currently, if an argument is given multiple times — such as a
positional argument given both positionally and by keyword — a
``TypeError`` is raised. This remains true for duplicate arguments
provided through multiple keyword argument unpackings,
provided through multiple ``**`` unpackings,
e.g. ``f(**{'x': 2}, **{'x': 3})``.
A function looks like this::
@ -176,22 +177,26 @@ For example::
{**locals(), "override": None}
However, ``f(*x for x in it)`` and ``f(**x for x in it)`` continue
to raise SyntaxError.
Unbracketed comprehensions in function calls, such as ``f(x for x in it)``,
are already valid. These could be extended to::
f(*x for x in it) == f((*x for x in it))
f(**x for x in it) == f({**x for x in it})
However, this is likely to be confusing and is not included in this
PEP. These will throw ``SyntaxError`` and comprehensions with explicit
brackets should be used instead.
Disadvantages
=============
The allowable orders for arguments in a function call is more
complicated than before.
The simplest explanation for the rules may be "positional arguments
come first and keyword arguments follow, but iterable unpackings are
allowed after keyword arguments" or "iterable arguments precede
all keyword arguments and keyword argument unpackings, and iterable
argument unpackings precede all keyword argument unpackings".
The allowable orders for arguments in a function call are more
complicated than before. The simplest explanation for the rules
may be "positional arguments precede keyword arguments and ``**``
unpacking; ``*`` unpacking precedes ``**`` unpacking".
While ``*elements, = iterable`` causes ``elements`` to be a list,
Whilst ``*elements, = iterable`` causes ``elements`` to be a list,
``elements = *iterable,`` causes ``elements`` to be a tuple. The
reason for this may confuse people unfamiliar with the construct.