On Mon, Mar 04, 2019 at 10:09:32AM -0500, James Lu wrote:
> How many situations would you need to make a copy of a dictionary and
> then update that copy and override old keys from a new dictionary?
Very frequently.
That's why we have a dict.update method, which if I remember correctly,
was introduced in Python 1.5 because people were frequently re-inventing
the same wheel:
def update(d1, d2):
for key in d2.keys():
d1[key] in d2[key]
You should have a look at how many times it is used in the standard
library:
[steve@ando cpython]$ cd Lib/
[steve@ando Lib]$ grep -U "\.update[(]" *.py */*.py | wc -l
373
Now some of those are false positives (docstrings, comments, non-dicts,
etc) but that still leaves a lot of examples of wanting to override old
keys. This is a very common need. Wanting an exception if the key
already exists is, as far as I can tell, very rare.
It is true that many of the examples in the std lib involve updating an
existing dict, not creating a new one. But that's only to be expected:
since Python didn't provide an obvious functional version of update,
only an in-place version, naturally people get used to writing
in-place code.
(Think about how long we made do without sorted(). I don't know about
other people, but I now find sorted indispensible, and probably use it
ten or twenty times more often than the in-place version.)
[...]
> The KeyError of my proposal is a feature, a sign that something is
> wrong, a sign an invariant is being violated.
Why is "keys are unique" an invariant?
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
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, and the "require unique keys" behaviour is more common, then
I maintain that for the very rare cases you want an exception, you can
subclass dict and overload the __add__ method:
# Intentionally simplified version.
def __add__(self, other):
if self.keys() & other.keys():
raise KeyError
return super().__add__(self, other)
> The ugliness of the syntax makes one pause
> and think and ask: “Why is it important that the keys from this
> dictionary override the ones from another dictionary?”
Because that is the most common and useful behaviour. That's what it
means to *update* a dict or database, and this proposal is for an update
operator.
The ugliness of the existing syntax is not a feature, it is a barrier.
--
Steven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
