18.02.20 19:35, Brandt Bucher пише:
...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.
Yes, but this is a different thing. You *must* to implement new `__or__`
in a subclass to make the behavior of `d1 | d2` be different from
`{**d1, **d2}`. Actually, there was already an example -- Counter.
It is not an argument for implementing `__or__` in dict. It is an
argument for implementing `__or__` in other classes. So to add a value
to it you have to look at from from the opposite side: you want an
operation for merging OrderedDict, defaultdict, etc and add
`dict.__or__` just for symmetry, even if it is not actually necessary
for dicts.
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.
Agree, the current code makes easier to implement such operations in
other mapping classes.
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.
Let's take a closer look at these examples. Unfortunately the PEP does
not provide links to the original code, so the context is not always known.
IPython/zmq/ipkernel.py
IPython/zmq/kernelapp.py
matplotlib/delaunay/triangulate.py
numpy/ma/core.py
praw/internal.py
pygments/lexer.py
sphinx/highlighting.py
sphinx/quickstart.py
sympy/abc.py
sympy/parsing/maxima.py
sympy/printing/ccode.py and sympy/printing/fcode.py
In almost all examples it is guaranteed that the result is a dict. You
create a dict by calling dict() or using dict display and then update
it. So the form `{**d1, **d2}` can be used in all these cases.
In some examples, like in praw/internal.py, it may be especially good:
data = {'name': six.text_type(user), 'type': relationship, **kwargs}
In some cases, like in sympy/abc.py the proposed transformation is just
not correct if arguments have overridden `__or__`. Currently it is
guaranteed that the result is a dict, but with proposed code it is no
longer true.
matplotlib/legend.py
sphinx/domains/__init__.py
sphinx/ext/doctest.py
sphinx/ext/inheritance_diagram.py
In these cases you merge a user provided dict with some default value
which is a dict by default, but may be overridden in subclasses.
Although it is unlikely.
matplotlib/backends/backend_svg.py
The current code uses `{**attrib, **extra}`.
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_svg.py#L155
requests/sessions.py
The proposed transformation makes the code less efficient -- it makes
redundant copying.
sympy/utilities/runtests.py
Sorry, but the current code
globs = globs.copy()
if extraglobs is not None:
globs.update(extraglobs)
looks much clearer to me than the proposed
globs = globs | (extraglobs if extraglobs is not None else {})
_______________________________________________
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/V6HCC6F2EQZTZ5JKPPMWFJNYO6HNGTJY/
Code of Conduct: http://python.org/psf/codeofconduct/
