On 29 Jul 2014 04:40, "Ryan Hiebert" <ryan@ryanhiebert.com> wrote:
>
>
> > On Jul 28, 2014, at 11:04 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> >
> > I'm still inclined to prefer allowing update() to accept multiple
> > arguments:
> >
> > a.update(b, c, d)
> >
> > rather than a += b + c + d

Note that if update() was changed to accept multiple args, the dict() constructor could similarly be updated.

Then:

    x = dict(a)
    x.update(b)
    x.update(c)
    x.update(d)

Would become:

    x = dict(a, b, c, d)

Aside from the general "What's the use case that wouldn't be better served by a larger scale refactoring?" concern, my main issue with that approach would be the asymmetry it would introduce with the set constructor (which disallows multiple arguments to avoid ambiguity in the single argument case).

But really, I'm not seeing a compelling argument for why this needs to be a builtin. If someone is merging dicts often enough to care, they can already write a function to do the dict copy-and-update as a single operation. What makes this more special than the multitude of other three line functions in the world?

Cheers,
Nick.