My first gut reaction: if you find yourself reaching for glom, refactor your data into something simpler so you don’t have to use it.
I mean sure, there are some domains and use cases where it could be warranted, but the page tries too hard to sell it as a long-needed solution for a ubiquitous problem. Which it isn’t.
It would be nice to refactor things to be simpler, but sometimes we have to work with other people’s data. For my job, I have to make a lot of API calls to deeply nested data. This tool seems like it could be useful.
Yep, I’m looking forward to trying this tool with some JSON-serialized Java objects I have to deal with from a 3rd party API (yes it is as bad as it sounds).
Maybe I’ve just been unlucky with the data I’ve worked with, but LinkedIn, Facebook, GitHub, Wikipedia, Twitter, and PayPal’s APIs (especially the midtier/internal ones) are all exceedingly nested. Could just be my experience, but nested data seems pretty ubiquitous to me!
You forgot to point out that Python provides a traceback:
Traceback (most recent call last):
File "smalldemo.py", line 17, in <module>
main()
File "smalldemo.py", line 8, in main
bar(target)
File "smalldemo.py", line 11, in bar
foo(target)
File "smalldemo.py", line 14, in foo
value = target.a['b']['c']
KeyError: 'b'
And the varying error messages it gives is enough to pinpoint which one of these operations failed.
It looks like a good exercise project though. Someone saw time to work out the documentation and it didn’t fail entirely explaining what this thing is doing. Good exercise especially for the purposes of explaining what’s the purpose of that thing. It can get tricky.
EDIT I just realized that you were referring to the author’s statement about which dict get is causing the error. My statement below is not relevant to that.
The traceback is good, but if you are getting lots of deeply nested json documents some fields might be present on one document and not on another within the same collection. So you end up in this loop where you process a piece of the collection, hit an exception, stop and fix it. Repeat this a while until you think the code is stable. Then at some point in the future you end up with another piece of a new collection that blows up. C’est la vie.
Trust me, no forgetfulness occurred here. If 'b' and 'c' were variables, which they commonly are, you wouldn’t know which one had the value which caused the KeyError. And furthermore, the example was more about the TypeErrors, such as the one raised when a dictionary is replaced with a list.
The traceback sheds no light on that. The only way to make the traceback work is to split up the operation into multiple lines, and that’s why that code ends up verbose and un-Pythonic.
My first gut reaction: if you find yourself reaching for
glom, refactor your data into something simpler so you don’t have to use it.I mean sure, there are some domains and use cases where it could be warranted, but the page tries too hard to sell it as a long-needed solution for a ubiquitous problem. Which it isn’t.
It would be nice to refactor things to be simpler, but sometimes we have to work with other people’s data. For my job, I have to make a lot of API calls to deeply nested data. This tool seems like it could be useful.
Yep, I’m looking forward to trying this tool with some JSON-serialized Java objects I have to deal with from a 3rd party API (yes it is as bad as it sounds).
Maybe I’ve just been unlucky with the data I’ve worked with, but LinkedIn, Facebook, GitHub, Wikipedia, Twitter, and PayPal’s APIs (especially the midtier/internal ones) are all exceedingly nested. Could just be my experience, but nested data seems pretty ubiquitous to me!
It’s worth taking a look at the author’s projects page, it’s a treasure trove of well engineered Python modules.
Thanks! In fact, this comment led me to update it. Long overdue, it has over 20 projects now: http://sedimental.org/open_source_projects.html :)
You forgot to point out that Python provides a traceback:
And the varying error messages it gives is enough to pinpoint which one of these operations failed.
It looks like a good exercise project though. Someone saw time to work out the documentation and it didn’t fail entirely explaining what this thing is doing. Good exercise especially for the purposes of explaining what’s the purpose of that thing. It can get tricky.
EDIT I just realized that you were referring to the author’s statement about which dict get is causing the error. My statement below is not relevant to that.
The traceback is good, but if you are getting lots of deeply nested json documents some fields might be present on one document and not on another within the same collection. So you end up in this loop where you process a piece of the collection, hit an exception, stop and fix it. Repeat this a while until you think the code is stable. Then at some point in the future you end up with another piece of a new collection that blows up. C’est la vie.
Trust me, no forgetfulness occurred here. If
'b'and'c'were variables, which they commonly are, you wouldn’t know which one had the value which caused the KeyError. And furthermore, the example was more about the TypeErrors, such as the one raised when a dictionary is replaced with a list.The traceback sheds no light on that. The only way to make the traceback work is to split up the operation into multiple lines, and that’s why that code ends up verbose and un-Pythonic.