[Python-ideas] [Python-Dev] hello, new dict addition for new eve ?

[Guido van Rossum]

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 at 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 at 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 at 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 <http://python.org/%7Eguido>)
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111230/84bc958f/attachment.html>