but for a website handling many requests this can add up very quickly
This code is in a config reader, true? I'd expect it to run only on startup or reload, not on every request. I see no reason to try optimizing it, especially at the expense of clarity.
Also, if someone cares about maximum runtime performance, they're not using Bottle, they're using (e.g.) Falcon. Bottle's beauty is in its ease of use and its code simplicity, not in its blazing speed.
if you show me bottleneck
Yes, I agree with you 100%. The right way to optimize is to profile first, and then make targeted changes.
Reasons why it's more important for code to be clear than to be fast:
It almost always doesn't matter in actual production (unless you've profiled and know where to optimize).
Over its lifetime, code costs more to read than to write, so it should be optimized for ease of reading. (And, arguably, a list is easier to read less error prone than a tuple, because (a) [...] is less ambiguous in Python than (...), and (b) tuples of size 1 are prone to errors.
Optimizations are frequently platform specific. Even if you ran dis with every compiles and every version of Python, you wouldn't be future-proof. (One example that comes to mind is string concatenation with +, whose performance varies greatly depending on compiler and version.)
A set is arguably a more appropriate data structure to use here than either a list or a tuple, since sets are designed precisely for membership queries, which is all this code does. I'm not proposing that we use a set--because I think a list is clearer to the reader.
(I know you probably know all of that already, since you're an experienced engineer, but I want to state it here for the benefit of future contributors.)
I came to this PR with an open mind, but I'm becoming convinced that this was an unnecessary change, albeit a small one; possibly even very slightly detrimental.
Finally, I want to add: Overall, I very highly appreciate the efforts you're putting into this project, which is near and dear to my heart. Thank you for all your recent improvements. I'd just like to challenge open source contributors in general to step back and think at a higher level about the changes they propose. My goal (like yours) is to have the best possible code out there. Thanks again!
This code is in a config reader, true? I'd expect it to run only on startup or reload, not on every request. I see no reason to try optimizing it, especially at the expense of clarity.
Also, if someone cares about maximum runtime performance, they're not using Bottle, they're using (e.g.) Falcon. Bottle's beauty is in its ease of use and its code simplicity, not in its blazing speed.
Yes, I agree with you 100%. The right way to optimize is to profile first, and then make targeted changes.
Reasons why it's more important for code to be clear than to be fast:
[...]is less ambiguous in Python than(...), and (b) tuples of size 1 are prone to errors.diswith every compiles and every version of Python, you wouldn't be future-proof. (One example that comes to mind is string concatenation with+, whose performance varies greatly depending on compiler and version.)setis arguably a more appropriate data structure to use here than either a list or a tuple, since sets are designed precisely for membership queries, which is all this code does. I'm not proposing that we use a set--because I think a list is clearer to the reader.(I know you probably know all of that already, since you're an experienced engineer, but I want to state it here for the benefit of future contributors.)
I came to this PR with an open mind, but I'm becoming convinced that this was an unnecessary change, albeit a small one; possibly even very slightly detrimental.
Finally, I want to add: Overall, I very highly appreciate the efforts you're putting into this project, which is near and dear to my heart. Thank you for all your recent improvements. I'd just like to challenge open source contributors in general to step back and think at a higher level about the changes they propose. My goal (like yours) is to have the best possible code out there. Thanks again!