Re:Dictionary union (PEP 584) is merged
by seemslegit on Tuesday February 25, 2020 @05:27PM
(#22418182)
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.
[ Parent
| on HN ]
Guido himself said he had forgotten about this trick and since it's syntactic sugar, it does not respect dict subclasses or other mappings.
Re:Dictionary union (PEP 584) is merged
by seemslegit on Tuesday February 25, 2020 @05:53PM
(#22418405)
imo
defaultdict(callback,{**a,**b})
is more readable than a | b without knowing that a or b are defaultdicts and having to reason about which default callback will be usedIt’s also really expensive. This new operator works with any Mapping type without needing silly hacks.
Re:Dictionary union (PEP 584) is merged
by anonymoushn on Tuesday February 25, 2020 @10:19PM
(#22419983)
Note that a | b is already a disaster if you try to use subclasses of set. In python 2.7, iirc it would return a set of a's type but without calling the constructor. In python 3 it seems to return a set (not the type of a or the type of b).
Re:Dictionary union (PEP 584) is merged
by CameronNemo on Tuesday February 25, 2020 @11:29PM
(#22420280)
Not sure about the set operator, but this operator is meant to handle subclasses better than the status quo.
Re:Dictionary union (PEP 584) is merged
by mdrachuk on Wednesday February 26, 2020 @12:55AM
(#22420664)
Wow, one more point for python 3.
Just override ‘__and__’ in your whatever class to replace default return.
Pretty explicit in my book.
Re:Dictionary union (PEP 584) is merged
by blackandblue on Wednesday February 26, 2020 @07:19AM
(#22422299)
the easy to forget justification is surprising to me. especially when most modern languages have the concept of unpacking, rest, spread or etc.
making the trick work with other mapping types and making it faster is totally understandable though.
Re:Dictionary union (PEP 584) is merged
by banannaise on Thursday February 27, 2020 @03:22PM
(#22437369)
It's pretty obvious with the context of other languages, but wildly outside the norm for Python. I rarely see dict unpacking outside function signatures.
Re:Dictionary union (PEP 584) is merged
by war1025 on Tuesday February 25, 2020 @06:32PM
(#22418712)
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.
actually, only
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
by dahfizz on Tuesday February 25, 2020 @11:13PM
(#22420211)
This seems pretty straightforward. When doing
`dict(d1, d2)`
You are calling the dict function, and using the normal syntax for unpacking a dictionary into kwargs. In this case, the name for kwargs must be strings.
Re:Dictionary union (PEP 584) is merged
by uryga on Wednesday February 26, 2020 @07:19AM
(#22422301)
yeah, that side of the (in)equation was pretty obvious, i was mostly interested in the `{...}` one. i admit that a bytecode listing probably isn't the best exposition, i just like digging into VM stuff :)
Re:Dictionary union (PEP 584) is merged
by seemslegit on Tuesday February 25, 2020 @06:41PM
(#22418771)
dict(d1, **d2)
only works with string keys {**d1,**d2} or dict({**d1,**d2})
works with all key types it seems