<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 9, 2012, at 9:48 AM, Guido van Rossum wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">The more fundamental "conflict" here seems to be between algorithms and classes. list.sort(), bisect and heapq focus on the algorithm.</span></blockquote><br></div><div>Bisect in particular had way too much focus on the algorithm.  The API is awkward and error-prone for many common use cases.</div><div><br></div><div>I've tried to remedy that through documenting how to implement the common use cases:   <a href="http://docs.python.org/py3k/library/bisect.html#searching-sorted-lists">http://docs.python.org/py3k/library/bisect.html#searching-sorted-lists</a></div><div><br></div><div>The issue is that the current API focuses on "insertion points" rather than on finding values.  Unfortunately, this API is very old, so the only way to fix it is to introduce a new class.</div><div><br></div><div>If we introduced class around a sorted sequence, then we could make an reasonable API that corresponds to what people usually want to do with sorted sequences.  </div><div><br></div><div>Of course, that still leaves the issue with an O(n) insort.  As Daniel pointed-out, a list is not the correct underlying data structure if you want to do periodic insertions and deletions.</div><div><br></div><div><br></div><div>Raymond</div><br></body></html>