pairs from a list

George Sakkis george.sakkis at gmail.com
Wed Jan 23 13:39:25 EST 2008


On Jan 23, 4:37 am, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> 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



More information about the Python-list mailing list