jason.orendorff at gmail.com
Tue Feb 14 10:28:51 PST 2012
On Tue, Feb 14, 2012 at 5:02 AM, David Bruant <bruant.d at gmail.com> wrote:
>> To be sure, this is assuming that iteration order is fixed for a given
>> implementation. If order is not specified, then I don't see why that
>> should be required either.
> It is not required, but it's what experience tells us from the for-in loop.
All right, but let's not make the mistake of only learning from our
Many other language communities have very specific relevant
experience. For example, there is a single dominant Java
implementation and a single dominant Python implementation. Have the
other implementations been forced to duplicate the dominant
implementation's hash table iteration order, because existing code
depends on it? Have the dominant implementations been forced to back
out memory management changes or hash table optimizations that would
affect iteration order?
I don't think that has ever happened. Python hash codes differ from
version to version and from OS to OS. Jython has a completely
different hashing function from CPython, even for strings. Keep in
mind that hash tables are one of two core data structures in Python,
so if code could sanely depend on iteration order, it would.
Of course code will depend on unspecified behavior when that
unspecified behavior is actually intelligible and useful. Experience
suggests hash table iteration order is neither.
Mark Miller is holding up the argument for determinism really well.
I'm not sure anyone disagrees with his points. We should look into
deterministic data structures and measure the performance.
More information about the es-discuss