←back to thread

Dict Unpacking in Python

(github.com)
133 points _ZeD_ | 2 comments | 08 Jul 25 16:05 UTC | HN request time: 0.413s | source
Show context
zelphirkalt ◴[11 Jul 25 23:57 UTC] No.44538027[source]▶
I found dictionary unpacking to be quite useful, when you don't want to mutate things. Code like:

    new_dict = {**old_dict, **update_keys_and_values_dict}
Or even complexer:

    new_dict = {
        **old_dict,
        **{
            key: val
            for key, val in update_keys_and_values_dict
            if key not in some_other_dict
        }
    }
It is quite flexible.
replies(1): >>44538627 #
peter422 ◴[12 Jul 25 01:50 UTC] No.44538627[source]▶
I love the union syntax in 3.9+:

  new_dict = old_dict | update_keys_and_values_dict
replies(1): >>44538710 #
parpfish ◴[12 Jul 25 02:10 UTC] No.44538710[source]▶
Don’t forget the in place variant!

  the_dict |= update_keys_and_values_dict
replies(1): >>44539624 #
masklinn ◴[12 Jul 25 05:45 UTC] No.44539624[source]▶
No no, do forget about it: like += for lists, |= mutates “the dict”, which often makes for awkward bugs.

And like += over list.extend, |= over dict.update is very little gain, and restricts legal locations (augmented assignments are statements, method calls are expressions even if they return "nothing")

replies(1): >>44541813 #
IgorPartola ◴[12 Jul 25 13:08 UTC] No.44541813[source]▶
The |= does exactly what it says on the tin. How could it not mutate the left side of the assignment?
replies(2): >>44542549 #>>44542850 #
1. masklinn ◴[12 Jul 25 15:43 UTC] No.44542850[source]▶
> The |= does exactly what it says on the tin. How could it not mutate the left side of the assignment?

The normal way? If the LHS is an integer. |= updates the binding but does not mutate the object.

Nothing requires that |= mutate the LHS let alone do so unconditionally (e.g. it could update the LHS in place as an optimisation iff the refcount indicated that was the only reference, which would optimise the case where you create a local then update it in multiple steps, but would avoid unwittingly updating a parameter in-place).

edit: you might not be understanding what dict.__ior__ is doing:

  >>> a = b = {}
  >>> c = {1: 2}
  >>> b |= c
  >>> a
  {1: 2}
That is, `a |= b` does not merely desugar to `a = a | b`, dict.__ior__ does a `self.update(other)` internally before updating the binding to its existing value. Which also leads to this fun bit of trivial (most known from list.__iadd__ but "working" just as well here):

  >>> t = ({},)
  >>> t[0] |= {1: 2}
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: 'tuple' object does not support item assignment
  >>> t
  ({1: 2},)
replies(1): >>44546045 #
2. dumah ◴[12 Jul 25 23:16 UTC] No.44546045[source]▶
That’s not “the normal way”, it’s just the case when the LHS is immutable.

This behavior is congruent to C++ and it’s documented and idiomatic.

It’d be weird if the in-place operator deeply copied the LHS, and problematic for a garbage-collected language in high throughput applications.