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

Guido van Rossum guido at python.org
Tue Jul 10 00:15:37 EDT 2018

On Mon, Jul 9, 2018 at 8:24 PM, Rob Cliffe via Python-Dev < python-dev at python.org> wrote:

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)."

Hm, I don't think it's worth tweaking the text here. The PEP has some choice things to say about comprehensions, and I don't mind calling them out especially here. Also, when you need a temporary variable outside a comprehension it's easy enough to rewrite the code a bit -- but for a comprehension you'd have to refactor the whole comprehension away (into a regular for-loop), which is a bit more effort.

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).

Hm, I think I might have simplified this a bit from the code I actually found -- there might not have been a return in the original. I don't want to break the if...elif pattern in the rewrite. I guess I'll rewrite it using assignment to a variable instead of return.

# 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 := readnextitem()) 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.)

Hm, you have a point there. I was referring to

for value in iter(read_next_item, None): ...

The example would be more convincing if there was an additional argument to read_next_value(), since then the 2-arg iter() version would have required a lambda. Maybe I shouldn't mention 2-arg iter here at all.

# Share a subexpression between a comprehension filter clause and its

output filtereddata = [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), y2, y3, 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.)

I could add this (before the filtered_data example):

# Reuse a value that's expensive to compute
[y := f(x), y**2, y**3]

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?

Good call, I'll add conditional expressions 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, *otherinfo = 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.

I wouldn't hold my breath.

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

Fixed already.

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

eg -> e.g.

Thanks, will fix.

members of the core-mentorship mailing list

core-mentorship -> core mentorship

Why? The list is named core-mentorship at python.org.

is a vast improvment over the briefer::

improvment -> improvement

Will fix.

Best wishes Rob Cliffe

https://github.com/python/peps/pull/719

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180709/c9ab5a21/attachment-0001.html>

More information about the Python-Dev mailing list