Revert "GH-96145: Add AttrDict to JSON module for use with object_hook (#96146)" by ambv · Pull Request #105948 · python/cpython

the implementation has some issues

Please elaborate. This is the simplest possible implementation that meets the spec of being fully substitutable for a regular dict while allowing optional attribute access for all valid identifiers that aren't keywords or dict methods. The implementation is pretty much unchanged since introduced by Martelli twenty years ago and is the usual recipe that people have been using in practice.

While it is possible to contrive a funky case like Jelle's pop example, this seems to never arise in practice. People who wrangle data for living will benefit by having this option for JSON's object hook. It greatly improves the readability of data access code in much the same way as dataclasses, namedtuple, Enum, Panda's dataframes, and SimpleNamespace.

I would support marking this as provisional to leave wiggle room for dealing with Jelle's pop example, but I think the feature should not be reverted. The code is immediately usable and will be of great service to the data wranglers who deal with heavily nested JSON. If you all decide to take this code out, I predict that this will never get done and will be gone forever. Our users won't get to have nice things.

We've already has two decades of people reinventing this for the own projects, so it is not doing to mature much from here. Also, the people like CAM Gerlack who fundamentally oppose this programming practice data will likely never change their minds despite the successes of dataclasses, SimpleNamespace, and argparse.Namespace. ISTM those folks have never personally felt the pain of using chains of square brackets and quotes for lookups into known schemas, nor suffered the consequent readability issues (but acknowledge that I can't really know what is in their minds).

I vote for shipping it as-is, or perhaps marking this a provisional , or perhaps adding a note that the handling of d.pop and friends is subject to change. In the end, no matter how much discussion you want to have, the core functionality will remain very close to what we have now. Flat-out reverting this is likely to just kill the idea forever (I have lost the spirit and energy for pursuing this further).