Arguments against JSON-driven development

I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently.

Values are different from their memory representations. Different memory representations of the same value are okay. Branching on the difference is not. Of course, to hide representation differences from users, you need abstract data types [0], and, sadly, Python doesn't have these.

[0] https://www.cs.cmu.edu/~rwh/introsml/modules/sigstruct.htm

> If you want to argue that Python ought to change its implementation to guarantee that, for example, any two references to the tuple (1, 2, 3) must refer to the same in-memory representation (so the 'is' operator would always return True), because that would save memory, or make the runtime faster, or whatever, that's fine.

I never said this either. I said that it should be a valid optimization, not that implementations absolutely have to do it. As things stand now, it's not a valid optimization, because it would break existing programs.

In actuality, I don't care much about the optimization itself. However, it's a good benchmark for assessing whether Python has compound values. Values can be deduplicated, because they may be represented more than once. Objects can't be deduplicated, because by definition an object exists exactly once in memory.

> But trying to claim that Python is violating "one of the cornerstones of Western logic" is just too much.

It seems appropriate to me. But, to be clear, what I was claiming violates the indiscernibility of identicals is dragonwriter's explanation, not Python itself. A simple explanation that doesn't violate the indiscernibility of identicals is to admit that Python doesn't have compound values. Which takes us back to square one [1].

[1] https://news.ycombinator.com/item?id=12358968

It argues that loosely defined objects are an excellent design pattern, but I'm too tired to decide if it is directly relevant to this.

  def set_r(adict, keypath, val):
    key = keypath[0]
    if len(keypath) == 1:
      adict[key] = val
      return
    if not key in adict:
      adict[key] = {}
    set_r(adict[key], keypath[1:], val)

  def build_book_inventory(book_ids, shops):
    shop_labels = [shop['label'] for shop in shops]
    books = Persistency_books_table_read(
      shop_labels=shop_labels,
      book_ids=book_ids)
    inventory = {}
    keys = 'shop_label cell_label book_id'.split()
    for book in book_list:
      keypath = [book[k] for k in keys]
      set_r(inventory, keypath, book['count']
    return inventory

Second, I'd avoid creating local variables like "book_id". It creates mess. We never had the slightest interest in the book_id; it's just part of the wine we are pouring from one bottle into another.

Third, I've preserved (modulo names) the interface of this function but I suspect the surrounding code could also be improved. Also call a list of books "books", not book_list; list is the assumed sequence container in Python. "books=book_ids" is unfortunate; to thrive in a weakly typed language we need variable names that distinguish objects from ids.

Larger point: the author wants to create classes for the various business objects, which is a common enough pattern, but ultimately just makes extra work and redundant lines of code. A relational database can handle a wide variety of objects, with some knowledge of their semantics, without any custom code per-class.

As you know, the difference between dicts and objects in python is mostly semantic sugar. We can easily enough make a class that gives dot-notation access to values in a dict, if one objects to the noisiness of foo['bar'].

If you want to enforce object schema at system boundaries, there are better ways (more compact, expressive and maintainable) than writing elaborate "classes" for each type of object.