[Python-ideas] dictionary constructor should not allow duplicate keys

Steven D'Aprano steve at pearwood.info
Wed May 4 08:22:52 EDT 2016

On Wed, May 04, 2016 at 12:18:59AM -0400, Random832 wrote:
> On Tue, May 3, 2016, at 23:31, Chris Angelico wrote:
> > Duplicate keys in dict display
> > is more similar to duplicate keyword arguments in a function call than
> > to reassignment.
> To play devil's advocate for a minute here...
> Why *don't* we allow duplicate keyword arguments in a function call,
> anyway? CALL_FUNCTION doesn't seem to actually care, if I create this
> situation by monkey-patching the calling function's consts to get
> duplicate keywords. All the arguments that have been raised here for
> *allowing* duplicate keyword arguments seem to apply just as well to
> f(**{'a': 1}, **{'a': 2}) [where 'a' may not be the only key present and
> they may not be literal^Wdisplays], yet that is prohibited. Why not
> remove that check, too?

(1) Because status quo wins. In the absence of a really compelling 
reason to remove that check, we don't have to justify prohibing 
duplicate keyword args, we just have to note that it is already in place 
and so we shouldn't change it.

(2) Duplicate keys in a dict may have side-effects, which mean they do 
something. Duplicate keyword arguments don't have side-effects (not in 
the keys at least). So that's a difference.

(3) The analogy between function calls and dicts is not really that 
strong. The dict constuctor intentionally allows certain duplicates:

py> dict({'a': None}, a=2)
{'a': 2}

for good reason (think of over-riding the values provided in the input 
dict with keyword arguments), but it's not clear that there is an 
analogy for function calls. Perhaps there is, and if it is a good enough 
analogy, we might have to re-think the duplicate kwargs situation.


More information about the Python-ideas mailing list