Dict Unpacking in Python

(github.com)

122 points _ZeD_ | 4 comments | 08 Jul 25 16:05 UTC | HN request time: 0.633s | 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]▶

>>44538027 #

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]▶

>>44538627 #

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]▶

>>44538710 #

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 #

1. IgorPartola ◴[12 Jul 25 13:08 UTC] No.44541813[source]▶

>>44539624 #

The |= does exactly what it says on the tin. How could it not mutate the left side of the assignment?

replies(2): >>44542549 #>>44542850 #

2. parpfish ◴[12 Jul 25 15:04 UTC] No.44542549[source]▶

>>44541813 (TP) #

In typed languages, I’m all about using nice safe immutable variables/values.

But in python, everything is mutable so there’s only so much safety you can wring out of adhering the an immutable style. Any other function can hop in and start mutating things (even your “private” attributes). Plan for mutations occurring everywhere.

replies(1): >>44543051 #

3. masklinn ◴[12 Jul 25 15:43 UTC] No.44542850[source]▶

>>44541813 (TP) #

> 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},)

4. graemep ◴[12 Jul 25 16:15 UTC] No.44543051[source]▶

>>44542549 #

I find the fewer mutations the easier code is to understand, at the level of an individual function.

Of course you do not have the safety you would have in a language that enforces immutability, but there is still a cost (in terms of maintenance and the likelihood of bugs) to mutation.

↑