Accessing dict keys like an attribute?

Question

I find it more convenient to access dict keys as obj.foo instead of obj['foo'], so I wrote this snippet:

class AttributeDict(dict):
    def __getattr__(self, attr):
        return self[attr]
    def __setattr__(self, attr, value):
        self[attr] = value

However, I assume that there must be some reason that Python doesn't provide this functionality out of the box. What would be the caveats and pitfalls of accessing dict keys in this manner?

Answer 1

The best way to do this is:

class AttrDict(dict):
    def __init__(self, *args, **kwargs):
        super(AttrDict, self).__init__(*args, **kwargs)
        self.__dict__ = self

Some pros:

• It actually works!
• No dictionary class methods are shadowed (e.g. .keys() work just fine. Unless - of course - you assign some value to them, see below)
• Attributes and items are always in sync
• Trying to access non-existent key as an attribute correctly raises AttributeError instead of KeyError
• Supports [Tab] autocompletion (e.g. in jupyter & ipython)

Cons:

• Methods like .keys() will not work just fine if they get overwritten by incoming data
• Each AttrDict instance actually stores 2 dictionaries, one inherited and another one in __dict__
• Causes a memory leak in Python < 2.7.4 / Python3 < 3.2.3
• Pylint goes bananas with E1123(unexpected-keyword-arg) and E1103(maybe-no-member)
• For the uninitiated it seems like pure magic.

A short explanation on how this works

• All python objects internally store their attributes in a dictionary that is named __dict__.
• There is no requirement that the internal dictionary __dict__ would need to be "just a plain dict", so we can assign any subclass of dict() to the internal dictionary.
• In our case we simply assign the AttrDict() instance we are instantiating (as we are in __init__).
• By calling super()'s __init__() method we made sure that it (already) behaves exactly like a dictionary, since that function calls all the dictionary instantiation code.

One reason why Python doesn't provide this functionality out of the box

As noted in the "cons" list, this combines the namespace of stored keys (which may come from arbitrary and/or untrusted data!) with the namespace of builtin dict method attributes. For example:

d = AttrDict()
d.update({'items':["jacket", "necktie", "trousers"]})
for k, v in d.items():    # TypeError: 'list' object is not callable
    print "Never reached!"

Update - 2020

Since this question was asked almost ten years ago, quite a bit has changed in Python itself since then.

While this approach is still valid for some cases, e.g. legacy projects stuck to older versions of Python and cases where you really need to handle dictionaries with very dynamic string keys - I think that in general the dataclasses introduced in Python 3.7 are the obvious/correct solution to vast majority of the use cases of AttrDict.