<div dir="ltr">For the regular dict (non kwargs or namespace __dict__) use case I would actually like to <i>see disorder preserved during iteration</i>.<div><br></div><div>If we don't, we will eventually to find ourselves in a similar state we were in pre hash-randomization:</div><div> (1) Over time, code will come to depend on the order for no good reason. Especially true of tests. This greatly increases the engineering barrier when trying to move a codebase between Python versions or Python VMs.</div><div><br></div><div>The underlying implementation is free to preserve order (as it now does, great work!) but I think the behavior of iteration when an ordered type was not explicitly requested or ordered iteration was not explicitly requested should be perturbed in order to maintain long term code health.</div><div><br></div><div>Disorder for this purpose need not be a random shuffle (overkill). It just needs to be regularly inconsistent. A simple thing to do on top of 3.6's new dict implementation would be to pick a random starting point within the order array rather than offset 0 to start iteration from. That small change would be sufficient to guarantee that code depending on order must ask for order. It could even allow us to get people ready for iteration within the same process to become unstable.</div><div><br></div><div>Maybe I worry too much. Having slogged through fixing problems to enable hash randomization on a code base of tens of millions of lines in 2012... there is a lot of value in enforcing disorder where none is intended to be guaranteed. Explicit is better than implicit.</div><div><br></div><div>-gps</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 12, 2016 at 5:37 AM Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2016-09-12 13:50 GMT+02:00 Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" class="gmail_msg" target="_blank">solipsis@pitrou.net</a>>:<br class="gmail_msg">
> Besides, I don't think it has been proven that the compact-and-ordered<br class="gmail_msg">
> dict implementation is actually *faster* than the legacy one.<br class="gmail_msg">
<br class="gmail_msg">
Python 3.6 dict is slower than Python 3.5 dict, at least for a simple lookup:<br class="gmail_msg">
<a href="http://bugs.python.org/issue27350#msg275581" rel="noreferrer" class="gmail_msg" target="_blank">http://bugs.python.org/issue27350#msg275581</a><br class="gmail_msg">
<br class="gmail_msg">
But its memory usage is 25% smaller.<br class="gmail_msg">
<br class="gmail_msg">
I'm curious about the performance of the "compaction" needed after<br class="gmail_msg">
adding too many dummy entries (and to preserve insertion order), but I<br class="gmail_msg">
don't know how to benchmark this :-) Maybe add/remove many new keys? I<br class="gmail_msg">
expect bad performance on the compaction, but maybe not as bad as the<br class="gmail_msg">
"hash DoS".<br class="gmail_msg">
<br class="gmail_msg">
For regular Python code, I don't expect compaction to be a common<br class="gmail_msg">
operation, since it's rare to remove attributes. It's more common to<br class="gmail_msg">
modify attributes value, than to remove them and later add new<br class="gmail_msg">
attributes.<br class="gmail_msg">
<br class="gmail_msg">
Victor<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Python-Dev mailing list<br class="gmail_msg">
<a href="mailto:Python-Dev@python.org" class="gmail_msg" target="_blank">Python-Dev@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br class="gmail_msg">
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/greg%40krypto.org" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br class="gmail_msg">
</blockquote></div>