On Oct 18, 2019, at 06:49, Paul Moore <p.f.mo...@gmail.com> wrote:
>
> IMO, debating the "meaning" of addition, and whether the + operator is
> appropriate here, is not the key question. The real questions for me
> are whether the update operation is used frequently enough to require
> an additional way of spelling it, and whether using the + operator
> leads to cleaner more readable code.
I don’t think it’s about the mutating update operation; I think everyone can
live with the update method there. The problem is the copying update. The only
way to spell it is to store a copy in a temporary variable and then update
that. Which you can’t do in an expression. You can do _almost_ the same thing
with {**a, **b}, but not only is this ugly and hard to discover, it also gives
you a dict even if a was some other mapping type, so it’s making your code more
fragile, and usually not even doing so intentionally.
I have definitely wanted this operation myself. The fact that even people who
don’t like this proposal think it would be helpful in a quarter of the 20
places given where it could be used sounds like an argument for it. (As a side
note, I think the PEP might be more effective if it identified good uses,
rather than identifying a bunch of uses good and bad and leaving it to the
reader to decide which was which, but that’s not a problem with the value of
the proposal, at worst it’s a “strategic” problem with the PEP.)
If we accept that this is useful, then there’s the question of whether it needs
to be an operator, or a method, or a builtin function, or a function in
collections. And then, if it’s an operator, the question of whether that should
be + or | or something else.
And I think mutating update just goes along for the ride: if we end up adding +
in analogy with list concatenation, then obviously we want += as well; if we
add |, add |= as well; it we add a merge method, we’ve already got an update
method so nothing changes there; etc
Anyway, it sounds like the only arguments against it are arguments that Python
shouldn’t have polymorphic operator overloading in the first place. Honestly,
if you believe that, I don’t know why you’d like Python in the first place.
It’s embedded so deeply in the design of the language that most of the “data
model” chapter of the reference is about it; it’s a big part of what makes
Python “duck typed”, and why we have NumPy and SymPy while other dynamic
languages can’t, and so on.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MUYP33KVGLQ6YVSZOOABA5Y47QTPINZB/
Code of Conduct: http://python.org/psf/codeofconduct/
