<div dir="ltr">I think I'll bow out of this now.  It's just too tedious.<br><br>Like here:<br>

<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br>[Nick]<br>> I never said the motivation was to gain performance relative to the</span><br style="text-decoration-style:initial;text-decoration-color:initial"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> two-statement version - I said the motivation given in the PEP is to</span><br style="text-decoration-style:initial;text-decoration-color:initial"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> gain performance relative to the *repeated subexpression* version,</span><br style="text-decoration-style:initial;text-decoration-color:initial"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> *without* making the transition to the already supported two-statement</span><br style="text-decoration-style:initial;text-decoration-color:initial"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> version.</span><br style="text-decoration-style:initial;text-decoration-color:initial">

<br>This is what you wrote:<br><br><div>>> "NAME := EXPR" exists on a different level of complexity, since it</div><div>>> adds name binding in arbitrary expressions for the sake of minor</div><div>>> performance improvement in code written by developers that are</div><div>>> exceptionally averse to the use of vertical screen real estate,</div><div><br>I'm not telepathic, so took it for it what said.  It didn't say a word about "repeated expressions", nor a word about "two-statement versions"<br><br>It did say "minor" performance improvements, which sure suggested to me that you had in mind the tiny changes in bytecode that can result from squashing a current two-statement spelling into a one-statement form with an embedded assignment.  That fit both "minor performance improvement" and "vertical screen space", which were the only the two clues I had to go on.<br><br>In the example you eventually gave in a later message, the performance difference was more on the order of a factor 2 (regexp searches can be expensive indeed), which matches nobody's idea of "minor".  So the use of "minor" wholly ruled out in my mind that you had _anything_ akin to your eventual example in mind.<br><br>For the rest, sure, words could be added to the PEP without end.   At least some of the points I covered were telegraphically mentioned in my Appendix, although I'll grant that nobody else is telepathic either ;-)<br></div><div class="gmail_quote"><div><br>For the question:<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote>> The remaining point of contention is only the "Inevitable cost 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>> change" one: given the level of disruption this will cause in the way<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 Python gets taught to new users, is it giving a commensurate<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>> pay-off in increased semantic expressiveness?<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>> My answer to that question remains "No", while your answer is either<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>> "Yes" or "I don't see why that should matter" (I'm genuinely unsure<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>> which).<br><br>I don't know, and I'm not qualified to guess - I don't teach Python to new users for a living.<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span>  </span>Decades ago I tutored "advanced" engineering undergrads in a variety of science-y subjects, and was routinely surprised by what broke their brains.</span>

<br><br>I have noted that assignment expressions have been part of a great many languages for decades (this isn't cutting edge tech), questions about them are conspicuous by absence on StackOverflow (everyone else seems to teach them effectively), and skimming various online teaching materials for other languages convinced me that none of those professional educators thought it needed more than a page to teach (and to teach them with relatively few words).  There's really not much to them:  people have to learn what binding means in Python regardless, pretty much starting in the first hour, yes?  "Binding" on its own is the hard part.<br><br>If they don't drop out and stick around for the 10-minute lesson on assignment expressions 3 weeks later, will _that_ finally break their brains?  "Wow - it not only binds the name, but ALSO returns the object that was bound?!  I just can't take it - please, let's go back to the lesson on metaclasses" just doesn't seem likely to me ;-)<br><br></div><div class="gmail_quote">At heart, ":=" could make a good case for being the simplest of all Python's operators.  It does no computation at all, and you don't even have to worry about a dunder method changing its meaning depending on context.<br><br>So, ya, when someone claims they'll make Python significantly harder to teach, I'm skeptical of that claim.  Which does not mean I believe it's wrong - it means I'm skeptical.  I would also be skeptical of a claim that teaching them would be no trouble at all, except nobody has made such a claim ;-)<br></div></div>