On 3/2/07, <b class="gmail_sendername">Adam Olsen</b> <<a href="mailto:rhamph@gmail.com">rhamph@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 3/1/07, Jason Orendorff <<a href="mailto:jason.orendorff@gmail.com">jason.orendorff@gmail.com</a>> wrote:<br>> I wonder if anyone else finds the heapq and bisect APIs a little dated.</blockquote><div><br>Ooh, me, me! 
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> It seems like these things could be offered in a more intuitive and<br>> featureful way by making them classes.  They could go in the
<br>> collections module: </blockquote><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I agree, at least for heapq.  The algorithm involves enough voodoo
<br>that it's not obvious how to extend it, so it might as well be wrapped<br>in a class that hides as much as possible.</blockquote><div><br>Sounds good to me. +1<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The same can't be said for bisect though.  All it does is replace del<br>a[bisect_left(a, x)] with a.remove(x).  A little cleaner, but no more<br>obvious.  And the cost is still O(n) since it involves moving all the<br>
pointers after x.</blockquote><div><br>A sortedlist class seems like a useful abstraction to me, since while using an instance
of such a class, you could be sure that the list remains sorted. For example, you don't have to worry about it being changed outside of your code and no longer being sorted.<br><br>Also, wouldn't a sortedlist class also have in insert() method to replace 
bisect.insort(), as well as different implementations of __contains__ and index?<br></div></div>