question on dict subclassing and overriding __setitems__

[Eric S. Johansson]

I apologize if this is an FAQ but googling has not turned up anything,
at least to my keywords.

I need to parse a configuration file from an existing application and
I'm treating it as a dictionary. I created my class with a parent class
of dict. Everything works okay except I discover I need to force keys
to uppercase when setting a value.

I override __setitems__ and, as you'd expect, I get a recursive loop.
I'm obviously missing a clue on how to break the recursion. My
admittedly simpleminded method overloading looks like:

def __setitem__ (self, index, value):
"""force keys to uppercase"""
self[index.upper()] = value

thanks for any pointers.

[Diez B. Roggisch]

Eric S. Johansson schrieb:

I apologize if this is an FAQ but googling has not turned up anything,
at least to my keywords.

I need to parse a configuration file from an existing application and
I'm treating it as a dictionary. I created my class with a parent class
of dict. Everything works okay except I discover I need to force keys
to uppercase when setting a value.

I override __setitems__ and, as you'd expect, I get a recursive loop.
I'm obviously missing a clue on how to break the recursion. My
admittedly simpleminded method overloading looks like:

def __setitem__ (self, index, value):
"""force keys to uppercase"""
self[index.upper()] = value

dict.__setitem__(self, index.upper()) = value

Or better even

super(subclass, self).__setitem__(key.upper(), value)
DIez

[Eric S. Johansson]

Diez B. Roggisch wrote:

dict.__setitem__(self, index.upper()) = value
oh duh.
Or better even

super(subclass, self).__setitem__(key.upper(), value)

hmm. http://fuhm.net/super-harmful/

I think I need to do some more reading.

---eric

[George Sakkis]

Eric S. Johansson wrote:

Diez B. Roggisch wrote:

Or better even

super(subclass, self).__setitem__(key.upper(), value)

hmm. http://fuhm.net/super-harmful/

Interesting link, didn't know about it. I've always found super() ugly
and doubted that it was in practice better suited for multiple
inheritance than explicit method call, but I kept using it nonetheless
since it was "blessed" for new style classes. Unless of course the code
broke for one of the reasons mentioned in the article, in which case I
reverted back to the "old way". Good to know that I can safely get rid
of practically all super() calls. Any python-dev-er's take on super()'s
utility and future in Py3K ?

George