5 ms·

The only thing I disagree with is "use nested comprehensions" thing. In my mind: x = [letter for word in words for letter in word] is inside-out o

The only thing I disagree with is "use nested comprehensions" thing. In my mind: x = [letter for word in words for letter in word] is inside-out or backwards or backwards. I want the nested for being the less specific case: x = [letter for letter in word for word in words] makes more sense in my mind. (It's also my first answer to the "what're some warts in the your language of choice).

jules 12y ago
Even clearer: x = [for word in words: for letter in word: letter] This also has the advantage of being readable left to right without encountering any unbound identifiers like all other constructs in Python.
- hueving 12y ago
  As someone who spends a significant amount of time in python that is much harder to follow. There is an expectation for order in list comprehensions and what you wrote completely violates it.
njharman 12y ago
I'm in the camp that if your list comp needs more than one for clause, it's complicated enough to be broken out into actual for loop.
- jevgeni 12y ago
  Everybody, listen to this person!
  - jules 12y ago
    Then it turns into this: x = [] for word in words: for letter in word: x.append(letter) Which in addition to being far more verbose and less readable, is also less efficient.
    - sophacles 12y ago
      I'll tell you what I tell my team: it's barely more verbose, and the readability is up for extremely serious debate (I mean, everyone understands nested for loops, but the nested list comprehension thing is wierd... why is something that appears way way before the innermost "for" the same as something in that for loop's declaration?) It may also be less efficient. When I'm shown numbers that the difference between the comprehension and the for loops are (in each specfic instance, or in aggregate for the program in question) is above statistical noise AND it's a significant factor in overall runtime (I won't ever worry about a millisecond when the runtime is 1s), then I'll gladly say: put them in. Until then, just use the loops. Use of really strange language features that are surprising, not exactly idiomatic (this argument is common for this case) and not shown to be of actual benefit, are detrimental in a polyglot environment.
      - jules 12y ago
        When I see a list comprehension I can see with a single glance what it's doing. Not so with the 4 line for loop. Comprehensions aren't a strange language feature in Python either...it's one of the central features of Python. Don't use something until it's proven to yield a great benefit is a very conservative approach. That may be appropriate in some cases, but I'm very glad that I am not in such a team since that would be incredibly frustrating. I much prefer an approach where you go with the choice that's most likely the better one, even if it's not 100% proven better or not a big difference.
        sophacles 12y ago
        I'm talking strictly about multi "for" comprehensions. They just are too confusing to me and most of the people I've worked with ever. But we also use lots (most) python features fully, just that one has been the source of dozens of bugs in this one codebase, not to mention others I've worked on with other people. It is a shitty non-intuitive syntax. Nested for loops, flatten(), various itertools functions and chained generator expressions all suffice, and I have yet to see them provide measurable slowdown to actual code compared to good algorithms and decent factoring. Like I said, I'll even use multi-for comprehensions if there is a measurable difference over nested for-loops. Also, I think you are intentionally misrepresenting what I said - when I said don't use "weird stuff" I explicitly excluded idiomatic language things. That includes (for python) single for comprehensions. The multi-for comprehension is something I rarely come across in the wild despite it's long time existence in python - it's a weird one.

jules 12y ago

Even clearer: x = [for word in words: for letter in word: letter] This also has the advantage of being readable left to right without encountering any unbound identifiers like all other constructs in Python.

hueving 12y ago
As someone who spends a significant amount of time in python that is much harder to follow. There is an expectation for order in list comprehensions and what you wrote completely violates it.

njharman 12y ago

I'm in the camp that if your list comp needs more than one for clause, it's complicated enough to be broken out into actual for loop.

jevgeni 12y ago
Everybody, listen to this person!
- jules 12y ago
  Then it turns into this: x = [] for word in words: for letter in word: x.append(letter) Which in addition to being far more verbose and less readable, is also less efficient.
  - sophacles 12y ago
    I'll tell you what I tell my team: it's barely more verbose, and the readability is up for extremely serious debate (I mean, everyone understands nested for loops, but the nested list comprehension thing is wierd... why is something that appears way way before the innermost "for" the same as something in that for loop's declaration?) It may also be less efficient. When I'm shown numbers that the difference between the comprehension and the for loops are (in each specfic instance, or in aggregate for the program in question) is above statistical noise AND it's a significant factor in overall runtime (I won't ever worry about a millisecond when the runtime is 1s), then I'll gladly say: put them in. Until then, just use the loops. Use of really strange language features that are surprising, not exactly idiomatic (this argument is common for this case) and not shown to be of actual benefit, are detrimental in a polyglot environment.
    - jules 12y ago
      When I see a list comprehension I can see with a single glance what it's doing. Not so with the 4 line for loop. Comprehensions aren't a strange language feature in Python either...it's one of the central features of Python. Don't use something until it's proven to yield a great benefit is a very conservative approach. That may be appropriate in some cases, but I'm very glad that I am not in such a team since that would be incredibly frustrating. I much prefer an approach where you go with the choice that's most likely the better one, even if it's not 100% proven better or not a big difference.
      - sophacles 12y ago
        I'm talking strictly about multi "for" comprehensions. They just are too confusing to me and most of the people I've worked with ever. But we also use lots (most) python features fully, just that one has been the source of dozens of bugs in this one codebase, not to mention others I've worked on with other people. It is a shitty non-intuitive syntax. Nested for loops, flatten(), various itertools functions and chained generator expressions all suffice, and I have yet to see them provide measurable slowdown to actual code compared to good algorithms and decent factoring. Like I said, I'll even use multi-for comprehensions if there is a measurable difference over nested for-loops. Also, I think you are intentionally misrepresenting what I said - when I said don't use "weird stuff" I explicitly excluded idiomatic language things. That includes (for python) single for comprehensions. The multi-for comprehension is something I rarely come across in the wild despite it's long time existence in python - it's a weird one.