On Jan 23, 4:37 am, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Tue, 22 Jan 2008 23:33:00 -0800, George Sakkis wrote:
> > As I mentioned already, I consider the seeking of the most efficient
> > solution a legitimate question, regardless of whether a "dumb" solution
> > is fast enough for an application. Call it a "don't be sloppy" principle
> > if you wish.
>
> Sure, by why do you limit "efficient" and "don't be sloppy" to mean
> "write the fastest executing code you can, regardless of every other
> trade-off"?
I explicitly didn't limit sloppiness to inefficiency and mentioned
it's a tradeoff:
"... all else being equal or at least comparable (elegance,
conciseness, readability, etc.). Of course it's a tradeoff;
spending a week to save a few milliseconds on average is usually a
waste for most applications, but being a lazy keyboard banger writing
the first thing that pops into mind is not that good either."
> But... do you write list.__len__() instead of len(list) to save a few
> nanoseconds?
No, of course not, it's not worth it, but that doesn't mean that being
curious about what's faster and using timeit to find out is totally
worthless.
Another example: avoiding attribute lookups within a loop. I rarely
write
bar = foo.bar
for i in big_list: bar(i)
but it's valuable to know that it can make a difference when I really
need it. Always writing the first thing that "just works" prevents one
from even considering that there might be faster (or more elegant,
more general, etc.) alternatives.
George
--
http://mail.python.org/mailman/listinfo/python-list
