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

[Steven D'Aprano]

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 
exception.

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 
commonplace.

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?



-- 
Steve