[Python-ideas] Optional key to `bisect`'s functions?

[Masklinn]

On 2012-02-09, at 01:25 , Guido van Rossum wrote:
> Hmm... I disagree with Raymond's rejection of the proposed feature. I have
> come across use cases for this functionality multiple time in real life.
> 
> Basically Raymond says "bisect can call the key() function many times,
> which leads to bad design". His alternative, to use a list of (key, value)
> tuples, is often a bit clumsy when passing the sorted list to another
> function (e.g. for printing); having to transform the list using e.g. [v
> for (k, v) in a] feels clumsy and suboptimal.

Yes, this is the kind of things which prompted my original email. It is even
clumsier when there are many (smaller) lists to manipulate and insert into
in turn, and requires two verbose and potentially expensive phases of
decoration and undecoration.

Using two separate lists has similar (though simpler) issues, especially
when producing API-related structures as the "helper" collection must be
cleaned up during an undecoration phase.

And as Terry notes, this gets very clumsy as each candidate insertion now
requires three statements (a call to bisect_right to get the insertion
index followed by an insertion into the helper list and an other one for
the actual list).