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

[Paul Moore]

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.

>> 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