frozendict

Nathan Rice nathan.alexander.rice at gmail.com
Fri Feb 10 11:53:08 EST 2012


On Fri, Feb 10, 2012 at 5:08 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Feb 10, 2012 at 1:30 PM, Nathan Rice
> <nathan.alexander.rice at gmail.com> wrote:
>> The only thing needed to avoid the hash collision is that your hash
>> function is not not 100% predictable just by looking at the python
>> source code.  I don't see why every dict would have to be created
>> differently.  I would think having the most ubiquitous data structure
>> in your language be more predictable would be a priority.  Oh well....
>
> It's perfectly predictable. If you put a series of keys into it, you
> get those same keys back. Nobody ever promised anything about order.
>
> If your hash function is not 100% predictable, that means it varies on
> the basis of something that isn't part of either the Python
> interpreter or the script being run. That means that, from one
> execution to another of the exact same code, the results could be
> different. The keys will come out in different orders.

I think having a hash function that is not referentially transparent
is a bad thing.  Basing your language on a non-deterministic function?
 Yeah...

A type factory that produces the dict type on interpreter
initialization (or, replaces the hash function, rather), and uses
time/system information/etc would solve the problem, while limiting
the introduced non-determinism.  I don't care if the order of
iteration for keys is different from interpreter run to run.

I have used frozenset(mydict.items()) when my requirements dictated.
It is a minor performance hit.

Lets also not forget that knowing an object is immutable lets you do a
lot of optimizations; it can be inlined, it is safe to convert to a
contiguous block of memory and stuff in cache, etc.  If you know the
input to a function is guaranteed to be frozen you can just go crazy.
Being able to freeze(anyobject) seems like a pretty clear win.
Whether or not it is pythonic is debatable.  I'd argue if the meaning
of pythonic in some context is limiting, we should consider updating
the term rather than being dogmatic.

Just my 2 cents...


Nathan



More information about the Python-list mailing list