21–28 of 28 posts
I think this has been possible in PHP since forever and that community treats it as bad practise. Let's not repeat PHP's mistake 20 years later...
This has been possible in functional and "expression" languages since forever, and it's considered a very good practice.
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 unpython…
Well, = and == in C are two different operators as well.
The problem is more allowing non-boolean comparisons
we have "{NAME : EXPR}" for dict
just do "(NAME : EXPR)" with parenthesis
within its scope, list comp can be
results = [b for a in data if (b: f(a))]
perhaps even with c++ range based for the win
results = [win for (the: data) if (win: f(the))]
I'm not particularly sold on this proposal, but the examples in the OP seem like poor counterarguments; there are a lot of ways to write incomprehensible python. (Nested list comprehensions anyone?) And it's already possible to write one-liners that do too many things; I'm not convinced that this proposal would make that worse. Best to consider how this feature would actually be used, and make a judgement as to wheth…
Looks like a major improvement in readability to me...
As a long-time Python user, this is one of the worst proposals I've seen. Yes, it has a potential for being useful. But its usefulness, unlike context managers and async, is very limited, implied a substantial cognitive overhead by introducing a new operator, and has a very significant potential for abuse. One of the nice things about Python is that it is highly succing while disallowing the sort of expressions that…
I have been noticing this long before. For me it was with the pep that dealt with automatic string interpolation, i think it was 498..
I think this has been possible in PHP since forever and that community treats it as bad practise. Let's not repeat PHP's mistake 20 years later...
Perhaps the 20-year mistake of PHP is treating it as a bad practice? This has been possible in functional and "expression" languages since forever, and it's considered a very good practice.
Really? Can you show an example?
I think this has been possible in PHP since forever and that community treats it as bad practise. Let's not repeat PHP's mistake 20 years later...
I'm not particularly sold on this proposal, but the examples in the OP seem like poor counterarguments; there are a lot of ways to write incomprehensible python. (Nested list comprehensions anyone?) And it's already possible to write one-liners that do too many things; I'm not convinced that this proposal would make that worse. Best to consider how this feature would actually be used, and make a judgement as to wheth…
Looks like a major improvement in readability to me...
Two assignment operators instead of one doesn't seem that hard to wrap my head around, but Python is used widely in education as well, and we should also pay heed to the lessons of C++ - the road to incomprehensible languages is paved with good-intentioned syntax.