3 ms·
At least it introduces a new operator, to avoid the classic C mistake of typing "=" when you meant "==", and various ugly workarounds like Yoda conditions. Thi
by guitarbill 9y ago
At least it introduces a new operator, to avoid the classic C mistake of typing "=" when you meant "==", and various ugly workarounds like Yoda conditions.
This would be a huge boon for many list/dict/set comprehensions, as currently there's no way to filter on the result of a function call in the same comprehension (map + filter in one):
results = [b for b in input_data if (b := f(a))]
I think it's slightly unpythonic as it has the potential to be abused and make debugging harder (as noted in the post/email), but otherwise I can't think of a reason not to do it.
- Latty 9y agoThat's a better use case, but this just seems like something that's adding complexity to the language for little gain. Writing a generator to do the more complex thing is probably a much better (and more readable) alternative, if a list comprehension isn't cutting it.
- repsilat 9y ago> `results = [b for b in input_data...` Did you mean `[b for a in...`?
- abecedarius 9y agoAssuming so, there’s [result for a in input_data for result in [f(a)] if result] if you’ve just gotta make it a comprehension.
- ris 9y agoThis case could also be addressed by something more like PEP 3150 without the nasty potential for leaking the scope of an assignment beyond that statement in a non-obvious way. https://www.python.org/dev/peps/pep-3150/ https://www.python.org/dev/peps/pep-3150/
- kbob 9y agoIt's an open question whether that's more readable than the already legal results = [b for b in (f(a) for a in input_data) if b]
- coldtea 9y ago>At least it introduces a new operator, to avoid the classic C mistake of typing "=" when you meant "==", and various ugly workarounds like Yoda conditions. Well, = and == in C are two different operators as well. The problem is more allowing non-boolean comparisons