Hi Stephen, we can create a new empty list and iterate on first list which has non-unique values and check if an item is not in second list - if so append the item to second list. This approach also seems to maintain the order of the first list and creates unique values.
This was actually my knee-jerk thought too. But I think Stephen is most probably right in terms of performance. And the casting (or using dict.fromkeys()) is certainly more concise within the code. As an old school Perl developer this is really a case of “there’s more than one way to do it” I think and ultimately what matters most is your comfort level and consistency. By the latter, in my opinion, I mean that if you do certain things a certain way then it should be the way you ALWAYS do that thing. Very little is more aggravating than taking over someone else’s code and see their meandering (or evolution of learning?) as you step through it.
And indeed, the one line from the Zen of Python that I think is not true (it may have been in the past, but definitely not today) is that there should only be one obvious way of doing things. There’s always more than one!
This was excellent thank you. I have often used sets to dedupe, but never used a dictionary to.
Great tip!
Sets are the ideal route if you don’t care about order (and all elements are hashable)
Hi Stephen, we can create a new empty list and iterate on first list which has non-unique values and check if an item is not in second list - if so append the item to second list. This approach also seems to maintain the order of the first list and creates unique values.
Indeed, that works too. But going through dict.fromkeys() will be faster (I believe).
This was actually my knee-jerk thought too. But I think Stephen is most probably right in terms of performance. And the casting (or using dict.fromkeys()) is certainly more concise within the code. As an old school Perl developer this is really a case of “there’s more than one way to do it” I think and ultimately what matters most is your comfort level and consistency. By the latter, in my opinion, I mean that if you do certain things a certain way then it should be the way you ALWAYS do that thing. Very little is more aggravating than taking over someone else’s code and see their meandering (or evolution of learning?) as you step through it.
And indeed, the one line from the Zen of Python that I think is not true (it may have been in the past, but definitely not today) is that there should only be one obvious way of doing things. There’s always more than one!