Home Original page

[Python-ideas] Adding "+" and "+=" operators to dict

Nathan Schneider neatnate at gmail.com
Thu Feb 12 22:32:23 CET 2015 
On Thu, Feb 12, 2015 at 12:15 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 12 February 2015 at 19:22, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> > On 12 February 2015 at 11:14, Paul Moore <p.f.moore at gmail.com> wrote:
> >>
> >> (the "new dependency" then would be not supporting Python <3.5 (or
> >> whatever))
> >
> > I've seen this argument a few times on python-ideas, and I don't
> understand
> > it. By this rationale, there's little point ever adding any new feature
> to
> > Python, because people who need to support older versions can't use it.
>
> To me, it means that anything that gets added to Python should be
> significant enough to be worth waiting for.
>
> > By posting on python-ideas, you're implicitly prepared to take the long
> term
> > view - these are ideas that we might be able to really use in a few
> years.
> > One day, relying on Python 3.5 or above will be completely reasonable,
> and
> > then we can take advantage of the things we're adding to it now. It's
> like
> > an investment in code.
>
> That's a fair point. You do make me think - when looking at new
> features, part of the long term view is to look at making sure a
> proposal is clean and well thought through, so that it's something
> people will be looking forward to, not merely something "good enough"
> to provide a feature.
>
> Evaluating the various proposals we've seen on that basis (and I
> concede this is purely my personal feeling):
>
> 1. + and += on dictionaries. Looking far enough into the future, I can
> see a time when people will see these as obvious and natural analogues
> of list and string concatenation. There's a shorter-term problem with
> the transition, particularly the fact that a lot of people currently
> don't find the "last addition wins" behavior obvious, and the
> performance characteristics of repeated addition (with copying). I
> could see dict1 + dict2 being seen as a badly-performing anti-pattern,
> much like string +, perfectly OK for simple cases but don't use it if
> performance matters. And performance is more likely to matter with
> dicts than strings.
>
> 2. | and |=. I can't imagine ever liking these. I don't like them for
> sets, either. Personal opinion certainly.
>
> 3. A dict method. Not sure. It depends strongly on the name chosen.
> And although it's not a strict rule (sets in particular break it) I
> tend to think of methods as being mutating, not creating new copies.
>
> 4. An updated() builtin. Feels clean and has a nice parallel with
> sorted(). But it's a common word that is often used as a variable, and
> I don't think (long term view again!) that a pattern of proliferating
> builtins as non-mutating versions of methods is a good one to
> encourage.
>
>
A reminder about PEP 448: Additional Unpacking Generalizations (
https://www.python.org/dev/peps/pep-0448/), which claims that "it vastly
simplifies types of 'addition' such as combining dictionaries, and does so
in an unambiguous and well-defined way". The spelling for combining two
dicts would be: {**d1, **d2}

Cheers,
Nathan



> >> why not create a function, put it on PyPI and collect usage stats
> >
> > Does anyone seriously believe that people will add a dependency which
> > contains a single three line function?
>
> I'm sorry, that was a snarky suggestion. (Actually my whole post was
> pretty snarky. Hopefully, this post is fairer.)
>
> I do think this is a reasonable situation to invoke the principle that
> not every 3-line code snippet deserves to be a builtin. Steven posted
> a pretty simple updated() function that projects can use, and I don't
> really understand why people can sometimes be so reluctant to include
> such utilities in their code.
>
> Anyway, overall I still remain unconvinced that this is worth adding,
> but hopefully the above explains my thinking better.
>
> Sorry again for the tone of my previous response.
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150212/86fc7924/attachment.html>
More information about the Python-ideas mailing list