<div dir="ltr"><div class="gmail_quote"><div dir="ltr">[Nick Coghlan]</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div></blockquote>>>> "NAME := EXPR" exists on a different level of complexity, since it<br>>>> adds name binding in arbitrary expressions for the sake of minor<br>>>> performance improvement in code written by developers that are<br>>>> exceptionally averse to the use of vertical screen real estate,<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>>> ...<br></div><div class="gmail_quote"><div> <br>[Tim]</div><div>>> Note that PEP 572 doesn't contain a single word about "performance" (neither</div><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> that specific word nor any synonym), and I gave only one thought to it when<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> writing Appendix A:  "is this going to slow anything down significantly?".<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> The answer was never "yes", which I thought was self-evident, so I never<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> mentioned it.  Neither did Chris or Guido.<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> Best I can recall, nobody has argued for it on the grounds of "performance".<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> except in the indirect sense that sometimes it allows a more compact way of<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> reusing an expensive subexpression by giving it a name.   Which they already<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> do by giving it a name in a separate statement, so the possible improvement<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> would be in brevity rather than performance.<br><br>[Nick]<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>> The PEP specifically cites this example as motivation:<br><br>The PEP gives many examples.  Your original was a strawman mischaracterization of the PEP's _motivations_ (note the plural:  you only mentioned "minor performance improvement", and snipped my listing of the major motivations).<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>   group = re.match(data).group(1) if re.match(data) else None<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> That code's already perfectly straightforward to read and write as a<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> single line,<br><br>I disagree.  In any case of textual repetition, it's a visual pattern-matching puzzle to identify the common substrings (I have to visually scan that line about 3 times to be sure), and then a potentially difficult conceptual puzzle to figure out whether side effects may result in textually identical substrings evaluating to different objects.  That's why "refererential transparency" is so highly valued in functional languages ("if subexpressions are spelled the same, they evaluate to the same result, period" - which isn't generally true in Python - to get that enormously helpful (to reasoning) guarantee in Python you have to ensure the subexpression is evaluated exactly once).<br><br>And as you of all people should be complaining about, textual repetition is also prone to "oops - forgot one!" and "oops! made a typo when changing the second one!" when code is later modified.<br><br>> so the only reason to quibble about it<br><br>I gave you three better reasons to quibble about it just above ;-)<br><br><br></div><div class="gmail_quote">> is because it's slower than the arguably less clear two-line alternative:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>  _m = re.match(data)<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>   group = _m.group(1) if _m else None<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><br>I find that much clearer than the one-liner above:  the visual pattern matching is easier because the repeated substring is shorter and of much simpler syntactic structure; it guarantees _by construction_ that the two instances of `_m` evaluate to the same object, so there's no possible concern about that (it doesn't even matter if you bound `re` to some "non-standard" object that has nothing to do with Python's `re` module); and any later changes to the single instance of `re.match(data)` don't have to be repeated verbatim elsewhere.  It's possible that it runs twice as fast too, but that's the least of my concerns.</div><div class="gmail_quote"><br></div><div class="gmail_quote">All of those advantages are retained in the one-liner too if an assignment expression can be used in it.<br><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> Thus the PEP's argument is that it wants to allow the faster version<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> to remain a one-liner that preserves the overall structure of the<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> version that repeats the subexpression:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> group = _m.group(1) if _m := re.match(data) else None<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> That's a performance argument, not a readability one (as if you don't<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> care about performance, you can just repeat the subexpression).<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><br>How does that differ from the part of what I said that you did retain above?<br><br><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">>> sometimes it allows a more compact way of </span><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">reusing an expensive</span></div><div class="gmail_quote"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">>> subexpression by giving it a name.   Which they already </span><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">do by giving</span></div><div class="gmail_quote"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">>> it a name in a separate statement, so the possible improvement </span><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">would</span></div><div class="gmail_quote">>> be in brevity rather than performance.<br><br>You already realized the performance gain could be achieved by using two statements.  The _additional_ performance gain by using assignment expressions is at best trivial (it may save a LOAD_FAST opcode to fetch the object bound to `_m` for the `if` test).<br><br>So, no, gaining performance is _not_ the motivation here.  You already had a way to make it "run fast'.  The motivation is the _brevity_ assignment expressions allow while _retaining_ all of the two-statement form's advantages in easier readability, easier reasoning, reduced redundancy, and performance.<br><br>As Guido said, in the PEP, of the example you gave here:<br><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span style="background-color:rgb(249,249,249);color:rgb(68,68,68);font-family:SourceSansProRegular,Arial,sans-serif;font-size:15px">Guido found several examples where a programmer repeated<br> a subexpression, slowing down the program, in order to save</span><div class="gmail_quote"><span style="color:rgb(68,68,68);font-family:SourceSansProRegular,Arial,sans-serif;font-size:15px;background-color:rgb(249,249,249);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">one line of code</span></div></blockquote><div class="gmail_quote"><span style="color:rgb(68,68,68);font-family:SourceSansProRegular,Arial,sans-serif;background-color:rgb(249,249,249);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br><font size="2">It couldn't possibly be clearer that Guido thought the programmer's motivation was brevity ("in order to save one line of code").  Guido only happened to mention that they were willing to slow down the code to get that brevity, but, as above, they were also willing to make the code harder to read, reason about, and maintain.  With the assignment expression, they don't have to give up any of the latter to get the brevity they mistakenly _think_ ;-) they care most about - and, indeed, they can make it even briefer.<br><br>I sure don't count it against the PEP that it may trick people overly concerned with brevity into writing code that's clearer and faster too, but that's a tiny indirect part of the PEP's motivation_s_ (note the plural again).<br></font><br></span></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote">

</div></blockquote></div>