<div dir="ltr"><div class="gmail_quote"><div dir="ltr">[Tim]<br>>> Regardless of how assignment expressions work in listcomps and genexps,<br>>> this example (which uses neither) _will_ rebind the containing block's `x`:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>>> [x := 1]<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>

<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">[Chris Barker]</span><br style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">

> This reinforces my point that it’s not just about comprehensions,</div><div class="gmail_quote"><br>I agree, it's not at all - and I'm amazed at the over-the-top passion that minor issues of scope in comprehensions have ... inspired.  It's the tip of the tail of the dog.<br><br></div><div class="gmail_quote">> but rather that the local namespace can be altered anywhere<br>> an expression is used  — which is everywhere.<br><br>Yes, everywhere.  But what of it?  Have you read the PEP?  The examples are all simple and straightforward and "local".  My example above was wholly contrived to make a specific point, and I expect we'll _never_ see that line in real code.<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><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 trivial example is unsurprising, but as soon as your<br>> line of code gets a bit longer, it could be far more hidden.<br><br>It's not possible to prevent people from writing horrible code, and I'm hard pressed to think of _any_ programming feature that can't be so abused.  From ridiculouslyLongVariableNamesWhoseVerbostiySeemsToBeAGoalInItself. massive overuse of globals, insanely deep nesting, horridly redundant parenthesization, functions with 20 undocumented arguments, creating Byzantine class structures spread over a directory full of modules to implement a concept that _could_ have been done faster and better with a list, ...<br><br>So on a scale of 1 ("wake me up when it's over") to 100 ("OMG!  It's the end of the world!!!"), "but it can be horridly abused" rates about a 2 on my weighting scale.  Do we really think so little of our fellow Pythoneers?  Key point:  absolutely nobody has expressed a fear that they _themself_ will abuse assignment expressions.  It's always some seemingly existential dread that someone else will ;-)<br><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></div><div class="gmail_quote">> I’m not saying it’s not worth it, but it a more significant<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>> complication than simply adding a new feature like augmented<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>> assignment or terniary expressions, where the effect is seen only<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>> where it is used.<br><br>Which is good to keep in mind when using a feature like this.  Python is an imperative language, and side effects are rampant.  Controlling them is important.<br><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>> A key problem with thinking about this is that we can scan existing<br>> code to find places where this would improve the code, and decide if<br>> those use-cases would cause confusion.<br><br>I went through that exercise for the PEP's Appendix A.  I assume you haven't read it.  I found many places where assignment expressions would make for a small improvement, and got surprised by concluding it was really the multitude of tiny, extremely-local improvements that "added up" to the real win overall, not the much rarer cases where assignment expressions really shine (such as in collapsing chains of semantically misleading ever-increasing indentation in long assign/f/else/assign/if/else/assign/if/else ...structures).  I also gave examples of places where, despite being "small and local" changes, using assignment expressions appeared to be a _bad_ idea.<br><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>> But we really can’t anticipate all the places where it might get used<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>> perhaps inappropriately) that would cause confusion. We can hope that</div><div class="gmail_quote">> people won’t tend to do that, but who knows?<br><br>Having spent considerable time on it myself (see just above), I do not assume that other Pythonistas are incapable of reaching sane conclusions too ;-)<br><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>> Example: in a function argument:<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>> result = call_a_func(arg1, arg2, kwarg1=x, kwarg2=x:=2*y)</div><div class="gmail_quote"><br></div><div class="gmail_quote">The PEP already calls that one a SyntaxError.  I can't imagine why a sane programmer would want to do that, but if they really must the PEP _will_ allow it if they parenthesize the assignment expression in this context (so "kwarg2=(x:=2*y)" instead.</div><div class="gmail_quote"><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>> Sure, there are always ways to write bad code, and most people<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>> wouldn’t do that, but someone, somewhere, that thinks shorter code is<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>> better code might well do it. Or something like it.<br><br>Someone will!  No doubt about it.  But what of it?  If someone is programming for their own amusement, why should I care?  If they're working with a group, bad practice should be discouraged by the group's coding standards and enforced by the group's code review process.  For this feature, and all others.</div><div class="gmail_quote"><br>"Consenting adults" is a key Python principle too.  And I believe in it, despite that I wrote tabnanny.py ;-)<br><br></div></div>