A very long time ago, I wrote an XML library (Gnosis Utilities xml_objectify) that had this same issue, and adopted the "duality" approach (where possible, with both dictionary and other styles also available). JSON is sort of the new XML, and it feels like the same concern. FWIW, LXML explicitly adopted my approach for an optional (mostly) compatible mode, and unlike me, they maintained that thing during the last 15 years since mine was touched.
I think the way to think about parsing JSON needn't be "this is just a Python dictionary once we read it", but rather that we have a custom dict-like object that borrows JSON/Javascript semantics. I've mentioned that I think a new name emphasizes this. And living in `collections` rather than `types` also fits this purpose better.
However we get there, writing `obj.element.sub.another` is SO MUCH nicer.
On Wed, Apr 15, 2020 at 11:01 AM Paul Moore p.f.moore@gmail.com wrote:
On Wed, 15 Apr 2020 at 15:41, Brett Cannon brett@python.org wrote:
The "hey I'm a dict, but look over hear and now you can treat my like
like any other object" duality doesn't sit well with me. I do understand the idea of wanting to convert something to convert JSON data into a more object-like access pattern, though.
I don't like the duality, but I *do* like (in some situations) the object-with-dynamic-attributes style of access. Basically, when access is predominantly via literal strings and heavily nested,
obj["element"]["sub"]["another"]is *far* more punctuation-heavy and (IMO) difficult to read as a consequence, than
obj.element.sub.anotherPaul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RZQG5BIY... Code of Conduct: http://python.org/psf/codeofconduct/