Comprehension with two variables - explanation needed

[Roy Smith]

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 <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.
> 
> Skip
> 


--
Roy Smith
roy at panix.com