5 ms·

I agree that I would have preferred "as"...but that said I am struggling to think of a reason this is needed. while (bytes := io.get(x)): Would currently

I agree that I would have preferred "as"...but that said I am struggling to think of a reason this is needed. while (bytes := io.get(x)): Would currently be written: bytes = io.get(x) while bytes: And likewise: [bar(x) for z in stuff if (x := foo(z))] is equivalently: [bar(foo(z)) for z in stuff if foo(z)] Perhaps this is just my personal opinion but I don't really think the ":=" (or "as" for that matter) adds much in the way of clarity or functionality. I guess at the end of the day I am neutral about this addition...but if there isn't a clear upside I usually think it's better to have less rather than add more.

Dunnorandom 8y ago
The first example would actually be equivalent to something like while True: bytes = io.get(x) if not bytes: break ... which I think is objectively less readable. 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] instead - which I personally don't mind, but it's arguably not as clear as having the in-line assignment expression.
- amorousf00p 8y ago
  Quibbles and bits. Python is the only language where I write logic and then massage data structures and outputs + design 'cooler' ways to create these for an extra hour -- a week after it is in production.
- gshulegaard 8y ago
  I wasn't really considering the repeated genearation on `io` in the `while` example...so now I see a clear benefit to the syntax. I guess I would say I am now lukewarm about adding this additional operator. It makes at least one logical structure nicer...but I wouldn't have been heartbroken if it wasn't accepted though.
- roman_g 8y ago
  And if foo(z) is consuming a generator somehow (e.g. it's next(g)) then you can't call it twice without side effects.
mockingbirdy 8y ago
I think I'll use this exactly to avoid duplication in while loops: bytes = next() while bytes: # do something ... bytes = next() It's possible to use while True and break, but that isn't very elegant.
wizpig64 8y ago
This second example: [bar(x) for z in stuff if (x := foo(z))] is not equivalent to: [bar(foo(z)) for z in stuff if foo(z)] because here, foo(z) will be called twice. If foo is an expensive operation or performs some other magic in the background that you don't want to call a second time, := lets you express this behavior without having to break your expression out into a huge for-if-append code block: output = [] for z in stuff: x = foo(z) if x: output.append(bar(x)) Of course, the above verbose language might end up being a better code in the end, because mashing together a bunch of terse code is often not very readable. But in real life, transforming a comprehension into a loop is just a bunch of work that gets in the way of me trying to complete a task. 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.
- bjd2385 8y ago
  Honestly, after seeing the first list comprehension, I can tell that this feature will probably increase code readability for me, but it's definitely going to take more thought to understand where values are coming from.
- gshulegaard 8y ago
  I'm aware `foo(z)` gets called twice, but I wouldn't choose to break it into the `for` loop you mention: [bar(x) for x in map(foo, stuff) if x] I was just trying to be as close to the original as possible. 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.
- deleted 8y ago
  [deleted]
LyndsySimon 8y ago
I think I would probably write [bar(foo(z)) for z in stuff if foo(z)] as [bar(y) for y in (z for z in stuff if foo(z))] or even as [bar(y) for y in filter(foo, stuff)] ... although, I get that `map`, `apply`, and `filter` aren't generally considered pythonic. 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.
- eswoo 8y ago
  It needs to be [bar(foo(y)) for y in (z for z in stuff if foo(z))] (etc.) though, since `bar` takes as input the output of `foo`. This leads to the objectionable duplicate calls to `foo`, hence the new assignment expressions. I like Dunnorandom's [bar(x) for x in map(foo, stuff) if x] best for a correct result using existing syntax, or [bar(x) for y in (foo(x) for x in stuff) if y] if you don't like `map`.

Dunnorandom 8y ago

The first example would actually be equivalent to something like while True: bytes = io.get(x) if not bytes: break ... which I think is objectively less readable. 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] instead - which I personally don't mind, but it's arguably not as clear as having the in-line assignment expression.

amorousf00p 8y ago
Quibbles and bits. Python is the only language where I write logic and then massage data structures and outputs + design 'cooler' ways to create these for an extra hour -- a week after it is in production.
gshulegaard 8y ago
I wasn't really considering the repeated genearation on `io` in the `while` example...so now I see a clear benefit to the syntax. I guess I would say I am now lukewarm about adding this additional operator. It makes at least one logical structure nicer...but I wouldn't have been heartbroken if it wasn't accepted though.
roman_g 8y ago
And if foo(z) is consuming a generator somehow (e.g. it's next(g)) then you can't call it twice without side effects.

mockingbirdy 8y ago

I think I'll use this exactly to avoid duplication in while loops: bytes = next() while bytes: # do something ... bytes = next() It's possible to use while True and break, but that isn't very elegant.

wizpig64 8y ago

This second example: [bar(x) for z in stuff if (x := foo(z))] is not equivalent to: [bar(foo(z)) for z in stuff if foo(z)] because here, foo(z) will be called twice. If foo is an expensive operation or performs some other magic in the background that you don't want to call a second time, := lets you express this behavior without having to break your expression out into a huge for-if-append code block: output = [] for z in stuff: x = foo(z) if x: output.append(bar(x)) Of course, the above verbose language might end up being a better code in the end, because mashing together a bunch of terse code is often not very readable. But in real life, transforming a comprehension into a loop is just a bunch of work that gets in the way of me trying to complete a task. 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.

bjd2385 8y ago
Honestly, after seeing the first list comprehension, I can tell that this feature will probably increase code readability for me, but it's definitely going to take more thought to understand where values are coming from.
gshulegaard 8y ago
I'm aware `foo(z)` gets called twice, but I wouldn't choose to break it into the `for` loop you mention: [bar(x) for x in map(foo, stuff) if x] I was just trying to be as close to the original as possible. 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.
deleted 8y ago
[deleted]

LyndsySimon 8y ago

I think I would probably write [bar(foo(z)) for z in stuff if foo(z)] as [bar(y) for y in (z for z in stuff if foo(z))] or even as [bar(y) for y in filter(foo, stuff)] ... although, I get that `map`, `apply`, and `filter` aren't generally considered pythonic. 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.

eswoo 8y ago
It needs to be [bar(foo(y)) for y in (z for z in stuff if foo(z))] (etc.) though, since `bar` takes as input the output of `foo`. This leads to the objectionable duplicate calls to `foo`, hence the new assignment expressions. I like Dunnorandom's [bar(x) for x in map(foo, stuff) if x] best for a correct result using existing syntax, or [bar(x) for y in (foo(x) for x in stuff) if y] if you don't like `map`.