Comprehension with two variables - explanation needed
roy at panix.com
Sun Nov 23 18:08:19 CET 2014
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
$ find . -name '*.py' | xargs grep '\[.* for .* for .*\]' | wc -l
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 <roy at 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.
roy at panix.com
More information about the Python-list