Add AttrDict to JSON module for use with object_hook

[rhettinger]

AttrDict is used improve the readability of nested data access from JSON files. Compare:

 config.servers.setup.interfaces.mgmt.protocol
 config["servers"]["setup"]["interfaces"]["mgmt"]["protocol"]

Victor's research showed that tooling this is very popular in Python world and the implementation dates back quite far. At first I suggested I suggested extending SimpleNamespace(); instead, Guido recommended putting this is the JSON module which is where it would primarily be used:

with open('kepler.json') as f:
    kepler = json.load(f, object_hook=AttrDict)
print(kepler.orbital_period.neptune)

Linked PRs

• Revert "GH-96145: Add AttrDict to JSON module for use with object_hook (#96146)" #105948
• [3.12] Revert "GH-96145: Add AttrDict to JSON module for use with object_hook (GH-96146)" (GH-105948) #106117
• gh-96145: Add AttrDict to JSON module for use with object_hook #96146

[JelleZijlstra]

I'd like to propose reverting this change and removing AttrDict from 3.12.

1. The feature didn't receive proper discussion. It was open for only a few days, with no input from others and no review on the PR. There was an old mailing list thread, but that thread didn't end in any consensus.

2. The implementation has surprising edge cases.

>>> d=json.AttrDict()
>>> d.pop
<built-in method pop of AttrDict object at 0x1046ee640>
>>> d.pop = 3
>>> d.pop
<built-in method pop of AttrDict object at 0x1046ee640>

Some of this is called out in the documentation, but this sample feels weird enough to me that I don't want this behavior in the standard library.

3. More generally, attribute access and subscripting are different things in Python. They work on different objects and come with different sets of expectations. An object that allows both attribute access and subscripting to do the same thing muddies that difference and makes the language less consistent.

[carljm]

@serhiy-storchaka pointed out in the linked mailing list thread that there is an existing way to do this in the standard library:

>>> import json
>>> from types import SimpleNamespace
>>> data = '{"foo": {"bar": "val"}}'
>>> obj = json.loads(data, object_hook=lambda x: SimpleNamespace(**x))
>>> obj.foo.bar
'val'

This doesn't require any new type of object that combines attribute and item access into the same thing; instead, it explicitly declares that you want to represent each JSON object as a SimpleNamespace (which has no methods to conflict with data members) and use attribute access (only).

He also pointed out that making this pattern simpler to use (no lambda) does not require making SimpleNamespace expose the full mapping API (as proposed in https://bugs.python.org/issue40284), it would just require adding support for SimpleNamespace constructor to take a single positional mapping argument, which is a small change.

Not sure why those suggestions were ignored at the time, but they seem preferable to adding a new type that mixes attribute and item access.

[ambv]

Given that the PR was created on a Saturday and merged the following Tuesday in August, which is generally a time of lower activity for us, I'm inclined to postpone this addition until we gather more consensus.

The idea isn't new but there's always some edge cases that made the feature controversial to endorse within the standard library. I concur that it's not obvious agreement was reached on this. +1 to reverting.

[erlend-aasland]

Perhaps it would be better fit as a "recipe" in the JSON documentation, for example using Serhiy's suggestion.