
I am accepting this PEP. Congratulations Steven and Brandt!
Thank you for your guidance, especially the suggestions late last year. And thanks Steven for taking me on as a co-author and shaping the bulk of the proposal.
Hm, the PEP should probably also link to that PR rather than to Brandt's private branch.
Agreed. This can probably be changed when the status is updated. Now, addressing Serhiy's points :)...
...it was decided that `d1 | d2` also should ignore the types of the operands and always return a dict. And it accepts only dicts, not general mappings, in difference to `{**d1, **d2}`. So the only disadvantage of `{**d1, **d2}` is that it is not well known and "looks ugly".
Not quite. While this point *has* been weakened a bit with the recent semantic change, you don't mention that `dict` subclasses can (and likely would) override the `__or__` trio with wrapped `super()` calls. So while `{**d1, **d2}` will *never* be anything but a `dict`, I can trust that well-written `dict` subclasses my code encounters will still be able to preserve themselves with `d1 | d2`, if desired.
The pure-Python implementation of the non-inplace operator can be simpler if use dict unpacking.
The purpose of the pure-Python implementation in the PEP is to be a clear, understandable example that serves as a codification of the semantics, not to be the shortest one-liner. The suggested changes make the code less readable, making it harder to see exactly what will happen if I do `self | other`. I'm against changing it, for that reason.
I suggest to include to objections that non-inplace merging of two dicts is much less common operation than concatenating of two strings or other sequences, and that the existing syntax {**d1, **d2} completely satisfies the need.
This is really two objections. Regarding the commonality of this operation, we've provided eighteen detailed examples of third-party library code that are candidates for these new operators. To the best of my knowledge, a large survey like this is unprecedented in a PEP. Whether or not it is more common than a different operation on other types isn't relevant here. We have gone above and beyond in demonstrating the use cases in detail. A rewording of your second objection has already been addressed: https://www.python.org/dev/peps/pep-0584/#more-than-one-way-to-do-it I feel that I've adequately responded to the other points you've raised here in this email (please let me know if I missed anything, and perhaps Steven may want to chime in as well). I don't know what the policy for changing the PEP is once it's gotten to this stage, but it's already grown to a huge size in its attempts to address every possible concern that has arisen over the past year (even some that, in my opinion, weren't serious proposals that needed to be acknowledged). I'd prefer not to bloat it even more this late in the game, if at all possible.