4 ms·
In my opinion, the non-hashable version which you moved here from a now-deleted response below is a perfect example of code that is harder to read, harder to ho
by wcarss 9y ago
In my opinion, the non-hashable version which you moved here from a now-deleted response below is a perfect example of code that is harder to read, harder to hold in one's head, and most importantly harder to modify.
The most pythonic version (your set solution) has a bug in that it does not apply to the general case. The second-most pythonic version (your one liner double for-loop slam dunk) is as clever as we can make it, and thereby fails Kernighan's debugging test[1].
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. There is a reason that pattern is nearly universally known, and imo it's that it is a good one.
1 - "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?", https://en.m.wikiquote.org/wiki/Brian_Kernighan https://en.m.wikiquote.org/wiki/Brian_Kernighan
- crdoconnor 9y ago>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.