Any reason why not just above? or just explicitly make a shallow copy?

@Skylion007 the version I have is 1.5x faster:

>>> other={1:2, 3:4}
>>> timeit.timeit(lambda: dict(other))
0.09024659299757332
>>> timeit.timeit(lambda: {**other})
0.05995289294514805
>>> 

and what about other.copy()? Also @jansel what about as other dict grows? My understanding is dict() may have more initial overhead due to the function call lookup, but better scaling with larger dicts.

@Skylion007 other.copy() is also slower:

>>> timeit.timeit(lambda: other.copy())
0.075550084002316

For large dicts all 3 become the same (though {**other} is slightly faster):

>>> large = dict.fromkeys(range(1000))
>>> timeit.timeit(lambda: dict(large))
2.926349258981645
>>> timeit.timeit(lambda: {**large})
2.9151299450313672
>>> timeit.timeit(lambda: large.copy())
2.917799219954759

None of this should be surprising if you look at the output bytecode:

• dict becomes LOAD_GLOBAL, which involves 2 module lookups (one for globals() and one for builtins -- both of which are hashtables). You can write dict=MyDict in global scope, so this is very hard to optimize.
• copy becomes LOAD_METHOD, which involves a method lookup on an object (also a hashtable lookup). The object might not be a dict, so this is very hard to optimize.
• {**x} involves zero string lookups, since you get DICT-specific bytecodes with no dynamic behavior.

The exact same logic flows making [*x] faster than list(x).