[Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

[Terry Reedy]

On 3/22/2019 12:53 AM, Steven D'Aprano wrote:
> On Thu, Mar 21, 2019 at 09:36:20PM -0400, Terry Reedy wrote:
> 
>> I counted what I believe to be 10 instances of copy-update in the top
>> level of /lib.  Do either of you consider this to be enough that any
>> addition would be worthwhile.
> 
> I think you're referring to Guido and Antoine? 

Yes, those were the two (core-devs) I quoted, and perhaps had missed my 
post, while you already thanked me for collecting some date.

> But for what it's worth,
> I think that's a good indication that there are uses for a merge
> operator.

Some, yes.  Enough for new syntax?  What is a reasonable standard?  Are 
there existing syntax features so sparsely used?  What is the bar for 
something that adds no new function, but saves 6 chars and is easier to 
understand for at least some?

In the past, 'Would this be used in the stdlib?' has been asked of 
feature proposals.  But I never paid attention past == 0 or > 0.  When 
Guido approved ':=', what threashhold of usefulness did he use?  How 
many uses of ':=' does he anticipate, or consider enough to justify the 
addition?

>> There are 3 in idlelib that I plan to replace with {**a, **b} and be
>> done with the issue.  I did not check any other packages.
> 
> If a+b already worked for dicts, would you still prefer {**a, **b}?

Example: {**sys.modules, **globals()}

Aside from the fact that I can patch *and* backport to 3.7 *now*, I 
think so.  The latter clearly (to me) maps mappings to a dict.

> How about if it were spelled a|b?

As in sys.modules | globals() or (sys.modules | globals())?  Closer.

-- 
Terry Jan Reedy