<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Tim]<br>
> When I was staring at my code, I never mentioned the very first <br>
> plausible use I bumped into (in code I was actively working on at the time):<br>
> <br>
> while not probable_prime(p := randrange(lo, hi)):<br>
> pass<br>
> # and now `p` is likely a random prime in range<br>
<div style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"></div></blockquote><div> </div>{Terry Reedy] <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As long as lo excludes 0:<br>
<br>
while p := randrange(lo, hi) and not probable_prime(p):<br>
continue<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can see how someone might prefer this stylistically, but it is buggy. <br>
If this is contained in a function (very likely) and lo could be <= 0, <br>
because it is either passed in or calculated, 0 could be passed on a <br>
likely prime!<br></blockquote><div><br>I never write code that uses "and" relying on that context-specific data constraints "guarantee" the LHS is always true. That combines a delicate precondition with "a trick". Dreadful.<br><br>I won't even write it this way, which keeps "the trick" but eliminates the hidden data assumption:<br><br>
<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">while [p := randrange(lo, hi)] and not probable_prime(p):</span></div><div><br></div><div>A singleton list is always truthy, so at least now it makes no assumptions about the value bound to `p`.<br><br>I could be paid to write it this way, but most employers couldn't afford to pay enough to do it twice ;-) :<br><br>
<div style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">while [(p := randrange(lo, hi)), not probable_prime(p)][-1]:</span></div><br class="gmail-Apple-interchange-newline">
That always works and doesn't rely on "a trick", but is ugly, obscure, and inefficient.<br><br style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I never mentioned it because I expected it would annoy people on 3(!) <br>
> counts:<br>
> <br>
> - assigning in a function call<br>
<br>
This is a style preference that people can and will disagree on. In any <br>
case, I think correctness trumps beauty, just as it trumps speed.<br></blockquote><div><br></div><div>All else being equal (and, yup, correctness is more equal than the others), I like to push assignments "to the left" as much as possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - reducing the loop body to `pass`<br>
<br>
I fixed that ;-). 'continue' better expresses the 'try again' part of <br>
English versions, such as "While the trial value is not acceptable, try <br>
again."<br></blockquote><div><br>Thanks! Now that you mention it (it had not occurred to me), I like `continue` much better than `pass` here too.<br><br><br>> - using the binding long after the loop ended<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The same is true for the current 4-line loop and a half.<br>
<br>
while True:<br>
p = randrange(lo, hi)<br>
if probable_prime(p):<br>
break # p used somewhere else<br></blockquote><div><br></div><div>Sure. But this PEP _started_ with a fancier model wherein the language would magically limit the scope of assignment targets in these block-opening tests. That was eventually removed, but I'm sure we'll see "style guides" demanding that it "should" never be used unless the target is in fact never referenced (at least not before re-binding) after the associated block ends.<br><br>It's been mildly surprising to me to see how often that _is_ the case in real code. But, as in the example above, I won't be following such a rule rigidly.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Indeed, for those reasons it wasn't "an obvious" win to me - or an <br>
> obvious loss. So I just moved on.<br>
> <br>
> However, after staring at hundreds of other cases, it does strike me as <br>
> "a small win" today - my brain cells have rewired to recognize more ":=" <br>
> patterns at a glance.<br>
> <br>
> Whether that's a good thing or not I don't know, but it is a real thing ;-)<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I must admit that I too am already more comfortable with := now than I <br>
was originally.</blockquote><div><br>The stories about its uncanny ability to destroy entire projects with a single use may have been exaggerated ;-)<br><br>But, ya, I've tried playing with it much more than most so far, and my bar for "obvious little win" has lowered. Not much, though, and it seems to have bottomed out with that example.<br><br>So, in the end, I expect I'll use it as sparingly - and gratefully! - as in all the other languages I've used with assignment expressions.<br><br>Next project: rehabilitate the much-maligned GOTO statement ;-)<br><br></div></div></div>