<br><br><div class="gmail_quote">On Thu, Jul 26, 2012 at 9:06 PM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Chris Angelico wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 24, 2012 at 1:20 AM, Steven D'Aprano<br>
<<a href="mailto:steve%2Bcomp.lang.python@pearwood.info" target="_blank">steve+comp.lang.python@<u></u>pearwood.info</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Although if you think about the implementation of dicts as hash tables,<br>
it does seem likely that it is trivial to enforce this -- one would have<br>
to work *harder* to break that promise than to keep it.)<br>
</blockquote>
<br>
However, it would be quite reasonable to implement a dict as a splay<br>
tree, and have values() return them nearest-first. This would mean<br>
that just reading from the dictionary could change the order of<br>
values(), yet it wouldn't make the implementation non-conformant.<br>
</blockquote>
<br></div>
Yes, it would.  The docs say that .keys(), .values(), etc., will maintain order unless the dict is modified in between calls.<span class="HOEnZb"><font color="#888888"><br>
<br>
~Ethan~<br>
-- <br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br>On the other hand, it's a somewhat far-out thing to guarantee. If some things were relaxed a bit for the benefit of alternative implementations, I'd think this could be one of the things.  I certainly wouldn't want to write code that depends on such a behavior, if nothing else because someday I might want to use a  dict-like-object that doesn't provide such a guarantee.<br>
<br><br>