[Python-ideas] Add a dict with the attribute access capability

Steven D'Aprano steve at pearwood.info
Wed Nov 29 22:40:13 EST 2017

On Wed, Nov 29, 2017 at 10:52:51AM +0200, Serhiy Storchaka wrote:

> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it 
> already was deprecated when the plistlib module was added to the regular 
> stdlib in Python 2.6.
> This is a dict subclass which allows to access items as attributes.

Isn't that a trivial subclass?

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

Possibly apart from a nicer repr, have I missed anything?

> Raymond noticed that that capability seemed nice to have.
> What do you think about reviving this type as general purpose type in 
> collections or types? Perhaps it can be convenient for working with 
> JSON, plists, configuration files, databases and in other cases that 
> need a dict with string keys.

I doubt that it is as convenient as you think. Most of the time I work 
with external data, I don't know the keys in advance, so I couldn't use 
obj.attr syntax. Configuration files (and equivalent) are possibly an 

But in general I'm suspicious of using attribute access for key lookups. 
I cannot help feeling that, while laziness and hubris are virtues in 
programmers, this is *too* lazy. This conflates two distinct concepts, 
attributes and key/value pairs. Attributes are conceptually part of the 
object, as in dog.tail or car.engine, or data about the object, like 
page.top_margin or engine.capacity. Key/value data is not.

Another way to look at this would be to say that deleting attributes 
is rare and unusual, while deleting keys is generally frequent and 

Its not a completely hard distinction, I acknowledge that its already a 
bit fuzzy, but I'm not sure it is a good idea to make it even fuzzier.

Consequently I'm strongly opposed to making this standard behaviour for 
dict and other mappings, but I'm neutral about making it opt-in for a 
distinct mapping type.

> If reintroduce it, there are open questions.
> 1. The name of the type.

AttrDict seems like the obvious name.

> 2. The location of the type. collections or types? Or other variants?

It is a mapping, which is a collection, so collections.

> 3. How it will collaborate with OrderedDict, defaultdict, etc?

Does it need to?

> 4. Should it be a dict subclass, or a mixin, or a proxy? Or add several 
> types?

Aren't these implementation details?


More information about the Python-ideas mailing list