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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
