Hi Julien,

Having now looked at your code, I realize we are not talking about the same concepts at all.

What I meant is similar to set union on the keys, where if a key exists in both dicts, the value in the result is equal to one of the values in the operands (and if the value is the same for both operands, that value is also the result value).

But looking at your code, you are more interested in *elementwise* addition, so that {'x': 1} + {'x': 2} results in {'x': 3}, and missing keys are considered to be zero. (For disjoint key sets, your result is the same as mine. :-)

I think this would be a nice thing for some applications, but I'm doubtful that it's of enough interest to add to the standard library, let alone make it a standard feature of the built-in dict class. One problem is that the dict API is already very rich (dozens of methods and operations) Another problem is that your proposed class solves only part of the puzzle of elementwise operations -- if you have elementwise addition for dicts, why not for lists? But l1+l2 already has a meaning for list: concatenation. We've discussed this before. NumPy has got its own solution (a1+a2 does elementwise addition if a1 and a2 are NumPy arrays), but for the stdlib we've always decided that it's better to leave the choice up to the user, the app or the framework (like NumPy), instead of making a choice in the stdlib that causes backward incompatibility.

(Had I known all this 22 years ago, maybe I could have chosen a different operator for list concatenation. But I don't think the issue is important enough to fix, even if we ever did a Python 4.)

--Guido

On Fri, Dec 30, 2011 at 9:40 AM, Guido van Rossum <guido@python.org> wrote:
Hi Julien,

Don't despair! I have tried to get people to warm up to dict addition too -- in fact it was my counter-proposal at the time when we were considering adding sets to the language. I will look at your proposal, but I have a point of order first: this should be discussed on python-ideas, not on python-dev. I have added python-ideas to the thread and moved python-dev to Bcc, so followups will hopefully all go to python-ideas.

--Guido


On Fri, Dec 30, 2011 at 7:26 AM, julien tayon <julien@tayon.net> wrote:
Hello,
Sorry to annoy the very busy core devs :) out of the blue

I quite noticed people were
1) wanting to have a new dict for Xmas
2) strongly resenting dict addition.

Even though I am not a good developper, I have come to a definition of
addition that would follow algebraic rules, and not something of a
dutch logic. (it is a jest, not a troll)

I propose the following code to validate my point of view regarding
the dictionnatry addition as a proof of concept :
https://github.com/jul/ADictAdd_iction/blob/master/test.py

It follows all my dusty math books regarding addition + it has the
amability to have rules of conservation.

I pretty much see a real advantage in this behaviour in functional
programming (map/reduce). (see the demonstrate.py), and it has a sense
(if dict can be seen has vectors).

I have been told to be a troll, but I am pretty serious.

Since, I coded with luck, no internet, intuition, and a complete
ignorance of the real meaning of the magic methods most of the time,
thus the actual implementation of the addition surely needs a complete
refactoring.

Sheers,
Bonne fêtes
Julien
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org



--
--Guido van Rossum (python.org/~guido)



--
--Guido van Rossum (python.org/~guido)