3 ms·

> 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 nee

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

rcarmo 12y ago
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.
Cieplak 12y ago
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-object-and-add-attributes-to-it http://stackoverflow.com/questions/2827623/python-create-obj...

3 ms·

> 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 nee

by the_mitsuhiko 12y ago

rcarmo 12y ago
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.
Cieplak 12y ago
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-object-and-add-attributes-to-it http://stackoverflow.com/questions/2827623/python-create-obj...