On Tue, 3 Sep 2019 at 13:38, None via Python-ideas
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)?
There's a PyPI package, glom (https://pypi.org/project/glom/) that appears to do what you are after, as well as a lot more. Maybe that is something you should look into. There's obviously a judgement call involved, but "not every 3-line function needs to be a builtin" (or by extension a stdlib function) is a common principle used here. In this case, any individual case is probably a simple 3-line function, but trying to write something flexible enough to cater for all (or even just most) of the endless variations of questions like "should it be an error if a nested item isn't a dictionary, or should that be treated as item not found?" is a significant undertaking, and it's likely difficult to come up with a usable design. So custom implementations, tailored to the needs of individual projects, seems like a good way to go (to me, at least). If someone (like the author of the glom package) finds a more general approach that solves a broad class of problems, making it a package on PyPI is a good next step. And if it turns out that the PyPI package becomes a clear example of "best of breed", and has stabilised to the point where the slow pace of change in the stdlib is acceptable, then it might be worth making into a stdlib function. Yes, it's a common enough requirement, but only in a broad sense (the details seem to differ each time). Paul