Thanks everyone for the feedback and suggestions. I agree that there are many ways one could easily implement this (chaining, reduce, looping, etc.). I could continue to maintain a utility function and copy that around to all of code bases where I need this functionality, which is what I do today. I think we could do better, though.
It is cumbersome to update and copy around a common function across organizations and code bases. Then I have to educate the rest of the dev team and tell them that there is a function that facilitates nested key retrievals. Another alternative would be to create a common package for this and update all of my projects to use that. Given that it would be 5-15 lines of code, that feels like it would be too small to be a robust dependency and would smell like some of the minuscule dependencies in the Javascript ecosystem (example: https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/). I really believe that a nested key retrieval mechanism should be a first-class offering of the standard library. It is extremely common in the Python ecosystem to find developers working with data sets comprised of nested data structures. Serializing and deserializing JSON is one of the most common functions developers do today, too. As this is a common task being performed by hundreds of thousands of developers, wouldn't it better if we had one canonical way to do it (in the spirit of PEP-20 and having one obvious way to do things)? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2I7DBVFV7AJEN6XWKC3R7VXWSTJUXGO4/ Code of Conduct: http://python.org/psf/codeofconduct/
