
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