> On Mar 4, 2019, at 11:25 AM, Steven D'Aprano <st...@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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
