[Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft (original) (raw)
Rob Cliffe rob.cliffe at btinternet.com
Mon Jul 9 23:24:19 EDT 2018
- Previous message (by thread): [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft
- Next message (by thread): [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 ifpattern1
has a match (in which case the match onpattern2
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 := 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.)
# 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.)
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, includingor
,and
andnot
. 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, *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.
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
- Previous message (by thread): [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft
- Next message (by thread): [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]