while (bytes := io.get(x)):
bytes = io.get(x)
while bytes:
[bar(x) for z in stuff if (x := foo(z))]
[bar(foo(z)) for z in stuff if foo(z)]
while True:
bytes = io.get(x)
if not bytes:
break
...
In the second example, you have an extra call to foo for every element of stuff. If foo(z) is expensive, you'd probably want to write this as
[bar(x) for x in map(foo, stuff) if x]
bytes = next()
while bytes:
# do something ...
bytes = next()
[bar(x) for z in stuff if (x := foo(z))]
[bar(foo(z)) for z in stuff if foo(z)]
output = []
for z in stuff:
x = foo(z)
if x:
output.append(bar(x))
When I'm developing out an idea and just want to see if the code works and passes my tests, I would rather have the option to insert behavior swiftly without having to reformat an entire block of code. Then when reviewing my code or deciding whether to make it reusable for something else, I can go back and clean things up.
[bar(x) for x in map(foo, stuff) if x]
I do find it odd you call out the calling of `foo` twice as a performance drain but then use the chief example of:
> When I'm developing out an idea and just want to see if the code works and passes my tests, I would rather have the option to insert behavior swiftly without having to reformat an entire block of code.
Tests are not something I (personally) consider to be performance sensitive. But like I said I am sort of neutral on this change. I don't really see a massive benefit to it, so I would personally air on the side of "don't add" but I'm not mad it's being added. It's a "meh" for me.
[bar(foo(z)) for z in stuff if foo(z)]
[bar(y) for y in (z for z in stuff if foo(z))]
[bar(y) for y in filter(foo, stuff)]
Overall, I think I agree with you - the new syntax in PEP572 might be handy, but it isn't necessary and I would say that the cognitive overhead of encountering yet another syntax doesn't justify the benefit, much less the technical overhead for the interpreter.
[bar(foo(y)) for y in (z for z in stuff if foo(z))]
I like Dunnorandom's
[bar(x) for x in map(foo, stuff) if x]
[bar(x) for y in (foo(x) for x in stuff) if y]
What do you mean by "intension"? I haven't seen this referred to in python and googling isn't turning out anything useful (also spelling it as "intention").
The worst for me is OOP. In french it's POO, which, for obvious reasons, does not inspire confidence in an english reader.
"comprehension list" in french can be translated to "liste en intension"
From my reading of the PEP, assignment expressions specifically prohibit type annotations.
Someone showed me this in a previous thread:
>> [bar(foo_z) for z in stuff for foo_z in [foo(z)] if foo_z]
Not a common idiom, though. Neither snippet is perfectly clear to me, but yours is closer.
But experience tells that the slow and gradual pace of the language evolution combined with the readability culture of the community don't lead that way.
While we will see code review breaking materials in the wild, I believe that the syntax will mostly be used sparingly, as other features, when the specific needs arise for it.
After all, it's been, as usual, designed with this in mind: "=" and ":=" are mutually exclusive. You don't use them in the same context.
The grammar makes sure of it most of the time, and for the rare ambiguities like:
vs The parenthesis will discourage pointless usage.My bet is that we will see essentially rare but useful and expressive use cases in productions, which is exactly the goal.
Given the month of debates around this, I think it's a fine compromise.
Like many, I would have preferred the use of the "as" keyword instead of a new operator, since it's already used to bind things to names in imports, context managers and try/except.
However, the new syntax has 2 advantages: it reads the same way than the original operator, and it supports type hints out of the box.