pairs from a list

[Steven D'Aprano]

On Wed, 23 Jan 2008 11:06:44 -0800, George Sakkis wrote:

> On Jan 23, 1:30 pm, Paddy <paddy3... at googlemail.com> wrote:
> 
>> I've heard quality expressed as "meeting requirements", which I think
>> is apt. Falling short of requirements everyone knows doesn't give a
>> quality result, but equally 'exceeding' requirements also detracts from
>> quality (as does not knowing your requirements). It is good to learn
>> optimization techniques, which may be part of what you are saying, but
>> part of that is learning when it pays to apply them and/or search for
>> them; and when it does not.
> 
> The OP wanted an answer to a simple question, not a lecture on good
> software engineering principles.


(1) It isn't a simple question. There were at least five alternatives, 
one of which would have been "fastest" except it failed the correctness 
test. The OP went on to ask:

"I suppose my question should have been, is there an obviously faster way?
Anyway, of the four ways below, the first is substantially fastest. 
[Note: actually it wasn't.]  Is there an obvious reason why?"

Asking *why* something is faster is very different from asking *which* is 
faster. I don't believe anyone actually answered that "why" question.

So, for the record, here's my attempt at an answer:

No, there is no "obvious" reason why one solution should be faster than 
another. But perhaps the two most general rules of thumb are:

* the more work you can push into built-ins written in C, and the least 
in slow code written in Python, the faster;

* lazy iterators are often (but not always) faster than building the 
entire list all at once.



Other than that, the details of why one particular technique is faster 
than another depends on the implementation of each, and that's not 
obvious.



(2) What the OP wanted and what he needed are not necessarily the same. 
Answering the OP's direct question is like giving him a fish -- he'll be 
hungry tomorrow. Teaching him good engineering principles is like 
teaching him to fish.

(3) This is Usenet, and the advice is free. Sometimes you get more than 
you expected, sometimes less. Regardless of what the OP wanted, the 
thread will go where the thread will go. The discussions of software 
engineering were mostly in response to you, not the OP.



-- 
Steven