[Python-ideas] Why operators are useful

Gustavo Carneiro gjcarneiro at gmail.com
Sat Mar 16 08:01:51 EDT 2019

On Sat, 16 Mar 2019 at 10:33, Steven D'Aprano <steve at pearwood.info> wrote:

> On Fri, Mar 15, 2019 at 10:53:31PM +0000, MRAB wrote:
> > There was also the suggestion of having both << and >>.
> >
> > Actually, now that dicts are ordered, that would provide a use-case,
> > because you would then be able to choose which values were overwritten
> > whilst maintaining the order of the dict on the LHS.
> Is that common enough that it needs to be built-in to dict itself?
> If it is uncommon, then the conventional solution is to subclass dict,
> overriding the merge operator to use first-seen semantics.
> The question this PEP is trying to answer is not "can we support every
> use-case imaginable for a merge operator?" but "can we support the most
> typical use-case?", which I believe is a version of:
>     new = a.copy()
>     new.update(b)
>     # do something with new

Already been said, but might have been forgotten, but the new proposed

    new = a + b

has to compete with the already existing syntax:

    new = {**a, **b}

The existing syntax is not exactly an operator in the mathematical sense
(or is it?...), but my intuition is that it already triggers the visual
processing part of the brain, similarly to operators.

The only argument for "a + b" in detriment of "{**a, **b}" is that "a + b"
is more easy to discover, while not many programmers are familiar with
"{**a, **b}".

I wonder if this is only a matter of time, and over time programmers will
become more accustomed to "{**a, **b}", thereby reducing the relative
benefit of  "a + b"?  Especially as more and more developers migrate code
bases from Python 2 to Python 3...

Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190316/9e0c6fd5/attachment.html>

More information about the Python-ideas mailing list