> On Mar 15, 2019, at 12:28 PM, Rhodri James <rho...@kynesim.co.uk> wrote:
>
> 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.
We don't design Python for ourselves. We design it for everyday users. Telling
them that they can assume nothing is an anti-pattern. People do rely quite a
bit on their intuitions. They also rely on implicit patterns already present in
the language (i.e. in no other place is + idempotent, in no other place is + a
destructive rather than concatenative or accumulative operator). As for
commutativity, + would be obviously commutative for numeric types and obviously
noncommutative for sequence concatenation, but for dicts the non-commutativity
isn't obvious at all. And since the "|" operator is already used for mapping
views, the + operator for merging would be unexpected.
What is missing from the discussion is that we flat out don't need an operator
for this. Use of explicit method names, update() or merge(), is already clear
and already brief. Also, if we're honest with ourselves, most of us would use
this less than once a year. So why make a pervasive change for this?
Today, at least one PEP was rejected that had a stronger case than this
proposal. We should consider asking why other major languages haven't gone
down this path. The most likely reasons are 1) insufficient need, 2) the "+"
operator doesn't make sense, and 3) there are already clean ways to do it.
Also, it seems like the efficiency concerns were dismissed with hand-waving.
But usually, coping and updating aren't the desired behavior. When teaching
Python, I like to talk about how the design of the language nudges you towards
fast, clear, correct code. The principle is that things that are good for you
are put within easy reach. Things that require more thought are placed a little
further away. That is the usual justification for copy() and deepcopy() having
to be imported rather than being builtins. Copying is an obvious thing to do;
it is also not usually good for you; so, we have you do one extra step to get
to it.
Raymond
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
