On Sun, Oct 20, 2019 at 11:29:54PM -0000, Dominik Vilsmeier wrote:
The question is, why would someone who has experience with adding counters but never felt the need to add dicts, assume that this behavior is specialized in `Counter` and not inherited by `dict`.
I think you might mean inherited *from* dict? dict doesn't inherit Counter's behaviour because Counter is the subclass and dict the parent class.
Maybe at some point they'll encounter a scenario where they need to recursive-merge (the `Counter` style) two dicts and then they might assume that they just need to add the dicts
Okay. So what? If they do this, it will be a mistake. Programmers make mistakes thousands of times a day, it is neither our responsibility nor within our power to prevent them all. Programmer error is not a good reason to reject a feature.
since they're familiar with this behavior from `Counter` and `Counter` subclasses `dict` so it's reasonable to assume this behavior is inherited.
No it isn't reasonable. Counters are designed to *count*. Their values are supposed to be ints, usually positive ints. dicts are general key:value stores where the values can be any kind of object at all, not just numbers or even strings. Most objects don't support addition. It is totally unreasonable to assume that dict addition will add values by default when by default, objects cannot be added.
how obvious is the conclusion that dict performs a shallow merge and resolves conflicting keys by giving precedence to the r.h.s. operand?
About as obvious that update performs a shallow merge and resolves duplicate keys by giving precedence to the last seen value. -- Steven