locking dictionaries (was Re: New statement proposal for Python)

Tim Peters tim.one at home.com
Sun Jun 17 23:32:30 EDT 2001


There's a PEP in here somewhere <wink>.  Eric Raymond brought up similar
ideas on Python-Dev some time ago, but nothing came of it then.

One concern:  since dicts are crucial to Python's performance, we're loathe
to add any code to their critical paths, or more memory to the object.
Indeed, I spent a fair chunk of my life reducing the internal dict bloat
after 2.1 was released, and we got some nice speedups in return.

Provided Guido is successful in healing the type/class split, it should be
possible to subclass dicts (in Python or C), and you can make those just as
slothful as you can bear <wink>.

[Alex Martelli]
> ...
> my correspondant was appalled at the idea of using 'bits' to overtly
> encode 'a set of options' and I could not find an alternative, as
> Python lacks 'sets'.
> ...
> A dictionary whose lockbits are set to forbid ANY rebinding,
> deleting, new-key binding, AND change to the lockbits, could
> suddenly and logically sprout hashability, since it becomes an
> acceptable key IF it has hashable values (much like a tuple --
> if the items are changeable, the fact that the _container_ is
> not does not suffice).  But that's an aside, I guess.

Earlier talk about freezing a dict actually started in relation to Greg
Wilson's PEP to add a set type to Python.  He's implementing sets as dicts
under the covers, and so sets of sets (etc) require hashing (and freezing)
dicts.  I don't think we have a slick solution for that.  Right now a Set
instance sets a .frozen flag when its __hash__ method gets called, and all
the mutating Set methods check that flag at the start (raising an exception
if it's set).  The problem is that the flag gets lit sometimes when it
needn't be; e.g., doing

    if setA in setB:

shouldn't freeze setA forever.  So hash() is a wrong thing to key on.  OTOH,
dict[setA] = 42 *must* freeze setA's dict, and the only clue the Set type
has is that hash() gets called.

So look on the bright side:  if you never get these bits, you'll never have
to wrestle with managing them either <0.8 wink>.





More information about the Python-list mailing list