Issue 1391204: dict.merge - Python tracker (original) (raw)

Created on 2005-12-27 13:00 by nlehuen, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)

msg49231 - (view)

Author: Nicolas Lehuen (nlehuen)

Date: 2005-12-27 13:00

If you want to update a dictionary with another one, you can simply use update :

a = dict(a=1,c=3) b = dict(a=0,b=2) a.update(b) assert a == dict(a=0,b=2,c=3)

However, sometimes you want to merge the second dict into the first, all while keeping the values that are already defined in the first. This is useful if you want to insert default values in the dictionary without overriding what is already defined.

Currently this can be done in a few different ways, but all are awkward and/or inefficient :

a = dict(a=1,c=3) b = dict(a=0,b=2)

Method 1: for k in b: if k not in a: a[k] = b[k]

Method 2: temp = dict(b) temp.update(a) a = temp

This patch adds a merge() method to the dict object, with the same signature and usage as the update() method. Under the hood, it simply uses PyDict_Merge() with the override parameter set to 0 instead of 1. There's nothing new, therefore : the C API already provides this functionality (though it is not used in the dictobject.c scope), so why not expose it ? The result is :

a = dict(a=1,c=3) b = dict(a=0,b=2) a.merge(b) assert a == dict(a=1,b=2,c=3)

msg49232 - (view)

Author: Raymond Hettinger (rhettinger) * (Python committer)

Date: 2006-01-01 06:17

Logged In: YES user_id=80475

The example is only slightly complicated by the implicit requirement to keep b unchanged; otherwise, it is easy enough to swap the dicts before updating: a,b=b,a; a.update(b).

Anyway, I do not think the use case is sufficiently common or cumbersome to warrant making the mapping API more complex.

Guido?

msg49233 - (view)

Author: Guido van Rossum (gvanrossum) * (Python committer)

Date: 2006-01-01 17:55

Logged In: YES user_id=6380

I don't think we need to provide every possible permutation of existing operations.

msg49234 - (view)

Author: Jim Jewett (jimjjewett)

Date: 2006-01-13 21:52

Logged In: YES user_id=764593

The times I have wanted it are for configuration settings.

If I don't find the answer in the first place, I look in the defaults -- and I would prefer to update the current settings all at once, since I'm going to the trouble of creating creating/finding the defaults dictionary. I don't want to change the defaults, since they typically apply over a wider scope than the current context.

Note that this isn't a random permutation -- it is an existing permutation that is already exported to C extensions, and just not to python code.

msg49235 - (view)

Author: Raymond Hettinger (rhettinger) * (Python committer)

Date: 2006-01-14 01:53

Logged In: YES user_id=80475

-1 Because it is not hard to do with existing tools, because adding variants makes the interface harder to learn (hmm, was it merge() or update() that behaves thusly?), and because it is not wise to treat this the one-way-to-do-it (i.e. the config default setting use case may be better solved with chainmap(), http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305268 , which doesn't duplicate data and allows subsequent dynamic updates to either the deaults or specified overrides).

The existence of underlying C code does not make a case for exposing it in Python. We have lots of internal code used solely for the convenience of the underlying implementation or made part of the C API to simplify coding extensions (usually for things that are trivial in Python but a PITA for an extension).