3 ms·
This can replace that, sure, but I think it's more meant to be replacing things like: foo = check_foo() while foo: do_foo() foo = check
by misnome 8y ago
This can replace that, sure, but I think it's more meant to be replacing things like:
foo = check_foo()
while foo:
do_foo()
foo = check_foo()
With
while foo := check_foo():
do_foo()
which is a case that hasn't had an elegant solution in the past. Another, if example, where you want to call a function based on the result of a check, but don't want to make that check more than once:
foo = check_foo()
if foo:
do_foo(foo)
else:
other_foo = check_other_foo()
if other_foo:
do_other_foo(other_foo)
else:
# Continue
with
if foo := check_foo():
do_foo(foo)
elif other_foo := check_other_foo()
do_other_foo(other_foo)
elif .....:
Yes, all of this has been possible and there are other ways to do it, but this expresses the problem very concisely and has less nesting at the cost of a slightly more complicated syntax. I find these rewritten examples easier to parse than the originals.
Pulling things out of comprehensions is pretty neat too.
Other than a few cases (e.g. these) I don't see this suited or intended for extremely wide usage, but no worse than any other complex idiom that people can overuse.
- mehrdadn 8y agoI agree the check_foo() duplication was bad, but was this workaround really so bad? while 1: foo = check_foo() if not foo: break do_foo(foo) Its only downside was taking 2 extra lines, not actual understandability.
- int_19h 8y agoIt makes the intent of the loop less clear, since now the condition is tucked away somewhere in the middle of the body, even though it's really a precondition.
- mehrdadn 8y agoI'm torn on this, because although it's easy to say that for a toy example like this, when these "preconditions" evolve over time, you get things like: while 1: now = time() if now > prev_time + UPDATE_TIME: report_progress() foo = check_foo() if not foo: break if foo < 0: print_error(); break do_foo(foo) prev_time = now Now, was it really dictating a precondition? Or was it actually dictating a postcondition? Or both or neither? Would you really want these responses to dictate the locations of the condition in the syntax? Because it seems to me that forcing yourself to put these conditions in the loop condition just makes the code extremely ugly and difficult to evolve (requiring you to duplicate code or have very convoluted expressions with assignments).
- int_19h 8y agoThe biggest thing this gives, IMO, is the ability to filter on a computed value in a comprehension, and then use that computed value as the result. It's something that's needed quite often if you use comprehensions heavily, and there's no good workaround for it currently (you can use a nested "for" over a 1-element tuple to create a named binding, but it's much uglier, has more overhead, and readability is basically non-existent).
- misnome 8y agoI agree that's a good feature, but feel it's hard to make comprehension examples that look elegant enough to avoid obvious sniping about how the feature makes it "unreadable".