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/
