No it really shouldn't. The usage is highly problematic because of naming conflicts and the implicit default behavior. This causes more problems than it's worth.
I'm not suggesting that it override the default dictionary behavior, but that it would be nice to have the option of using javascript-like object syntax by importing some special dict class. This library is really young, but I've always thought this sort of feature would be nice syntactic sugar, particularly for configuration objects. I find myself using namedtuples for this sort of thing, but it would be nice to have the option of using an ad-hoc data structure like this that's inherently trivial to serialize.
What I'd really like to see is new syntax for item access. Transform a::b into a['b'].
Items and attributes are different, and failing to distinguish can make your code fragile - for example, it looks like Dict().get will return the attribute, unlike Dict()['get']. And if a new python version adds a new method to dict, some of your uses of Dict() will now break.
But item access is ugly when dealing with nested JSON or any number of other things, and that leads to people like me using terrible hacks that ambiguate between the two.
> but that it would be nice to have the option of using javascript-like object syntax by importing some special dict class
It's dangerous to use because it needs recursive collapsing to a regular dict otherwise it's not safe to pass to many APIs. So yeah, it should definitely not exist in the standard library.
If you are Armin, I want to take a moment to say I love your work. This ruby-like dict class probably doesnt belong in the std python lib, but it is nice to have in pypi because of the syntactic sugar. No denying that it is kind of a leaky abstraction, one might even say a hack, but it has the potential to be useful for concisely expressing nested key-value objects, as long as the object instantiation is explicit so a reader would immediately know what they're working with. It's really easy to implement something like this by inheriting from dict and setting some magic methods, but I feel like I find myself implementing Struct classes like this for myself because it can be more elegant sometimes than nested dicts. If the python community agrees on the correct semantics for a defaultdict-like object with __getattr__ and __settattr__ implementations, it might be more elegant than the status-quo for ad-hoc objects: http://stackoverflow.com/questions/2827623/python-create-obj...
I agree with this. Even though I've used my Struct thing for a long while now _and_ subclassing dict directly in my case, I've been bitten by similar issues.
The syntactic sugar is very nice and saves up on oodles of brackets and quotes for nested objects, but if you try to mutate this sort of object you'll eventually run into trouble.
That (use as a config object) is exactly why I did my Struct thing. But if I were to do it again, I'd certainly make it immutable (although that would complicate the implementation somewhat)
