Adds a function to dictobject.c that allows python 
expressions like: 
 
>>> d = {2:3} 
>>> d += {4:5} 
>>> d 
{2: 3, 4: 5} 
 
and like: 
 
>>> d = {2:3} 
>>> e = d + {6:7} 
>>> e 
{2: 3, 6: 7} 
 
A few points: 
 
* I don't know much C, and this patch is probably 
implemented much more appropriately by someone who 
does 
 
* I don't know if there's a good reason that the dict 
type doesn't already supply this; if that's the case, 
I'd be interested to know why not 
 
* Lib/test/test_builtin.py fails (as it should) after 
applying this patch 
 
Please advise, and thanks! 

Logged In: YES 
user_id=80475

I recommend against this for several reasons:

1) adds new syntax but not new functionality

2) concept doesn't usefully extend to - and *

3) writing d.update(x) is clearer and more flexible -- in 
Py2.4, update() can take the same arguments as dict()

4) no use cases showing the + operator to be more 
expressive

5) possibly confusing given the | operator is used for sets

6) {1:4}+{1:7} is not commutative and unlike list addition, 
there is no underlying order that makes the non-
commutativity obvious.  IOW, the operator may introduce a 
new class of hard to find bugs.

If for some reason this gets approved, please assign back to 
me for implementation, documentation, and unittests.

Logged In: YES 
user_id=548370

1) adds new syntax but not new functionality

3) writing d.update(x) is clearer and more flexible -- in 
Py2.4, update() can take the same arguments as dict()

The same is true of list.extend and list.append.  After
years of writing python code, I still forget that I can't
add dictionaries to one another, which for me at least,
violates the principle of least surprise.

The patch doesn't provide the same behavior as the update
method; when adding two dicts, a third dict is returned. 
Only in the case of augmented assignment is the update
method similar.

Moreover, every other basic container-ish type supports
addition of the same type (or similar type).  It seems to me
that the dict type is missing a feature, not the other way
around.

2) concept doesn't usefully extend to - and *

I could see it extending to -, but you're right that it
doesn't extend to *.

5) possibly confusing given the | operator is used for sets

I don't understand this point, could you elaborate?

6) {1:4}+{1:7} is not commutative and unlike list addition, 
there is no underlying order that makes the non-
commutativity obvious.  IOW, the operator may introduce a 
new class of hard to find bugs.

But unlike list addition, dict addition is commutative:

>>> d = {2:3}
>>> e = {4:5}
>>> d + e == e + d
True

Thanks for looking; could you advise again?

Logged In: YES 
user_id=593130

I am usually big on orthogonality, but it never occurred to me 
that dicts should be addible, although sets are.  What should 
be the result of {1:2} + {1:3}?  If not something like {1:set
(2,3)}, the operator is *not* commutative.

The reference to sets and | is that | is used, I believe, for 
set union (addition) (and & for intersection).  So, if there 
were to be a dict union operator, the symbol should be | 
rather than +.

Logged In: YES 
user_id=548370

Doh.  You're right about it being not commutative.  I 
hadn't considered the example you provided. 
 
I agree that the | operator makes more sense.  I'll close 
this patch until I'm up to implementing that. 
 
Thanks, Terry, Raymond! 

Logged In: YES 
user_id=80475

The non-commutativity issue also applies to the | operator.

I wouldn't spend time on a second patch unless there were
significant new functionality, compelling use cases, a
natural readability for expressions involving the operator,
and an approach that suggests non-commutative update
behavior.  IOW, I wouldn't spend time on a second patch ;-)