
On Apr 20, 2020, at 11:01, Christopher Barker <pythonchb@gmail.com> wrote:
The JSON - related example is a good one -- JSON maps well to "data" in Python, dicts and lists of numbers and strings. If you find yourself converting a bunch of variable names to/from JSON, you probably should be simply using a dict, and passing that around anyway.
A lot of JSON is designed to be consumed by JavaScript, where there is no real line (there is no dict type; objects have both dict-style and dot-style access). So in practice, a lot of JSON maps well to data, a lot maps well to objects, and some is mushily designed and doesn’t quite fit either way, because in JS they all look the same anyway. The example code for an API often shows you doing `result.movies[0].title.en`, because in JS you can. And in other languages, sometimes it is worth writing (or auto-generating) the code for Movie, etc. classes and serializing them to/from JSON so you can do the same. This is really the same point as “sometimes ORMs are useful”, which I don’t think is that controversial. But, maybe even more importantly: even if you _do_ decide it makes more sense to stick to data for this API, you have the parallel `{'country': country, 'year': year}` issue, which is just as repetitive and verbose. The `{::country, ::year}` syntax obviously solves that dict key issue just as easily as it does for keywords. But most of the other variant proposals solve it at least indirectly via dict constructor calls—`dict(**, country, year)`, `dict(country=, year=)`, `dict(**{country, year})`, which isn’t quite as beautiful, but is still better than repeating yourself if the list of members or query conditions gets long.