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