[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