[Python-Dev] Call for prudence about PEP-572 (original) (raw)
Tim Peters tim.peters at gmail.com
Sun Jul 8 00:27:31 EDT 2018
- Previous message (by thread): [Python-Dev] Call for prudence about PEP-572
- Next message (by thread): [Python-Dev] Call for prudence about PEP-572
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Tim] > When I was staring at my code, I never mentioned the very first > plausible use I bumped into (in code I was actively working on at the time): > > while not probableprime(p := randrange(lo, hi)): > pass > # and now
p
is likely a random prime in range
{Terry Reedy]
As long as lo excludes 0: while p := randrange(lo, hi) and not probableprime(p): continue I can see how someone might prefer this stylistically, but it is buggy. If this is contained in a function (very likely) and lo could be <= 0, because it is either passed in or calculated, 0 could be passed on a likely prime!
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.
I won't even write it this way, which keeps "the trick" but eliminates the hidden data assumption:
while [p := randrange(lo, hi)] and not probable_prime(p):
A singleton list is always truthy, so at least now it makes no assumptions
about the value bound to p
.
I could be paid to write it this way, but most employers couldn't afford to pay enough to do it twice ;-) :
while [(p := randrange(lo, hi)), not probable_prime(p)][-1]:
That always works and doesn't rely on "a trick", but is ugly, obscure, and inefficient.
I never mentioned it because I expected it would annoy people on 3(!) > counts: > > - assigning in a function call
This is a style preference that people can and will disagree on. In any case, I think correctness trumps beauty, just as it trumps speed.
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.
> - reducing the loop body to
pass
I fixed that ;-). 'continue' better expresses the 'try again' part of English versions, such as "While the trial value is not acceptable, try again."
Thanks! Now that you mention it (it had not occurred to me), I like
continue
much better than pass
here too.
- using the binding long after the loop ended
The same is true for the current 4-line loop and a half.
while True: p = randrange(lo, hi) if probableprime(p): break # p used somewhere else
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.
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.
Indeed, for those reasons it wasn't "an obvious" win to me - or an > obvious loss. So I just moved on. > > However, after staring at hundreds of other cases, it does strike me as > "a small win" today - my brain cells have rewired to recognize more ":=" > patterns at a glance. > > Whether that's a good thing or not I don't know, but it is a real thing ;-)
I must admit that I too am already more comfortable with := now than I was originally.
The stories about its uncanny ability to destroy entire projects with a single use may have been exaggerated ;-)
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.
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.
Next project: rehabilitate the much-maligned GOTO statement ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180707/8092f381/attachment.html>
- Previous message (by thread): [Python-Dev] Call for prudence about PEP-572
- Next message (by thread): [Python-Dev] Call for prudence about PEP-572
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]