Improving Python's SimpleNamespace

Python's SimpleNamespace class provides an easy way for a programmer to create an object to store values as attributes without creating their own (almost empty) class. While it is useful (and used) in its present form, Raymond Hettinger thinks it could be better. He would like to see the hooks used by mappings (e.g. dictionaries) added to the class, so that attributes can be added and removed using either x.a or x['a']. It would bring benefits for JSON handling and more in the language.

A SimpleNamespace provides a mechanism to instantiate an object that can hold attributes and nothing else. It is, in effect, an empty class with a fancier __init__() and a helpful __repr__():

    >>> from types import SimpleNamespace
    >>> sn = SimpleNamespace(x = 1, y = 2)
    >>> sn
    namespace(x=1, y=2)
    >>> sn.z = 'foo'
    >>> del(sn.x)
    >>> sn
    namespace(y=2, z='foo')

Hettinger proposed his idea to the python-dev mailing list in mid-April. He described it as follows:

     catalog = json.load(f, object_hook=SimpleNamespace)
     print(catalog['clothing']['mens']['shoes']['extra_wide']['quantity']) # currently possible with dict()
     print(catalog.clothing.mens.shoes.extra_wide.quantity)                # proposed with SimpleNamespace()
     print(catalog.clothing.boys['3t'].tops.quantity)                      # would also be supported

There are examples of production code that does this sort of thing, he said, but each user needs to reinvent the wheel: "This is kind of [a] bummer because the custom subclasses are a pain to write, are non-standard, and are generally somewhat slow." He had started with a feature request in the Python bug tracker, but responses there suggested adding a new class.

Guido van Rossum thought that kind of usage was not particularly Pythonic, and was not really in favor of propagating it:

Kyle Stanley wondered if it made sense for the feature to reside in the json module; "that seems like the most useful and intuitive location for the dot notation". He thought that JSON users would not be surprised by that style of usage, but Van Rossum disagreed:

Several others agreed that the duality of object and dictionary access was not a good fit for Python, but there is a still a problem to be solved, as Hettinger noted: "working with heavily nested dictionaries (typical for JSON) is no fun with square brackets and quotation marks". Victor Stinner listed a handful of different projects from the Python Package Index (PyPI) that provide some or all of the features that are desired, but he did not see that any of those had "been battle-tested and gained enough popularity" that they should be considered for the standard library.

Stinner (and others in the thread) pointed to the glom library as one that might be of use in working with deeply nested JSON data. But the "AttrDict" pattern is rather popular, as Hettinger pointed out. glom can do lots more things, but it is not able to freely mix and match the two access types as Hettinger wants.

There were some who thought it might be reasonable for the json module to provide the functionality, as Stanley had suggested, including Van Rossum who seemed to come around to the idea. Glenn Linderman supported adding the feature in a bug report comment; he thinks it is useful well beyond just JSON. "Such a feature is just too practical not to be Pythonic." Similarly, Cameron Simpson thought it would make a good addition:

It is true that adding dictionary-like functionality to SimpleNamespace should not affect existing code, but most in the thread still seem to be against adding the feature to that class. Eric Snow put it this way:

Perhaps the most radical suggestion came from Rob Cliffe. He thought it might make sense to add a new operator to the language (perhaps "..") with no default implementation. That would allow classes to define the operator for themselves:

    obj..abc..def..ghi

As Stinner pointed out, though, that and some of the other more speculative posts probably belonged in a python-ideas thread instead. It does not seem particularly likely that SimpleNamespace will be getting this added feature anytime soon—or at all. There is enough opposition to making that change, but there is recognition of the problem, so some other solution might come about. It would, presumably, need the PEP treatment, though; a visit to python-ideas might be in the offing as well.