On Mon, Apr 20, 2020 at 12:17 PM Andrew Barnert <abarnert@yahoo.com> wrote:
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.

Well, sure. Though JSON itself is declarative data.

In Python, you need to decide how you want to work with it, either as an object with attributes or a dict. But if you are getting it from JSON, it's a dict to begin with. So you can keep it as a dict, or populate an object with it. B ut populating that object can be automated:

an_instance = MyObject(**the_dict_from_JSON)

And then:


It's not always that simple, but you sure shouldn't have to do anything like:

name = the_dict_from_JSON['name']

Which is what I'm getting at:

why are all those ever variables in a current namespace? it may be worth rethinking.


> 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.

only if you have those as local variables -- why are they ?

I'm not saying it never comes up in well designed code -- it sure does, but if there's a LOT of that, then maybe some refactoring is in order.

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython