Great article. I liked the many options to solve the problem. I feel the dictionary comorehension is too much of a cool trick that is hard to understand. The scaling version with the kwargs is beautiful.
Like some other articles, I'm a bit disappointed with using time libraries to measure performance of code because the running time is biased and tied up to the machine performance. Big O notation would be more suitable.
Big O is great, but you'd need to know how these solutions work internally to measure it. That's why we use empirical measurements like the timeit library to get a rough idea of each solution's performance.
Personally, I prefer correctness and readability over performance anyway. If something becomes a major bottleneck, then I would start looking into more performant solutions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article. I liked the many options to solve the problem. I feel the dictionary comorehension is too much of a cool trick that is hard to understand. The scaling version with the kwargs is beautiful.
Like some other articles, I'm a bit disappointed with using time libraries to measure performance of code because the running time is biased and tied up to the machine performance. Big O notation would be more suitable.
Big O is great, but you'd need to know how these solutions work internally to measure it. That's why we use empirical measurements like the
timeitlibrary to get a rough idea of each solution's performance.Personally, I prefer correctness and readability over performance anyway. If something becomes a major bottleneck, then I would start looking into more performant solutions.