Summary:
Dictionaries should support being added to other dictionaries instead of
using update(). This should be a relatively easy fix and would make the
language more pythonic.

How to reproduce:
$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> {1: 2, 3: 4} + {5: 6, 7: 8}

What happens:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'dict' and 'dict'

What should happen:
{1: 2, 3: 4, 5: 6, 7: 8}

Temporary workaround:
>>> a = {1: 2, 3: 4}
>>> b = {5: 6, 7: 8}
>>> c = a.copy()
>>> c.update(b)
>>> print c
{1: 2, 3: 4, 5: 6, 7: 8}
This is undesirable because it is not very compact and hard to read. Why
should any language take five lines of code to merge only two dictionaries?

What would you do in case of duplicate keys?

I am against adding __add__ to dict, since merging dictionaries is not a
commutative operation.

If a short syntax is desired for merging dictionaries, the just define a
function. For example: 

def merge_dicts(*args):
  result = {}
  for x in args:
    result.update(x)
  return result

__add__ is non-commutative for lists, tuples, strings etc. - perhaps 
non-commutative wasn't quite what you were looking for :p.

Why so much opposition to the shorter spelling of .copy() & .update()? 
As Tim pointed out, lists, tuples, and strings all provide this
shortcut.  Why not dicts?

Lists, tuples, and strings are all sequences. Adding two non-ordering
mappings makes much less sense in my head than two sequences.

Tim Gordon wrote:
> __add__ is non-commutative for lists, tuples, strings etc. - perhaps 
> non-commutative wasn't quite what you were looking for :p.

Yeah, I was not clear in my explanation.

The thing is for lists, tuples, string and other ordered types
concatenation is a well-defined concept. Whereas for dictionaries is not
obvious what concatenation should do with duplicate keys. For example,
what would be the result of {"a": 1, "b": 2} + {"a": 2, "b": 1}? Should
it be {"a": 1, "b": 2} or {"a": 2, "b": 1}?

Also, it would be inconsistent the use of | for the union operation of sets.

A dict.merge() method could be added so that:

>>> a = dict(x=10, y=20)
>>> b = dict(y=30, z=40)
>>> a.merge(b)
dict(x=10, y=20, z=40)
>>> b.merge(a)
dict(y=30, z=40, x=10)

In case of duplicate keys, the items of the second dict with the same
keys will be discarded (even if dict.update() does the opposite, I think
here it make more sense in this way).

I never needed to do something like this though, so I'm +0 about it.

IIRC, Guido has previously rejected this suggestion and its variants.

> IIRC, Guido has previously rejected this suggestion and its variants.

Got a link?  It'd be nice to know what the rationale was.

Regardless of whether this feature will be dict.merge or __add__, it
needs to work its way through python-ideas first.

FWIW, I'm -1 on the proposal because it partially overlaps the existing
capability of dict.update().  To the extent it doesn't overlap, it is
use case challenged (typically, it doesn't make sense to build a
brand-new dictionary from two independent dictionaries and the atypical
case easily fulfilled by a couple of updates on an empty dict).  

Also, the notation itself is at odds with the existing pipe-operator
used by sets and by dict views.

FWIW, there are other alternatives to directly combining dictionaries. 
See http://code.activestate.com/recipes/305268/ for one example.

FWIW, here are some use cases:

http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/python/context.py#L32
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/python/log.py#L270
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/words/xish/utility.py#L23
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/web/microdom.py#L720
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/web/microdom.py#L738
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/test/test_adbapi.py#L370
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/test/test_zshcomp.py#L34
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/mail/scripts/mailmail.py#L345
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/internet/_dumbwin32proc.py#L167
http://twistedmatrix.com/trac/browser/tags/releases/twisted-8.2.0/twisted/lore/default.py#L17

ISTM these examples show how little value would come from fattening-up
the dict API.  The examples use the copy/update pattern which is clear,
explicit, and extendable to n-ary cases without incurring O(n**2)
behavior.  Tranforming them to a f=d+e pattern saves a few characters;
doesn't add any speed; makes it less clear that we're operating on
dictionaries; and does not extend well to the n-ary case (f=a+b+c+d+e
which copies a's elements five times, b's four times, etc.)  No new
functionality gets added -- all this is is a piece of syntactic sugar
that obscures what is going-on under the hood.  The dict API is one of
the most fundamental in the language; it needs to be kept as clean and
hazard-free as possible.

Cool.  I'm convinced.

> what would be the result of {"a": 1, "b": 2} + {"a": 2, "b": 1}?
> Should it be {"a": 1, "b": 2} or {"a": 2, "b": 1}?

or {"a":[1,2], "b":[1,2]}
As I remember, Guido rejected because of this ambiguity.