On 15/03/2019 18:54, Raymond Hettinger wrote:
So, we have to ask whether we're stretching too far from "operators are good" to "we
need this operator". Here are some considerations:
Frequency of usage: Math provides ∑ and ∏ because they are common. It doesn't
provide a special operator for sqrt(c**2 - b**2) because the latter is less
fundamental and less common. To me, f=d.copy() followed by f.update(e) arises
so rarely that an operator isn't warranted. The existing code is already
concise, clear, and rare.
I think the "less fundamental" in your argument is more relevant than
the "less common". Mathematicians will cheerfully invent operators for
whatever is fundamental to their field and then use them twice in a
paper, but still write out fully common combinations. I would suggest
that merging is merging is a fairly fundamental operation for
dictionaries, so is a good candidate for an operator.
The combination "f=d.copy(); f.update(e)" is rare in my code. I suspect
that's partly because it doesn't occur to me that I can do it. Guido's
argument about recognisability is strong here. I know that
dict.update() exists, and that I can destructively merge dictionaries.
The extra step of doing the copy first for a non-destructive merge makes
for a much less memorable pattern, to the point where I just don't think
of it unless it would be more than usually useful. "f = d | e" (however
it gets spelled) is much easier to remember the existence of.
Familiarity: We know about + because we use it a lot in addition and concatenation contexts. However, a symbol like ⊗ is more opaque unless we're
using it every day for a particular purpose. To me, the "+" operator implies "add/extend" semantics rather than
"replace" semantics. Successive applications of "+" are never idempotent unless one operand is an identity element. So for me,
"+" isn't familiar for dict merges. Loosely put, it isn't "plus-like". I think this is why so many other languages decided not
use "+" for dict merges even when that would have been a trivially easy implementation choice.
I'm beginning to be swayed by the arguments that merging is more
"or-like" and the right analogy is with set union. Personally I don't
find "|" for set union at all obvious, but that argument was lost long
ago, and like I said it's just personal. I don't have the same problem
you have with the semantics of "+", but when I was a maths student I was
used to using "+" as an entirely generic operator not necessarily
meaning addition, so it's probably just me.
Obviousness: When working with "+" on numeric types, it is obvious it should be commutative. When using
"+" when sequence types, it is obvious that concatenation is non-commutative. When using "+" for
mapping types, it is not obvious that it isn't commutative. Likewise, it isn't obvious that "+" is a
destructive operation for mappings (consider that adding to a log file never destroys existing log entries, while
updating a dict will overwrite existing values).
I suspect this is a bit personal; I had sufficiently evil lecturers in
my university Algebra course that I still don't automatically take the
commutativity of "+" over a particular group as a given :-) Nothing is
obvious unless you already know it.
(There is a probably apocryphal tale of a lecturer in full flow saying
"It is obvious that..." and pausing. He then turned to the blackboard
and scribbled furiously in one corner for five minutes. "I was right,"
he said triumphantly, "it is obvious!")
Harmony: The operators on dict views use "|" but regular dicts would use "+".
That doesn't seem harmonious.
Yes, that's probably the killer argument against "+", damn it.
Impact: When a class in the standard library adds a method or operator, the
reverberations are felt only locally. In contrast, the dict API is
fundamental. Changing it will reverberate for years. It will be felt in the
ABCs, typeshed, and every mapping-like object. IMO such an impactful change
should only be made if it adds significant new functionality rather than
providing a slightly shorter spelling of something we already have.
I am inclined that adding significant new utility (which this does) is
also a good enough reason to make such an impactful change.
--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
