cannot create my own dict

[A.T.Hofkamp]

On 2007-09-19, Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> wrote:
> A.T.Hofkamp a écrit :
>> So if copying all methods of a native dictionary is not enough, what should I
>> do to make my class work as a dictionary WITHOUT deriving from dict (which will
>> obviously work).
>>

Hello all,

Thanks for all the suggestions, the cause of the problem seems to be that I
assumed that I can export magic methods from a member. Apparently, that is not
true :-(

> Sorry, I missed this last requirement. BTW, why don't you want to 
> subclass dict ?

The reason for this problem is that we are busy re-structuring a large Python
program, and we want to ensure nobody is messing up our data structures (at
least not until we are finished).
Most data types have a nice frozen variant (set -> frozenset, list -> tuple,
__setattr__ override), but dictionaries do not.

As a result I wanted to have a read-only dictionary.
There is one in the Cook book, but it uses property's that I don't understand
and they are also not in de Python language reference (at least I couldn't find
them in the index and not in the table of contents).
I don't like code that I don't understand (in particular when bugs in that code
will be nasty to debug), so I decided to write my own, not in the last place,
because I expected it to be simple in Python.
I can derive from dict, but the problem with that is that I start with a
read/write dictionary, and I can only hope to plug all holes to prevent my data
from leaking out.
By starting from 'object', I certainly don't have that problem, I start with a
closed bucket and punch holes in it in a controlled way.
(I rather have the program drop dead due to not having enough access than
have it continue with too much access causing havoc 500 statements later in a
totally unrelated area.)

Rather than write a bunch of code like

    def __contains__(self, val):
        return val in self.mydict

I thought I'd simply do

   self.__contains__ == self.d.__contains__

which is exactly the same but less work (or so I thought), and possibly
slightly faster.

Well, no such luck thus :-(


Tnx for clearing up the problem,
Albert