Skip to main content

Timeline for How do I merge two dictionaries in a single expression in Python?

Current License: CC BY-SA 4.0

81 events
when toggle format what by license comment
Dec 10, 2022 at 3:52 comment added theYnot Nice comprehensive answer - should be using this as an example
Nov 7, 2022 at 17:58 comment added keithpjolley my "sigh" is that copying {'foo': {'bar': 'blah'}} takes 29 times longer than {'foo': 'bar', 'bar': 'blah'}
Nov 6, 2022 at 23:25 comment added Aaron Hall♦ @keithpjolley - I think you understand, but for others who might come along later: dict_of_dicts_merge is slower because it's a recursive deep copy, so the comparison is a bit unfair.
Nov 5, 2022 at 15:35 comment added keithpjolley having to use 3.6 and need the deep copy. for the, if that, one other person interested, the dict_of_dicts_merge() function took 29 times longer than {**x, **y}. sigh.
Mar 29, 2022 at 10:49 history edited Mateen Ulhaq CC BY-SA 4.0
Reword to separate "`x` and `y`, `z`" for clarity. Also make title format to one line.
Aug 11, 2021 at 5:01 comment added Stof x | y is confusing to read, as @ysth explained it is counter-intuitive. I prefer x |= y which is going to mutate x with new values from y and reads far clearer!
S Jul 20, 2021 at 9:33 history suggested user16442705 CC BY-SA 4.0
Formatting, minor tweaks
Jul 19, 2021 at 16:20 review Suggested edits
S Jul 20, 2021 at 9:33
Jun 18, 2021 at 15:34 comment added Thorbjørn Ravn Andersen I think that the requirement of "single-line" should give way to the clarity given by the two line "copy + update". This will be readable to almost all, where the more concise syntax require intimate knowledge of semantics.
Mar 19, 2021 at 21:17 review Suggested edits
Mar 24, 2021 at 6:59
Feb 16, 2021 at 22:12 review Suggested edits
Feb 17, 2021 at 2:29
Dec 18, 2020 at 13:57 history edited Aaron Hall♦ CC BY-SA 4.0
probably shouldn't be fixing grammar on quotes, but in this case, the grammar fix was wrong, it is "the fact... is" not "the fact... are".
S Dec 18, 2020 at 13:55 history suggested Samuel Sorial CC BY-SA 4.0
Grammar improvements
Dec 17, 2020 at 20:07 review Suggested edits
S Dec 18, 2020 at 13:55
S Dec 9, 2020 at 14:10 history suggested Alonme CC BY-SA 4.0
Move newest version to be the first - as it should be the preferred way
Dec 9, 2020 at 11:01 review Suggested edits
S Dec 9, 2020 at 14:10
Nov 3, 2020 at 4:27 comment added ysth huh; I would have expected x | y to be like {**y, **x}, not {**x, **y}
S Oct 18, 2020 at 14:00 history suggested quassy CC BY-SA 4.0
Python 3.9 is released by now
Oct 18, 2020 at 9:37 review Suggested edits
S Oct 18, 2020 at 14:00
Oct 9, 2020 at 21:22 comment added Vedran Šego @AleksandrPanzin, I said "I cannot see why [you'd want double keys in a single dict definition]". Of course you'd want proper updates between multiple dictionaries, but I don't see the purpose inside a single definition (like two "a" keys in my example).
Oct 9, 2020 at 18:19 comment added Aleksandr Panzin @VedranŠego - There's a lot of cases where you would prefer to override. As an example - hieratical value setup. You have your base config in dictionary and overrides coming from a different dict. Doing copy & update works, but that's inconsistent API design. list+list work.... while dict+dict doesn't.
Sep 8, 2020 at 15:04 comment added Vedran Šego Wow! That's a thorough answer. One minor comment, though: "the intended usage for dict(**y) is for creating dictionaries for readability purposes". I would argue that it's also to make the code less error prone, because dict(a=17, b=19, a=23) would fail with "SyntaxError: keyword argument repeated", while {"a": 17, "b": 19, "a": 23} would not (with 23 overwriting 17) and your accidental double key "a" would've gone unnoticed. Of course, if you want to allow double keys (I cannot see why, though), then {...} syntax is the way to go. Many linters, of course, warn of double keys.
Aug 29, 2020 at 2:31 comment added Aaron Hall♦ While possible, that's using the "new way" except for lists instead of dictionaries - I'm not going to suggest people are doing something we have no evidence they're doing that is clearly suboptimal... you could do even more things that are suboptimal, so I'm not going to introduce the idea.
Aug 29, 2020 at 0:43 comment added superb rain @AaronHall With fresh new benchmarks, thanks :-). You have another dict((k, v) ...) a bit higher in your post, btw. And I just thought of another solution that I think hasn't been mentioned yet: dict([*x.items(), *y.items()]). It's a bit slower for me than the chain one.
Aug 29, 2020 at 0:08 history edited Aaron Hall♦ CC BY-SA 4.0
format with fences, improve copy-pasteability, update a bit of Python 2 specific code, remove Python 2 specific performance analysis, update perf analysis for 3.8
Aug 28, 2020 at 22:56 comment added superb rain What x and y did you use in the benchmarks? And I find dict((k, v) ... for k, v in d.items()) somewhat clumsy and artificially inefficient. No need to unpack and repack every item. I think it should be dict(item ... for item in d.items()).
Jul 31, 2020 at 1:53 comment added Aaron Hall♦ Here's the expected release schedule: python.org/dev/peps/pep-0596
Jul 4, 2020 at 14:58 review Suggested edits
Jul 5, 2020 at 1:36
Jun 27, 2020 at 9:02 review Suggested edits
Jun 27, 2020 at 11:54
Jun 23, 2020 at 3:30 history edited Red CC BY-SA 4.0
Added dict comprehension link, and changed some dict to dictionary
Jun 16, 2020 at 2:26 review Suggested edits
Jun 16, 2020 at 4:43
May 17, 2020 at 15:04 comment added Aaron Hall♦ I agree with the eagerness to leave the old way behind, but sometimes people have to work in environments where they only have the older technology available to them. People also have to update code, and seeing the old way next to the new way allows them to confidently replace the old code with equivalent new code. I am open to suggestions on reorganizing the material, but I think we need to keep the older information.
May 17, 2020 at 14:33 comment added Neil G I agree with Gringo, this answer should be made shorter by removing all mention of Python < 3.5.
Apr 1, 2020 at 8:51 review Suggested edits
Apr 1, 2020 at 11:27
Mar 13, 2020 at 2:09 comment added Gringo Suave Hi, the top is a summary, yes. Up to you. The whole thing would be a great blog post. Note Py 3.4 and below are EOL, 3.5 approaching EOL in 2020-09.
Mar 11, 2020 at 17:32 comment added Aaron Hall♦ @GringoSuave Are you saying that it needs a summary? Because I would characterize the first part as a summary. If you say it's too long, what would you like to cut from this answer, that you think, in the cutting, would create value for users? Cheers!
Mar 4, 2020 at 15:24 history edited Nick T CC BY-SA 4.0
PEP-584 implemented circa 3.9.0a4
Feb 19, 2020 at 4:02 history edited Aaron Hall♦ CC BY-SA 4.0
update for update in PEP
Dec 29, 2019 at 3:46 history edited Aaron Hall♦ CC BY-SA 4.0
foreshadowing z = x + y
Aug 22, 2019 at 12:30 comment added Aaron Hall♦ @Richard_wth - that error message is unrelated. Check out this answer: stackoverflow.com/questions/18950054/…
Aug 22, 2019 at 6:04 comment added Richard_wth If dict1 and dict2 have some keys in common, {**dict1, **dict2} raises TypeError: type object got multiple values for keyword argument common_key_name. I guess I'll stay with {dict1, **dict2} and string keys.
May 16, 2019 at 16:07 comment added Aaron Hall♦ @MohammadAzim "strings only" only applies to keyword argument expansion in callables, not generalized unpacking syntax. To demonstrate that this works: {**{(0, 1):2}} -> {(0, 1): 2}
May 16, 2019 at 15:00 comment added Mohammad Azim Strings only limitation for keywords expansion is enough to rule out {**x, **y} method. However, the items approach can be made workable by converting dictitems to list like dict(list(x.items()), list(y.items())).
Feb 3, 2019 at 19:49 review Suggested edits
Feb 4, 2019 at 0:54
Dec 13, 2018 at 11:01 review Suggested edits
Dec 13, 2018 at 12:22
Nov 9, 2018 at 2:18 history edited Aaron Hall♦ CC BY-SA 4.0
deleted 6 characters in body
Nov 9, 2018 at 1:57 history edited Aaron Hall♦ CC BY-SA 4.0
address comments asking about nested dictionaries
Jul 3, 2018 at 17:02 history edited Jesse Dhillon CC BY-SA 4.0
added an example of splatting with a literal dict
Oct 19, 2017 at 21:16 history edited Aaron Hall♦ CC BY-SA 3.0
added 493 characters in body
Sep 29, 2017 at 17:01 history edited Aaron Hall♦ CC BY-SA 3.0
added 323 characters in body
Aug 12, 2017 at 22:05 history edited Aaron Hall♦ CC BY-SA 3.0
added 964 characters in body
Apr 15, 2017 at 19:13 history edited Aaron Hall♦ CC BY-SA 3.0
added 147 characters in body
Apr 15, 2017 at 17:47 history edited Aaron Hall♦ CC BY-SA 3.0
added 1681 characters in body
S Dec 14, 2016 at 15:46 history suggested Markus Schanta CC BY-SA 3.0
Use triple double quotes for function docstrings (as per PEP257 https://www.python.org/dev/peps/pep-0257/#what-is-a-docstring)
Dec 14, 2016 at 15:44 review Suggested edits
S Dec 14, 2016 at 15:46
Dec 2, 2016 at 21:24 history edited Aaron Hall♦ CC BY-SA 3.0
added 5 characters in body
Sep 10, 2016 at 17:30 review Suggested edits
Sep 10, 2016 at 18:11
Jun 26, 2016 at 12:36 history edited Aaron Hall♦ CC BY-SA 3.0
added 168 characters in body
Jun 26, 2016 at 10:19 history edited Mark Amery CC BY-SA 3.0
Reordered to put the most modern approach first; added emphasis on *single expression* since I imagine that may have gone over some readers' heads; tweaked language slightly for clarity in a few places. Feel free to revert if you disagree!
Jun 13, 2016 at 22:46 history edited Aaron Hall♦ CC BY-SA 3.0
added 62 characters in body
Apr 16, 2016 at 15:03 history edited Aaron Hall♦ CC BY-SA 3.0
added 12 characters in body
Apr 1, 2016 at 18:18 history edited Aaron Hall♦ CC BY-SA 3.0
deleted 123 characters in body
Feb 8, 2016 at 17:32 history edited Aaron Hall♦ CC BY-SA 3.0
added 432 characters in body
Feb 7, 2016 at 14:24 history edited Aaron Hall♦ CC BY-SA 3.0
added 1475 characters in body
Jan 6, 2016 at 16:29 history edited Aaron Hall♦ CC BY-SA 3.0
added 297 characters in body
Nov 9, 2015 at 20:01 history edited Aaron Hall♦ CC BY-SA 3.0
added 4 characters in body
Nov 3, 2015 at 15:27 history edited Aaron Hall♦ CC BY-SA 3.0
added 54 characters in body
Sep 10, 2015 at 20:39 history edited Air CC BY-SA 3.0
It is not meet that you meet the ask
Jul 29, 2015 at 17:18 history edited Aaron Hall♦ CC BY-SA 3.0
added 228 characters in body
Jul 21, 2015 at 18:14 history edited Neil G CC BY-SA 3.0
deleted 17 characters in body
Jul 1, 2015 at 13:23 history edited Aaron Hall♦ CC BY-SA 3.0
updated to improve currency of the article
May 10, 2015 at 22:50 history edited Aaron Hall♦ CC BY-SA 3.0
added 165 characters in body
Mar 11, 2015 at 22:04 history edited Aaron Hall♦ CC BY-SA 3.0
added 508 characters in body
Mar 5, 2015 at 15:28 history edited Aaron Hall♦ CC BY-SA 3.0
deleted 102 characters in body
Mar 5, 2015 at 14:52 vote accept Carl Meyer
Mar 5, 2015 at 2:13 history edited Aaron Hall♦ CC BY-SA 3.0
added 644 characters in body
Feb 25, 2015 at 18:16 history edited Aaron Hall♦ CC BY-SA 3.0
added 1571 characters in body
Feb 6, 2015 at 20:48 history edited Aaron Hall♦ CC BY-SA 3.0
added 279 characters in body
Jan 10, 2015 at 2:21 history edited the Tin Man CC BY-SA 3.0
deleted 5 characters in body
Dec 2, 2014 at 22:58 history edited Aaron Hall♦ CC BY-SA 3.0
added 143 characters in body
Nov 10, 2014 at 22:11 history answered Aaron Hall♦ CC BY-SA 3.0
toggle format