[Python-checkins] peps: PEP 448: Update from Joshua Landau.

[berker.peksag]

https://hg.python.org/peps/rev/04cfd59d12fb
changeset:   5687:04cfd59d12fb
user:        Berker Peksag <berker.peksag at gmail.com>
date:        Mon Feb 02 15:31:33 2015 +0200
summary:
  PEP 448: Update from Joshua Landau.

files:
  pep-0448.txt |  41 ++++++++++++++++++++++-----------------
  1 files changed, 23 insertions(+), 18 deletions(-)


diff --git a/pep-0448.txt b/pep-0448.txt
--- a/pep-0448.txt
+++ b/pep-0448.txt
@@ -16,11 +16,11 @@
 ========
 
 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 @@
     >>> {'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 @@
 
 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 @@
 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 @@
 
     {**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.
 

-- 
Repository URL: https://hg.python.org/peps