On Mar 4, 2019, at 11:25 AM, Steven D'Aprano <steve@pearwood.info> wrote:
The PEP gives a good example of when this "invariant" would be unnecessarily restrictive:
For example, updating default configuration values with user-supplied values would most often fail under the requirement that keys are unique::
prefs = site_defaults + user_defaults + document_prefs
Another example would be when reading command line options, where the most common convention is for "last option seen" to win:
[steve@ando Lib]$ grep --color=always --color=never "zero" f*.py fileinput.py: numbers are zero; nextfile() has no effect. fractions.py: # the same way for any finite a, so treat a as zero. functools.py: # prevent their ref counts from going to zero during
Indeed, in this case you would want to use {**, **} syntax.
and the output is printed without colour.
(I've slightly edited the above output so it will fit in the email without wrapping.)
The very name "update" should tell us that the most useful behaviour is the one the devs decided on back in 1.5: have the last seen value win. How can you update values if the operation raises an error if the key already exists? If this behaviour is ever useful, I would expect that it will be very rare.
An update or merge is effectively just running through a loop setting the value of a key. See the pre-Python 1.5 function above. Having update raise an exception if the key already exists would be about as useful as having ``d[key] = value`` raise an exception if the key already exists.
Unless someone can demonstrate that the design of dict.update() was a mistake You’re making a logical mistake here. + isn’t supposed to have .update’s behavior and it never was supposed to.
, and the "require unique keys" behaviour is more common, I just have. 99% of the time you want to have keys from one dict override another, you’d be better off doing it in-place and so would be using .update() anyways.
then I maintain that for the very rare cases you want an exception, you can subclass dict and overload the __add__ method: Well, yes, the whole point is to define the best default behavior.