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

[Rob Cliffe]

I apologise for not replying in the form of a Pull Request - I don't 
know how to make one.


On 10/07/2018 02:00, Guido van Rossum wrote:
> Rationale
> =========
>
> Naming the result of an expression is an important part of programming,
> allowing a descriptive name to be used in place of a longer expression,
> and permitting reuse.  Currently, this feature is available only in
> statement form, making it unavailable in list comprehensions and other
> expression contexts.
I think the wording of the last sentence gives too much importance to 
list comprehensions (IMO influenced by the amount of discussion of the 
PEP that was related to list comprehensions, understandably since that 
was the case where the semantics were most debatable).  I would suggest
"... making it unavailable in expression contexts."
or maybe
"... making it unavailable in expression contexts (including list 
comprehension)."

> Another example illustrates that programmers sometimes do more work to
> save an extra level of indentation::
>
>     match1 = pattern1.match(data)
>     match2 = pattern2.match(data)
>     if match1:
>         return match1.group(1)
>     elif match2:
>         return match2.group(2)
>
> This code tries to match ``pattern2`` even if ``pattern1`` has a match
> (in which case the match on ``pattern2`` is never used). The more
> efficient rewrite would have been::
>
>     match1 = pattern1.match(data)
>     if match1:
>         return match1.group(1)
>     else:
>         match2 = pattern2.match(data)
>         if match2:
>             return match2.group(2)
I suggest
... The more efficient rewrite would have been:
     match1 = pattern1.match(data)
     if match1:
         return match1.group(1)
     match2 = pattern2.match(data)
     if match2:
         return match2.group(2)
(a more natural way to write it which avoids cascading indentation).

>     # Handle a matched regex
>     if (match := pattern.search(data)) is not None:
>         ...
I suggest
     # Handle a matched regex
     if (match := pattern.search(data)) is not None:
         # do something with match
I think it is really important to make clear the benefit of the PEP 
here: that "match" is bound to a value and can be used subsequently.

>     # A more explicit alternative to the 2-arg form of iter() invocation
>     while (value := read_next_item()) is not None:
>         ...
As the 2-arg form of iter() is not that well known, I suggest that the 
iter version is spelled out for contrast.  (Sorry, I can't quite work it 
what it would be.)

>     # Share a subexpression between a comprehension filter clause and 
> its output
>     filtered_data = [y for x in data if (y := f(x)) is not None]
That's fine, but what about also having an example that illustrates, 
simply, the "permitting reuse" in an expression part of the Rationale, e.g.
         powers = [ (y := x+1), y**2, y**3, y**4 ]
(I appreciate that this sort of overlaps with the section "Simplifying 
list comprehensions", but it seems to me to be such an important part of 
the Rationale that it should be illustrated here.)

> Relative precedence of ``:=``
> -----------------------------
>
> The ``:=`` operator groups more tightly than a comma in all syntactic
> positions where it is legal, but less tightly than all operators,
> including ``or``, ``and`` and ``not``.
and presumably including "if" and "else", as in
     x := y if y else -1
Might it be worth adding "if" and "else" to the list?


> - Single assignment targets other than than a single ``NAME`` are
>   not supported::
>
>     # No equivalent
>     a[i] = x
>     self.rest = []
>
> [snip]
>
> - Iterable packing and unpacking (both regular or extended forms) are
>   not supported::
>
>     # Equivalent needs extra parentheses
>     loc = x, y  # Use (loc := (x, y))
>     info = name, phone, *rest  # Use (info := (name, phone, *rest))
>
>     # No equivalent
>     px, py, pz = position
>     name, phone, email, *other_info = contact
>
> [snip]
>     total += tax  # Equivalent: (total := total + tax)
Is it conceivable that some of these restrictions might be removed in a 
future version of Python?  If so, the PEP might include a note to this 
effect.

Oh, and what I think are typos:

(Note that ``with EXPR as VAR`` does *not* simply assing the value
    of ``EXPR`` to ``VAR`` -- it calls ``EXPR.__enter__()`` and assigns
    the result of *that* to ``VAR``.)

     assing -> assign

(eg where the condition is ``f(x) < 0``

     eg -> e.g.

members of the core-mentorship mailing list

     core-mentorship -> core mentorship

is a vast improvment over the briefer::

     improvment -> improvement

Best wishes
Rob Cliffe