PEP 572: Tweaks suggested by Glenn Linderman and Tim Peters (#718)

* PEP 572: Tweaks suggested on python-dev by Glenn Linderman.
* Use Tim's rewording of the exceptional cases.
* Clarify that TargetScopeError is a *new* subclass of SyntaxError.
This commit is contained in:
Guido van Rossum 2018-07-10 11:02:30 -07:00 committed by GitHub
parent 145c034e89
commit 9c61127920
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 18 additions and 10 deletions

View File

@ -148,7 +148,7 @@ in order to avoid ambiguities or user confusion:
(y := f(x)) # Valid, though not recommended (y := f(x)) # Valid, though not recommended
This rule is included to simplify the choice for the user between an This rule is included to simplify the choice for the user between an
assignment statements and an assignment expression -- there is no assignment statement and an assignment expression -- there is no
syntactic position where both are valid. syntactic position where both are valid.
- Unparenthesized assignment expressions are prohibited at the top - Unparenthesized assignment expressions are prohibited at the top
@ -235,13 +235,21 @@ comprehension, for example::
partial_sums = [total := total + v for v in values] partial_sums = [total := total + v for v in values]
print("Total:", total) print("Total:", total)
An exception to this special case applies when the target name is the However, an assignment expression target name cannot be the same as a
same as a loop control variable for a comprehension containing it. ``for``-target name appearing in any comprehension containing the
This is invalid. This exception exists to rule out edge cases of the assignment expression. The latter names are local to the
above scope rules as illustrated by ``[i := i+1 for i in range(5)]`` comprehension in which they appear, so it would be contradictory for a
or ``[[(j := j) for i in range(5)] for j in range(5)]``. Note that contained use of the same name to refer to the scope containing the
this exception also applies to ``[i := 0 for i, j in stuff]``, as well outermost comprehension instead.
as to cases like ``[i+1 for i in i := stuff]``.
For example, ``[i := i+1 for i in range(5)]`` is invalid: the ``for
i`` part establishes that ``i`` is local to the comprehension, but the
``i :=`` part insists that ``i`` is not local to the comprehension.
The same reason makes these examples invalid too::
[[(j := j) for i in range(5)] for j in range(5)]
[i := 0 for i, j in stuff]
[i+1 for i in i := stuff]
A further exception applies when an assignment expression occurs in a A further exception applies when an assignment expression occurs in a
comprehension whose containing scope is a class scope. If the rules comprehension whose containing scope is a class scope. If the rules
@ -260,13 +268,13 @@ See Appendix B for some examples of how the rules for targets in
comprehensions translate to equivalent code. comprehensions translate to equivalent code.
The two invalid cases listed above raise ``TargetScopeError``, a The two invalid cases listed above raise ``TargetScopeError``, a
subclass of ``SyntaxError`` (with the same signature). new subclass of ``SyntaxError`` (with the same signature).
Relative precedence of ``:=`` Relative precedence of ``:=``
----------------------------- -----------------------------
The ``:=`` operator groups more tightly than a comma in all syntactic The ``:=`` operator groups more tightly than a comma in all syntactic
positions where it is legal, but less tightly than all operators, positions where it is legal, but less tightly than all other operators,
including ``or``, ``and`` and ``not``. As follows from section including ``or``, ``and`` and ``not``. As follows from section
"Exceptional cases" above, it is never allowed at the same level as "Exceptional cases" above, it is never allowed at the same level as
``=``. In case a different grouping is desired, parentheses should be ``=``. In case a different grouping is desired, parentheses should be