<div dir="ltr"><div class="gmail_quote"><div>[Nick Coghlan]</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>> ...<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>> "NAME := EXPR" exists on a different level of complexity, since it<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>> adds name binding in arbitrary expressions for the sake of minor<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>> performance improvement in code written by developers that are<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>> exceptionally averse to the use of vertical screen real estate,</div><div class="gmail_quote">> ...<br><br></div><div class="gmail_quote">Note that PEP 572 doesn't contain a single word about "performance" (neither that specific word nor any synonym), and I gave only one thought to it when writing Appendix A:  "is this going to slow anything down significantly?".  The answer was never "yes", which I thought was self-evident, so I never mentioned it.  Neither did Chris or Guido.<br><br>Best I can recall, nobody has argued for it on the grounds of "performance". except in the indirect sense that sometimes it allows a more compact way of reusing an expensive subexpression by giving it a name.   Which they already do by giving it a name in a separate statement, so the possible improvement would be in brevity rather than performance.<br><br>The attractions are instead in the areas of reducing redundancy, improving clarity, allowing to remove semantically pointless indentation levels in some cases, indeed trading away some horizontal whitespace in otherwise nearly empty lines for freeing up a bit of vertical screen space, and in the case of comprehensions/genexps adding straightforward ways to accomplish some conceptually trivial things that at best require trickery now (like emulating a cell object by hand).<br><br>Calling all that "for the sake of minor performance improvements" - which isn't even in the list -  is sooooo far off base it should have left me speechless - but it didn't ;-)<br><br>But now that you mention it, ya, there will be a trivial performance improvement in some cases.  I couldn't care less about that, and can confidently channel that Guido doesn't either.  It would remain fine by me if assignment expressions ran trivially slower.<br><br></div></div>