On Thu, Oct 17, 2019 at 7:35 AM Brandt Bucher <brandtbucher@gmail.com> wrote:

Please let us know what you think – we'd love to hear any *new* feedback that hasn't yet been addressed in the PEP or the related discussions it links to! We plan on updating the PEP at least once more before review.

I, personally, do not feel a need to have an operator alternative to an 'update' function, because I believe the 'update' function is pretty self-explanatory: It has certain "cognitive property" (i.e. one can conclude what type of objects it applies to), it also explicitly identifies the way the operation applies.

But if someone needs an operator for that, I propose to introduce a different symbol, while considering some similarities in the (Python) language already. On the abstract level, the operation described in the PEP looks more like set union (on dict keys) than anything else using concatenation (not considering "arithmetic" meaning of '+' here). The problem with union is that it is commutative, while the proposed dict '+' is not, so let's imagine a new operator '|<' (and optionally '|>', or '|<=' for the '+=' version) and use it like this

```

a = dict(...)

b = dict(...)

c = a |< b

```

The consequences (and the differences to the original proposal):

1) The operator (visually) looks like set union but not quite and is self-explanatory.

2) The operator is unique enough it could suggest that 'a' and 'b' are dicts (the same way 'update' does and not the other way around - the object type being used to deduce the operator meaning).

2) Anyone finding this in the code, who does not now about the operator, will _not_ guess the wrong operation.

I know this has been somewhat addressed in PEP, but I simply cannot see, how adding another ambiguity to the '+' symbol, can be better, because the "familiarity" of '+' (which seems to me being an argument in the PEP) just hides the fundamental differences between this '+' and the other ones (arithmetic, or concatenation).

Richard