I've just encountered another case where the lack of a key on bisect has led to more complicated and error-prone code than necessary.

Quick summary: we've got a list containing an ordered collection of non-overlapping open intervals on the real line.  (In case anyone wants to know, the intervals represent the depths of chunks of interest in a rock core sample.)  There's then code for splitting an interval into two pieces at a given point, and for merging two adjacent intervals.  Splitting involves (i) finding the relevant interval using a bisect search based on the left endpoint of each interval, then (ii) replacing that interval with two new intervals in the list.

The fact that the list is being modified after every bisect search makes it messy to cache the left endpoints, since that cache has to be updated along with the list at every stage.  The operations are also relatively rare, which makes it feel inefficient to be computing *all* the left endpoints of the intervals in the first place.

Adding comparisons to our interval class is doable, but invasive and unnatural, since the actual class carries other pieces of data and there are many possible meanings for `<` with respect to that class: it doesn't make sense to hard-code the comparison with respect to depths in that class's `__lt__` method.

So I think there's a strong case for a key argument in some future version of Python.

[Of course, for our app we're on Python 2.7, so this issue won't help us directly.  We're probably going to go with either reimplementing bisect or using a proxy array like the one suggested by Eric Reynolds.]