On Mon, Jul 9, 2018 at 8:24 PM, Rob Cliffe via Python-Dev < python-dev@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 := 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.) > 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 >> 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.) > 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, *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. > 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-mentors...@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)
_______________________________________________ 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