>is a perfect example of code that is harder to read, harder to hold in one's head, and most importantly harder to modify. It's both shorter and less expressiv

>is a perfect example of code that is harder to read, harder to hold in one's head, and most importantly harder to modify. It's both shorter and less expressive than the equivalent for loop. If you find it harder to read that says more about your familiarity with list and generator comprehensions. >The most pythonic version (your set solution) has a bug Not in lieu of a hard requirement for counting non-hashable items, it isn't. It's faster as well as simpler: O(n) instead of O(n2). Unless you're counting lists of lists or something it makes no sense not to use it. >I feel that one for loop inside another is fine. Everyone in every language can see it and know instantly what the run-time characteristics likely are, and what at each point it is doing. What's most important: if it ever seems to be broken, I can drop a debugger or a logger (maybe with a condition!) in at any point, with ease Writing your code in a more verbose and complex way in order to satisfy your desire to put a debugger in is by far and away not the most important aspect of clean coding.