The fact ``dict`` is a mutable object makes this PEP very complicated.
Let's say we have this example:
x = {'a': 1, 'b': 2, 'c': {'c': 3}}
y = {'d': 4, 'c': {'c': 5}}
If we were to merge the two dicts together, such as:
x.update(y)
Then we expect ``y`` to have been updated and look like:
{'a': 1, 'b': 2, 'c': {'c': 5}, 'd': 4}
``x['c']`` is now the same object of ``y['c']`` and any updates to
either is reflected on the other.
Now if we have ``z = x + y``. Should ``z`` be a new shallow copy? Deep
copy? Or completely new dict with no references to neither ``x`` or
``y``?
If we limit the merge operator to ``inplace`` update, then we could have
two options, ``update`` and ``deepupdate``.
``x < y`` => x.update(y)
``x > y`` => y.update(x)
``y << x`` => deepupdate(x, y)
``x >> y`` => deepupdate(y, x)
Alex Martelli has an implementation of ``deepupdate`` on
https://stackoverflow.com/a/3233356/360362
I think supporting ``z = x op y`` on dicts without thinking carefully
about mutability and references will just add a new section to the
python gotchas.
Meitham On 10/21, brian.sk...@gmail.com wrote: > **Strongly** disagree. I would anticipate using this feature a LOT, and would > be excited to see it added. (I would love to replace things like "d2 = > d1.copy(); d2.update(d3)" with just "d2 = d1 | d3". In-place "d2 |= d3" is > nice in its terseness, but isn't a huge benefit.) But, I completely agree > with the arguments in favor of using "|" from the semantic perspective of the > operation being much more like a set operation, than a list operation. > > Further: One angle I don't think I've read from anyone yet (still catching up > on the thread tho) is the question of the obscurity of "|" vs the commonality > of "+", and how they would likely interact with newcomers. A newcomer is > likely going to use "+" a LOT, in all sorts of different situations. Given > how non-intuitive dict merging can be, I would rather 'd1 + d2' throw a > TypeError than return something unexpected. The more-obscure 'd1 | d2' is > likely only going to be used by people who know how the machinery works and > go searching for a more concise idiom, and who thus are less likely to be > surprised by how it works. > > -Brian > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/JXY3VH3UMVLOXRNDQNKDQDRIWJKISSEU/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Meitham Jamaa http://meitham.com GPG Fingerprint: 8C8E3FC7
signature.asc
Description: PGP signature
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HCCIG47U3CTOGCZNEI4ETRREKYGEBZBM/ Code of Conduct: http://python.org/psf/codeofconduct/
