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

Peter Mawhorter pmawhorter at gmail.com
Sat Feb 14 18:18:18 CET 2015


On Sat, Feb 14, 2015 at 7:59 AM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

>
> However, this thread started with a desire for the + and += operators
> -- essentially syntactic sugar ( which I happen to like ). So is there
> a real desire / use case for easy to spell merge-into-new-dict
> behavior at all?
>
> -Chris
>

I'm pretty sure it's already been mentioned but as many people seem to be
asking for a use-case again: the primary use-case that I can see for either
an operator or a merge function is doing the operation (copy-and-merge) as
part of a larger expression, like so:


result = foo(bar(merged(d1, d2))

or

result = foo(bar(d1 + d2))


There are plenty of times when succinct code is a virtue, and the lack of a
function/operator for merging dictionaries requires an extra line of code,
despite the concept being relatively straighforward. A more complicated
exmaple provides even better motivation IMO:

result = [ merged(d1, d2) for d1 in list1 for d2 in list2 ]

In fact, the entire concept of generator expressions is motivated by the
same logic: with sufficiently clear syntax, expressing complex operations
that conform to common usage patterns and are thus easy to understand as a
single line of code (or single expression) is beneficial relative to having
to type out a for-loop every time. Generator expressions are a really great
part of Python, because they make your code more readable (it's not just
having to read fewer lines of code, but I think more to do with having to
mentally track fewer variables IMO). A "merged" function for dictionaries
would achieve a similar result, by in the examples above eliminating a
variable assignment and a line of code.

As for the color of the bike-shed...

Arguments here have convinced me that an operator is perhaps unnecessary,
so a function (either class method, builtin, or normal method) seems like
the best solution. Given that I prefer "merged" for a name, as it's more
intuitive for me than "updated", although it's sad to miss out on the
parallelism with sort/sorted. I do think something past-tense is good,
because that's a mnemonic that greatly helped me learn when/where to use
sort vs. sorted.

-Peter Mawhorter

P.S.

A concrete example use case taken from code that I've actually written
before:

def foo1(**kwargs):
  defaults = {
    "a": 1,
    "b": 2
  }
  defaults.update(kwargs)
  process(defaults)

def foo2(**kwargs):
  defaults = {
    "a": 1,
    "b": 2
  }
  process(merged(defaults, kwargs))

foo1 uses the existing syntax, while foo2 uses my favorite version of the
new syntax. I've always felt uneasy about foo1, because if you read the
code too quickly, it *looks* as though two very odd things are happening:
first, you naively see the defaults being changed and wonder if there could
be bug where the defaults are retaining updates (if you later change
defaults to a global variable, watch out!), and second, you see
process(defaults) and wonder if there's a bug where the external input is
being ignored. The alternative that clears up these code readability issues
involves an extra line of code and a whole extra variable though, so it
isn't really a good option. The new syntax here does force me to pay a
small performance penalty (I'm creating the extra variable internally) but
that's almost never going to be an issue given the likely size of the
dictionaries involved. At the same time, the new syntax is miles clearer
and it's also more concise, plus it protects you in the case that you do
move "defaults" out of the function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150214/f3edbd21/attachment-0001.html>


More information about the Python-ideas mailing list