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

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.992835213.24305.python-list at python.org...
> 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.

Yes, I understand this MUST be an overriding concern.  Practicality
beats purity -- Python's speed is TOO dependent on dictionaries to
allow much play with them.

> 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>.

I think this points the way forwards.  Subclassable dictionaries
will at least allow real-life experimentation -- this may help
determine whether some potential "further dictionary feature" is
[a] of widespread-enough interest *AND* [b] susceptible of fast-
enough, memory-spare implementation, to warrant considering for
"REAL" dictionaries.


> > 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,

Maybe setB's __contains__ could specialcase this particular issue,
but it would still be there for "if setA in somedict".  My un-slick,
explicit-is-better-than-implicit approach would require *explicit*
locking/freezing as a necessary (not sufficient -- items need to be
right to) condition to make a dictionary hashable.  Having __hash__
blackmagically trigger freezing sounds somewhat scary to me, just
as it would if (e.g.) it made a list into a tuple or thereabouts.


Alex