We seem to be somewhat more liberal about nested comprehensions here, but I can't say I'm proud of that :-)
906 Python source files, 109k lines. $ find . -name '*.py' | xargs grep '\[.* for .*\]' | wc -l 729 $ find . -name '*.py' | xargs grep '\[.* for .* for .*\]' | wc -l 46 Without naming names, a quick look into our nested comprehensions with "hg blame" shows a very strong correlation between "people who wrote many nested comprehensions" and "people who's code I find difficult to read in general". I see one of these that has my name on the commit: report = [keys] + [[line[key] for key in keys] for line in results] but I'm glad to report that this was merely some third-party code that I imported into our repo. Whew, that was close! On Nov 23, 2014, at 11:45 AM, Skip Montanaro wrote: > On Sun, Nov 23, 2014 at 9:57 AM, Roy Smith <r...@panix.com> wrote: >> >> If it was complicated enough that you needed to loopify it to >> understand what it's doing, have pity on the next person who has to >> maintain your code and leave it as a loop > > Well, sure. I was mostly trying to give Ivan a path out of the weeds. > Poking through the code I'm involved with at work, using a crude > measuring stick (a couple regular expressions) I found over 1400 one > line list comprehensions, those which matched this regular expression: > > \[.* for .*\] > > OTOH, I only found 14 with two "for" keywords: > > \[.* for .* for .*\] > > (There may well have been more nested loop list comprehensions, simply > because it's hard to cram the full listcomp into 80 columns, my > self-imposed column limit.) > > In my experience, list comprehensions rapidly get unwieldy once you > get to nesting them. I generally unravel such items into a nested set > of for loops. > > Skip > -- Roy Smith r...@panix.com -- https://mail.python.org/mailman/listinfo/python-list
