<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 22, 2014 at 11:48 AM,  <span dir="ltr"><<a href="mailto:random832@fastmail.us" target="_blank">random832@fastmail.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Sep 21, 2014, at 01:18, David Wilson wrote:<br>
> Coming from this perspective, I'd prefer that further additions were<br>
> limited to clean and far better understood structures. In this light,<br>
> could we perhaps instead discuss the merits of a collections.Tree,<br>
> collections.SortedDict or similar?<br>
<br>
</span>As I understand it, the problem with a tree, SortedDict/SortedSet, or in<br>
general any collection that relies on comparison relationships (heap,<br>
etc), is: unlike hashing (where Hashable implies an immutable hash<br>
relationship), there is no way to detect whether an object implements an<br>
immutable well-defined ordering. And that, unlike a mutable hashed<br>
object (which can AIUI only lose itself), a mutable sorted object (or a<br>
badly-behaved one like NaN) can cause other objects in the set to be<br>
inserted in the wrong place or not found.<br></blockquote><div><br></div><div>A good point, too often overlooked.<br><br>We could introduce a convention requiring __hash__() even though it is not used by the implementation. After all, if the object is immutable when it comes to a well-defined ordering, it is immutable when it comes to equality. I don't really want to think about classes that are immutable when it comes to == but not when it comes to <; that seems terrible.<br></div></div><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>