You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add mapping methods to types.SimpleNamespace #84465
types.SimpleNamespace() would be much more usable if it were more substitutable for dictionaries. In particular, it would be wonderful to be able to use object_hook=SimpleNamespace in json.load():
I would prefer that SimpleNamespace remains as simple as it is
This doesn't affect the simplicity of the current API at all. If you don't need the feature, you won't even notice the extension.
If you want to add the mapping protocol, I suggest you to create
your own subclass and add the methods that you want
I do that for myself. However, users would greatly benefit from having this an option.
We don't ask users to write their own defaultdicts from scratch even though that is simple dict subclass. Providing this tool would instantly benefit a broad class of json users.
I'm not saying that there is no need for such tool.
I am just asking to leave SimpleNamespace unchanged.
I really don't see the downside. It doesn't impair SimpleNamespace in any way. Why would we add another type with substantially the same capabilities as SimpleNamespace? That would be a complete waste.
vpython commented on Apr 15, 2020
vpythonmannequin
Mannequin
More actions
Yes, I laud this effort. I don't care if it is called SimpleNamespace (which I didn't use because it was insufficient), or anything else, but it would be extremely handy to have this battery.
I eventually found one called Dotable (or did I rename it to that?) which after a fair bit of study I finally understood, and then was able to add a few tweaks to make it work the way that was most convenient for me.
While I agree with Guido that these are not standard Python semantics, they are, as pointed out by Raymond, far more convenient to use for nested structures.
And as far as using CoffeeScript, I don't know of a CoffeeScript to Python conversion: the rest of the semantics of Python are more preferable than Javascript. I just wish Brendan Eich had consulted with Guido before inventing Javascript.
vpython commented on Apr 15, 2020
vpythonmannequin
Mannequin
More actions
Here's what I have.
Maybe it would be better if parse and dump were under or dunder names, although I think parse was in the original implementation I found.
Is this the derived from the same original as PyPI dotable? Not sure.
vedgar commented on Apr 15, 2020
vedgarmannequin
Mannequin
More actions
I think there is a teaching moment here. I think it's important that no object in Python standard library conflates "item namespace" with "attr namespace". (Maybe that isn't true because of some specialized objects, but surely general ones such as SimpleNamespace shouldn't commit that mistake.)
On the other hand, we do have json in standard library, and JSON is primarily based on JavaScript Object Notation (yes, I know it's been extended to fit more languages, but still, its primal DNA shows). And the conflating of attributes and items is so natural in JS (a['b']===a.b) that it took them more than a decate to realize that separating Map from Object might be a good idea. :-)
So, maybe we should also have something like JSNamespace in stdlib (presumably in json module). But SimpleNamespace shouldn't be it. As Guido once said, a bucket has a handle, and it contains sand, but it doesn't contain a handle.
It seems like most core developers are against modifying types.SimpleNamespace, the trend is more about adding a different class.
About a different class, so far, I see no consensus on an API. I suggest to close this issue (which is about types.SimpleNamespace) and continue the discussion on python-dev.
Activity
rhettinger commentedon Apr 14, 2020
types.SimpleNamespace() would be much more usable if it were more substitutable for dictionaries. In particular, it would be wonderful to be able to use object_hook=SimpleNamespace in json.load():
Current:
Proposed:
rhettinger commentedon Apr 14, 2020
Only the magic methods need to be added: __getitem__, __setitem__, and __delitem__, __contains__, __len__, and __iter__.
The non-dunder names risk incursion into user-space names.
vstinner commentedon Apr 14, 2020
I would prefer that SimpleNamespace remains as simple as it is:
https://docs.python.org/dev/library/types.html#types.SimpleNamespace
"A simple object subclass that provides attribute access to its namespace"
If you want to add the mapping protocol, I suggest you to create your own subclass and add the methods that you want.
rhettinger commentedon Apr 14, 2020
This doesn't affect the simplicity of the current API at all. If you don't need the feature, you won't even notice the extension.
I do that for myself. However, users would greatly benefit from having this an option.
We don't ask users to write their own defaultdicts from scratch even though that is simple dict subclass. Providing this tool would instantly benefit a broad class of json users.
vstinner commentedon Apr 14, 2020
I'm not saying that there is no need for such tool. I am just asking to leave SimpleNamespace unchanged.
rhettinger commentedon Apr 14, 2020
I really don't see the downside. It doesn't impair SimpleNamespace in any way. Why would we add another type with substantially the same capabilities as SimpleNamespace? That would be a complete waste.
vpython commentedon Apr 15, 2020
Yes, I laud this effort. I don't care if it is called SimpleNamespace (which I didn't use because it was insufficient), or anything else, but it would be extremely handy to have this battery.
I eventually found one called Dotable (or did I rename it to that?) which after a fair bit of study I finally understood, and then was able to add a few tweaks to make it work the way that was most convenient for me.
While I agree with Guido that these are not standard Python semantics, they are, as pointed out by Raymond, far more convenient to use for nested structures.
And as far as using CoffeeScript, I don't know of a CoffeeScript to Python conversion: the rest of the semantics of Python are more preferable than Javascript. I just wish Brendan Eich had consulted with Guido before inventing Javascript.
vpython commentedon Apr 15, 2020
Here's what I have.
Maybe it would be better if parse and dump were under or dunder names, although I think parse was in the original implementation I found.
Is this the derived from the same original as PyPI dotable? Not sure.
vedgar commentedon Apr 15, 2020
I think there is a teaching moment here. I think it's important that no object in Python standard library conflates "item namespace" with "attr namespace". (Maybe that isn't true because of some specialized objects, but surely general ones such as SimpleNamespace shouldn't commit that mistake.)
On the other hand, we do have json in standard library, and JSON is primarily based on JavaScript Object Notation (yes, I know it's been extended to fit more languages, but still, its primal DNA shows). And the conflating of attributes and items is so natural in JS (a['b']===a.b) that it took them more than a decate to realize that separating Map from Object might be a good idea. :-)
So, maybe we should also have something like JSNamespace in stdlib (presumably in json module). But SimpleNamespace shouldn't be it. As Guido once said, a bucket has a handle, and it contains sand, but it doesn't contain a handle.
vstinner commentedon Apr 20, 2020
Raymond started a thread on python-dev:
https://mail.python.org/archives/list/[email protected]/message/JOMND56PJGRN7FQQLLCWONE5Z7R2EKXW/
It seems like most core developers are against modifying types.SimpleNamespace, the trend is more about adding a different class.
About a different class, so far, I see no consensus on an API. I suggest to close this issue (which is about types.SimpleNamespace) and continue the discussion on python-dev.
SimonBiggs commentedon May 3, 2023
Out of interest @rhettinger, what was your implementation for the above? I would absolutely love to be able to use the following:
Cheers,
Simon