osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft


On 7/9/2018 6:00 PM, Guido van Rossum wrote:
> This rule is included to simplify the choice for the user between an
> ? assignment statements and an assignment expression -- there is no

"statements" should not be plural in the above line.

> syntactic position where both are valid.


> An exception to this special case applies when the target name is the
> same as a loop control variable for a comprehension containing it.
> This is invalid.? This exception exists to rule out edge cases of the
> above scope rules as illustrated by ``[i := i+1 for i in range(5)]``
> or ``[[(j := j) for i in range(5)] for j in range(5)]``.? Note that
> this exception also applies to ``[i := 0 for i, j in stuff]``, as well
> as to cases like ``[i+1 for i in i := stuff]``.


It is unclear whether exactly what is invalid. Is the use of the target 
name that is the same as (any of the nested) loop control variable 
invalid? I think, from discussions, that that is what is meant. But this 
paragraph could be interpreted as meaning the special case doesn't 
apply, meaning that the target name would be in a "sublocal" scope.


> The ``:=`` operator groups more tightly than a comma in all syntactic
> positions where it is legal, but less tightly than all operators,

If comma is considered an operator, this sentence is inconsistent, would 
need to be "all other operators".? Even if comma is not considered an 
operator, the sentence would be more clear with "other" added, since 
":=" is an operator.


Sorry, I haven't learned pull requests.
Glenn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180709/7e78dd42/attachment.html>