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