<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>