I wouldn't have thought about dict unpacking as a solution either but once suggested it seems satisfactory and I don't see how adding a new operator is more discoverable or natural than just putting this method in a more prominent place in the documentation.
Dictionary union (PEP 584) is merged
11–20 of 87 posts
Re: Dictionary union (PEP 584) is merged
#12I wouldn't have thought about dict unpacking as a solution either but once suggested it seems satisfactory and I don't see how adding a new operator is more discoverable or natural than just putting this method in a more prominent place in the documentation.
It mentions in the PEP discussion that the { a, b} trick only works for string keys. So it isn't applicable in as many cases as the new operator.
dict(d1, **d2)
only works with string keys {**d1,**d2} or dict({**d1,**d2})
works with all key types it seemsRe: Dictionary union (PEP 584) is merged
#13I wouldn't have thought about dict unpacking as a solution either but once suggested it seems satisfactory and I don't see how adding a new operator is more discoverable or natural than just putting this method in a more prominent place in the documentation.
It mentions in the PEP discussion that the { a, b} trick only works for string keys. So it isn't applicable in as many cases as the new operator.
dict(d1, **d2)
has that problem. it works fine if you unpack into a dict literal: >>> d1 = {1: 'a'}
>>> d2 = {2: 'b'}
>>> {**d1, **d2}
{1: 'a', 2: 'b'}
iirc the pep mostly just says that it's suboptimal because it's syntactically heavy/noisy, non-obvious and can't be overloaded in dict subclasses---
i was curious why the two double-stars behave differently despite syntactic similarity. so i went and checked the bytecode, and it turns out they compile down to different opcodes! `{××d1, ××d2}` yields a BUILD_MAP_UNPACK, while `dict(d1, ××d2)` yields a CALL_FUNCTION_EX/CALL_FUNCTION_KW (depending on the CPython version)
Re: Dictionary union (PEP 584) is merged
#14Yay! I was wishing for this feature just a few days ago. It's somewhat analogous to how sorted (since Python 2.4) frees us from having to tediously make copies of lists to sort them in place.
{**d1, **d2}
today for the same effect.Re: Dictionary union (PEP 584) is merged
#15{**d1, **d2} is very natural if you also write javascript where their spread operator looks like: {...d1, ...d2}
Re: Dictionary union (PEP 584) is merged
#16Re: Dictionary union (PEP 584) is merged
#17The PEP document describing the feature: https://www.python.org/dev/peps/pep-0584/
> > Dict union will violate the Only One Way koan from the Zen. > There is no such koan. "Only One Way" is a calumny about Python originating long ago from the Perl community.
> There should be one-- and preferably only one --obvious way to do it.
Personally, I’ve always thought that Python missed its Zen, both here and on “explicit is better than implicit.”
Re: Dictionary union (PEP 584) is merged
#18Yay! I was wishing for this feature just a few days ago. It's somewhat analogous to how sorted (since Python 2.4) frees us from having to tediously make copies of lists to sort them in place.
You can already do {**d1, **d2} today for the same effect.
Note that the method you show is slightly different for cases of dict subclasses.
The PEP notes the difference: https://www.python.org/dev/peps/pep-0584/#d1-d2.
Re: Dictionary union (PEP 584) is merged
#19The PEP document describing the feature: https://www.python.org/dev/peps/pep-0584/
> > Dict union will violate the Only One Way koan from the Zen. > There is no such koan. "Only One Way" is a calumny about Python originating long ago from the Perl community.
Re: Dictionary union (PEP 584) is merged
#20Earlier quoted context omitted.
> > Dict union will violate the Only One Way koan from the Zen. > There is no such koan. "Only One Way" is a calumny about Python originating long ago from the Perl community.
That ship had long sailed with string formatting anyways.