> 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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TEC4G6LVTHFL566ELDC4J6S527LI5C37/
Code of Conduct: http://python.org/psf/codeofconduct/
