A month ago I promised the Steering Council I'd review PEP 584 and promptly got distracted by other things. But here it is, at last.
Some procedural things first: you (the PEP authors) should apply to the Steering Council for a formal review. They most likely will assign one of the SC members as a BDFL-Delegate who will guide the PEP to a resolution (either acceptance or rejection, after any number of revisions). Don't wait until you think the PEP is perfect! It doesn't have to be for a BDFL-Delegate to be assigned.
Note that the SC elections have just started, and in a few weeks we'll have a new SC. I won't be in it (I withdrew from the ballot). I don't know how this will affect the chances of this PEP. (Also note that after an election, a SC can overturn decisions by the previous SC, so I don't mean this as a reason to hurry -- just something to consider.)
Now to the content of PEP 584.
## Should the operators be + and +=, or | and |= ?
I haven't read _all_ the posts on this topic, but I've seen quite a few, and I still strongly favor | and |= . My reason for this is mainly that the operation really does do a set union **on the keys**.
Also, + is already overloaded enough (numbers, strings, sequences) and we don't need yet another, different meaning. The | operator should be known to most users from sets (which are introduced before dicts in the official Python tutorial).
I don't particularly care about learnability or discoverability in this case -- I don't think beginners should be taught these operators as a major tool in their toolbox (let them use .update()), and for anyone wondering how to do something with a dict without access to the official docs, there's always help(dict). The natural way of discovering these would be through tutorials, reading of the library docs, or by reading other people's code, not by trying random key combinations in the REPL.
## Does it matter that the operation is lossy, and not commutative in the values?
Centithreads have been wasted on this topic, and I really don't care. I **certainly** don't think that introducing a new operator or using a different operator (<<, really?) is needed because of the operator's asymmetry. A tutorial can show this in two or three lines, and anybody who remembers these operators exists but has forgotten how they handle conflicting values (and doesn't remember they correspond to.update()) can type one line in the REPL to figure it out:
>>> {"a": 1} | {"a": 2}
{"a": 2}
>>>
## What about the Counter class?
The Counter class is an over-engineered contraption that has way too many APIs to remember, and is quite inconsistent in what it tries to be. (When does it delete zeros? Why does it sometimes discard negative values?) We should not use it for guidance nor should we feel constrained by its design.
## What about performance?
Performance is not the only objective when using Python. Switching to inplace operators (here |=) is a generally useful and well-known technique (it also applies to string and list concatenation, for example).
## Other objections
The PEP does a good job of addressing pretty much everything that's been brought up against it (in fact, perhaps it goes a little too far in humoring obvious strawmen).
## Open questions
There's only one left in the PEP: "Should these operators be part of the ABC Mapping API?"
No. This would require every Mapping implementation to add these. While you might think that this could be addressed by adding concrete implementations in the Mapping ABC, that doesn't work for |, since there's no API for creating new instances.
It could be done for |=, by adding this to MutableMapping:
def __ior__(self, other):
self.update(other)
but without the ability to define __or__ in Mapping this seems inconsistent. Mapping implementations are of course free to define __or__.
All in all I would recommend to the SC to go forward with this proposal, targeting Python 3.9, assuming the operators are changed to | and |=, and the PEP is brought more in line with the PEP editing guidelines from PEP 1 and PEP 12. (In particular, there are some suggested section headings there that ought to be followed more closely. I'd be glad to give the authors more guidance in this matter if they request it.)