On Mon, Mar 04, 2019 at 08:01:38PM -0500, James Lu wrote:
On Mar 4, 2019, at 11:25 AM, Steven D'Aprano <steve@pearwood.info> wrote:
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 [...] Indeed, in this case you would want to use {**, **} syntax.
No I would NOT want to use the {**, **} syntax, because it is ugly. That's why people ask for + instead. (Or perhaps I should say "as well as" since the double-star syntax is not going away.) [...]
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.
James, I'm the author of the PEP, and for the purposes of the proposal, the + operator is supposed to do what I say it is supposed to do. You might be able to persuade me to change the PEP, if you have a sufficiently good argument, or you can write your own counter PEP making a different choice, but please don't tell me what I intended. I know what I intended, and it is for + to have the same last-key-wins behaviour as update. That's the behaviour which is most commonly requested in the various times this comes up.
, and the "require unique keys" behaviour is more common,
I just have.
No you haven't -- you have simply *declared* that it is more common, without giving any evidence for it.
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.
I don't know if it is "99% of the time" or 50% of the time or 5%, but this PEP is for the remaining times where we don't want in-place updates but we want a new dict. I use list.append or list.extend more often than list concatenation, but when I want a new list, list concatenation is very useful. This proposal is about those cases where we want a new dict. -- Steven