Response

There is precedent for non-commutative unions in Python:

>>> {0} | {False}
{0}
>>> {False} | {0}
{False}

While the results may be equal, they are distinctly different. In general, a | b is not the same operation as b | a.

Response

The same argument applies to sequence concatenation.

Sequence concatenation grows with the total number of items in the sequences, leading to O(N**2) (quadratic) performance. Dict union is likely to involve duplicate keys, so the temporary mappings will not grow as fast.

Just as it is rare for people to concatenate large numbers of lists or tuples, the authors of this PEP believe that it will be rare for people to merge large numbers of dicts. collections.Counter is a dict subclass that supports many operators, and there are no known examples of people having performance issues due to combining large numbers of Counters. Further, a survey of the standard library by the authors found no examples of merging more than two dicts, so this is unlikely to be a performance problem in practice… “Everything is fast for small enough N”.

If one expects to be merging a large number of dicts where performance is an issue, it may be better to use an explicit loop and in-place merging:

new = {}
for d in many_dicts:
    new |= d

Response

It isn’t clear why the first part of this argument is a problem. dict.update() may throw away values, but not keys; that is expected behavior, and will remain expected behavior regardless of whether it is spelled as update() or |.

Other types of union are also lossy, in the sense of not being reversible; you cannot get back the two operands given only the union. a | b == 365… what are a and b?

Response

There is no such koan. “Only One Way” is a calumny about Python originating long ago from the Perl community.

Response

There is no such prohibition. The “Zen of Python” merely expresses a preference for “only one obvious way”:

There should be one-- and preferably only one --obvious way to do
it.

The emphasis here is that there should be an obvious way to do “it”. In the case of dict update operations, there are at least two different operations that we might wish to do:

• Update a dict in place: The Obvious Way is to use the update() method. If this proposal is accepted, the |= augmented assignment operator will also work, but that is a side-effect of how augmented assignments are defined. Which you choose is a matter of taste.
• Merge two existing dicts into a third, new dict: This PEP proposes that the Obvious Way is to use the | merge operator.

In practice, this preference for “only one way” is frequently violated in Python. For example, every for loop could be re-written as a while loop; every if block could be written as an if/ else block. List, set and dict comprehensions could all be replaced by generator expressions. Lists offer no fewer than five ways to implement concatenation:

• Concatenation operator: a + b
• In-place concatenation operator: a += b
• Slice assignment: a[len(a):] = b
• Sequence unpacking: [*a, *b]
• Extend method: a.extend(b)

We should not be too strict about rejecting useful functionality because it violates “only one way”.

Response

This is very true. But it is equally true today, where the use of the | operator could mean any of:

• int/bool bitwise-or
• set/frozenset union
• any other overloaded operation

Adding dict union to the set of possibilities doesn’t seem to make it harder to understand the code. No more work is required to determine that spam and eggs are mappings than it would take to determine that they are sets, or integers. And good naming conventions will help:

flags |= WRITEABLE  # Probably numeric bitwise-or.
DO_NOT_RUN = WEEKENDS | HOLIDAYS  # Probably set union.
settings = DEFAULT_SETTINGS | user_settings | workspace_settings  # Probably dict union.

Response

This PEP does not take a position on whether dicts should support the full collection of set operators, and would prefer to leave that for a later PEP (one of the authors is interested in drafting such a PEP). For the benefit of any later PEP, a brief summary follows.

Set symmetric difference (^) is obvious and natural. For example, given two dicts:

d1 = {"spam": 1, "eggs": 2}
d2 = {"ham": 3, "eggs": 4}

the symmetric difference d1 ^ d2 would be {"spam": 1, "ham": 3}.

Set difference (-) is also obvious and natural, and an earlier version of this PEP included it in the proposal. Given the dicts above, we would have d1 - d2 be {"spam": 1} and d2 - d1 be {"ham": 3}.

Set intersection (&) is a bit more problematic. While it is easy to determine the intersection of keys in two dicts, it is not clear what to do with the values. Given the two dicts above, it is obvious that the only key of d1 & d2 must be "eggs". “Last seen wins”, however, has the advantage of consistency with other dict operations (and the proposed union operators).

Response

There are two primary reasons why adding the new operators to these classes would be problematic:

• Currently, neither defines a copy method, which would be necessary for | to create a new instance.
• Adding |= to MutableMapping (or a copy method to Mapping) would create compatibility issues for virtual subclasses.

Raise

It isn’t clear that this behavior has many use-cases or will be often useful, but it will likely be annoying as any use of the dict union operator would have to be guarded with a try/except clause.

Add The Values (As Counter Does, with +)

Too specialised to be used as the default behavior.

Leftmost Value (First-Seen) Wins

It isn’t clear that this behavior has many use-cases. In fact, one can simply reverse the order of the arguments:

d2 | d1  # d1 merged with d2, keeping existing values in d1

Concatenate Values In A List

This is likely to be too specialised to be the default. It is not clear what to do if the values are already lists:

{'a': [1, 2]} | {'a': [3, 4]}

Should this give {'a': [1, 2, 3, 4]} or {'a': [[1, 2], [3, 4]]}?

Use The Addition Operator

This PEP originally started life as a proposal for dict addition, using the + and += operator. That choice proved to be exceedingly controversial, with many people having serious objections to the choice of operator. For details, see previous versions of the PEP and the mailing list discussions.

Use The Left Shift Operator

The << operator didn’t seem to get much support on Python-Ideas, but no major objections either. Perhaps the strongest objection was Chris Angelico’s comment

The “cuteness” value of abusing the operator to indicate information flow got old shortly after C++ did it.

Use A New Left Arrow Operator

Another suggestion was to create a new operator <-. Unfortunately this would be ambiguous, d <- e could mean d merge e or d less-than minus e.

Use A Method

A dict.merged() method would avoid the need for an operator at all. One subtlety is that it would likely need slightly different implementations when called as an unbound method versus as a bound method.

As an unbound method, the behavior could be similar to:

def merged(cls, *mappings, **kw):
    new = cls()  # Will this work for defaultdict?
    for m in mappings:
        new.update(m)
    new.update(kw)
    return new

As a bound method, the behavior could be similar to:

def merged(self, *mappings, **kw):
    new = self.copy()
    for m in mappings:
        new.update(m)
    new.update(kw)
    return new

Use a Function

Instead of a method, use a new built-in function merged(). One possible implementation could be something like this:

def merged(*mappings, **kw):
    if mappings and isinstance(mappings[0], dict):
        # If the first argument is a dict, use its type.
        new = mappings[0].copy()
        mappings = mappings[1:]
    else:
        # No positional arguments, or the first argument is a
        # sequence of (key, value) pairs.
        new = dict()
    for m in mappings:
        new.update(m)
    new.update(kw)
    return new

An alternative might be to forgo the arbitrary keywords, and take a single keyword parameter that specifies the behavior on collisions:

def merged(*mappings, on_collision=lambda k, v1, v2: v2):
    # implementation left as an exercise to the reader