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. Ingeneral,a|b is not the same operation asb|a.

Response

The same argument applies to sequence concatenation.

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

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

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

new={}fordinmany_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 isexpected behavior, and will remain expected behavior regardless ofwhether it is spelled asupdate() or|.

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

Response

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

Response

There is no such prohibition. The “Zen of Python” merely expresses apreference for “only oneobvious way”:

Thereshouldbeone--andpreferablyonlyone--obviouswaytodoit.

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 twodifferent operations that we might wish to do:

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

In practice, this preference for “only one way” is frequently violatedin Python. For example, everyfor loop could be re-written as awhile loop; everyif block could be written as anif/else block. List, set and dict comprehensions could all bereplaced by generator expressions. Lists offer no fewer than fiveways 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 functionalitybecause 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 makeitharder to understand the code. No more work is required todetermine thatspam andeggs are mappings than it would taketo determine that they are sets, or integers. And good namingconventions 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 thefull collection of set operators, and would prefer to leave that for alater 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 differenced1^d2 would be{"spam":1,"ham":3}.

Set difference (-) is also obvious and natural, and an earlierversion of this PEP included it in the proposal. Given the dictsabove, we would haved1-d2 be{"spam":1} andd2-d1 be{"ham":3}.

Set intersection (&) is a bit more problematic. While it is easyto determine the intersection ofkeys in two dicts, it is not clearwhat to do with thevalues. Given the two dicts above, it isobvious that the only key ofd1&d2 must be"eggs". “Lastseen wins”, however, has the advantage of consistency with other dictoperations (and the proposed union operators).

Response

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

• Currently, neither defines acopy method, which would benecessary for| to create a new instance.
• Adding|= toMutableMapping (or acopy method toMapping) would create compatibility issues for virtualsubclasses.

Raise

It isn’t clear that this behavior has many use-cases or will be oftenuseful, but it will likely be annoying as any use of the dict unionoperator would have to be guarded with atry/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, onecan 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 notclear 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 beexceedingly controversial, with many people having serious objectionsto the choice of operator. For details, seeprevious versions of thePEP and the mailing listdiscussions.

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 wasChris Angelico’s comment

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

Use A New Left Arrow Operator

Another suggestion was to create a new operator<-. Unfortunatelythis would be ambiguous,d<-e could meandmergee ordless-thanminuse.

Use A Method

Adict.merged() method would avoid the need for an operator atall. One subtlety is that it would likely need slightly differentimplementations when called as an unbound method versus as a boundmethod.

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

defmerged(cls,*mappings,**kw):new=cls()# Will this work for defaultdict?forminmappings:new.update(m)new.update(kw)returnnew

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

defmerged(self,*mappings,**kw):new=self.copy()forminmappings:new.update(m)new.update(kw)returnnew

Use a Function

Instead of a method, use a new built-in functionmerged(). Onepossible implementation could be something like this:

defmerged(*mappings,**kw):ifmappingsandisinstance(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()forminmappings:new.update(m)new.update(kw)returnnew

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

defmerged(*mappings,on_collision=lambdak,v1,v2:v2):# implementation left as an exercise to the reader