[Python-ideas] PEP: Dict addition and subtraction

Steven D'Aprano steve at pearwood.info
Fri Mar 15 10:41:59 EDT 2019


On Fri, Mar 15, 2019 at 12:20:21PM +0100, Antoine Pitrou wrote:

> Agreed with this.  What is so useful exactly in this new dict operator
> that it hasn't been implemented, say, 20 years ago?

One could say the same thing about every new feature. Since Python 1.5
was so perfect, why add Unicode, decorators, matrix multiplication, 
async, descriptors, Decimal, iterators, ... 

Matrix multiplication is a perfect example: adding the @ operator could 
have been done in Python 0.1 if anyone had thought of it, but it took 15 
years of numerical folk "whinging" about the lack until it happened:

https://mail.python.org/pipermail/python-ideas/2014-March/027053.html

In some ways, it is often easier to get community buy-in for *big* 
changes, provided they are backwards compatible. With a big change, 
people often either want it, or don't care one way or another.

(Sometimes because the big change is too big or complicated or difficult 
for them to understand -- I feel that way about async. Some day I'll 
deal with it, but right now it's so far down my list of priorities that 
I have no opinion on anything to do with async.)

But *little* changes are easy enough for everyone to understand, and so 
they trigger the impulse to bike-shed. Everyone has an opinion on 
whether or not dicts should support an update operator, and whether to 
spell it + or | or <- or << or something else.

Or the infamous := operator, which ultimately is a useful but minor 
syntactic and semantic change but generated a huge amount of debate, 
argument and negativity. A far smaller change to the language than 
adding type hinting, but it generated far more argument.

I still remember being told in no uncertain terms by the core devs that 
adding a clear() method to lists was a waste of time because there was 
already a perfectly good way to spell it with slicing. And then ABCs 
came along and now lists have a clear method. So opinions change too.

Things happen when they happen, because if they had happened earlier we 
wouldn't still be arguing about them.



> I rarely find
> myself merging dicts and, when I do, calling dict.update() is entirely
> acceptable

The code we write is shaped by the operators and methods that
exist. You use dict.update() because *it exists* so when you want a new 
dict merged with another, you write the code that is possible today:

new = spam.copy()
new.update(eggs)
process(new)

and you are content because you "rarely find myself merging dicts".

But perhaps those who *frequently* merge dicts have a different option, 
and would prefer to write one line rather than three and avoid naming 
something that doesn't need a name:

process(spam + eggs)  # or spam|eggs if you prefer


> (I think the "{**d}" notation was already a mistake, making
> a perfectly readable operation more cryptic simply for the sake of
> saving a few keystrokes).

I don't know if it was a mistake, but disatisfaction with its lack of 
readability and discoverability is one of the motivations of this PEP.


[...]
> Besides, if I have two dicts with e.g. lists as values, I *really*
> dislike the fact that the + operator will clobber the values rather than
> concatenate them.  It's a recipe for confusion.

Are you confused that the update method clobbers list values rather than 
concatenate them? I doubt that you are.

So why would it be confusing to say that + does a copy-and-update?

(In any case, popular opinion may be shifting towards preferring the | 
operator over + so perhaps confusion over concatenation may not be an 
issue in the future.)



-- 
Steven


More information about the Python-ideas mailing list