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)

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?

Logged In: YES 
user_id=6380

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

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.

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).