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:

     catalog = json.load(f)
     print(catalog['clothing']['mens']['shoes']['extra_wide']['quantity'])

Proposed:

     catalog = json.load(f, object_hook=SimpleNamespace)
     print(catalog.clothing.mens.shoes.extra_wide.quantity])

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.

>>> SimpleNamespace(username1='value1', username2='value2')
namespace(username1='value1', username2='value2')
>>> dir(_)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'username1', 'username2']

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.

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.

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

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.

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.

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.

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.

Only the magic methods need to be added: getitem, setitem, and delitem, contains, len, and iter.

Out of interest @rhettinger, what was your implementation for the above? I would absolutely love to be able to use the following:

In particular, it would be wonderful to be able to use object_hook=SimpleNamespace in json.load():

Cheers,
Simon