Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #20173

Re: frozendict

Show all headers | View raw

On Fri, Feb 10, 2012 at 5:08 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Feb 10, 2012 at 1:30 PM, Nathan Rice
> <nathan.alexander.rice@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-08 22:43 -0500
  Re: frozendict Duncan Booth <duncan.booth@invalid.invalid> - 2012-02-09 10:33 +0000
    Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-09 09:36 -0500
      Re: frozendict Duncan Booth <duncan.booth@invalid.invalid> - 2012-02-09 14:52 +0000
        Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-09 10:19 -0500
          Re: frozendict Duncan Booth <duncan.booth@invalid.invalid> - 2012-02-09 18:47 +0000
        Re: frozendict Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-09 09:35 -0700
          Re: frozendict Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-10 01:24 +0000
            Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-09 21:30 -0500
            Re: frozendict Terry Reedy <tjreedy@udel.edu> - 2012-02-09 22:33 -0500
            Re: frozendict Chris Angelico <rosuav@gmail.com> - 2012-02-10 21:08 +1100
            Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-10 11:53 -0500
            Re: frozendict Chris Rebert <clp2@rebertia.com> - 2012-02-10 09:00 -0800
            Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-10 13:14 -0500
              Re: frozendict John Nagle <nagle@animats.com> - 2012-02-10 10:57 -0800
                Re: frozendict 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-10 21:52 -0800
                Re: frozendict John Nagle <nagle@animats.com> - 2012-02-13 13:15 -0800
        Re: frozendict Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-09 11:50 -0500

csiph-web