[Python-ideas] Add a dict with the attribute access capability
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.  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?
def __init__(self, *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
Aren't these implementation details?
More information about the Python-ideas