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

[Michel Desmoulin]

With Python 3.5, you can unpack in dictionaries:

d = {**foo, **bar}

It's now the defacto way of merging 2 dicts, and it requires that you
can use twice the same key for ovious reasons.

So even if you have good points, it's not possible to do this.

Le 02/05/2016 23:36, Luigi Semenzato a écrit :
> Hello and sorry if this is an old and over-discussed topic.  I could
> not find such discussions here.
> 
> This was discussed and rejected at https://bugs.python.org/issue16385,
> but I am not convinced that the discussion presented all arguments
> properly.  I tried reopening the bug at
> http://bugs.python.org/issue26910, but was told I should discuss it
> here instead.
> 
> The original problem description:
> 
> lives_in = { 'lion': ['Africa', 'America'],
>              'parrot': ['Europe'],
>              #... 100+ more rows here
>              'lion': ['Europe'],
>              #... 100+ more rows here
>            }
> 
> The above constructor overwrites the first 'lion' entry silently,
> often causing unexpected behavior.
> 
> These are the arguments presented in favor of the rejection, followed
> by my rebuttals.
> 
> 1. "An error is out of the question for compatibility reasons".  No
> real rebuttal here, except I wonder if exceptions are ever made and
> under what circumstances.  I should point out that a warning may also
> create incompatibilities.
> 
> 2. "There are ways to rewrite this as a loop on a list".  Yes of
> course, but the entire point of the dictionary literal is to offer a
> concise and convenient notation for entering a dictionary as program
> text.
> 
> 3. "Being able to re-write keys is fundamental to Python dicts and why
> they can be used for Python's mutable namespaces".  This is fine but
> it applies to the data structure, not the literal constructor.
> 
> 4. "A code generator could depend on being able to write duplicate
> keys without having to go back and erase previous output".  Yes, but
> it seems wrong to facilitate automated code generation at the expense
> of human code writing.  For hand-written code, I claim that in most
> (all?) cases it would be preferable to have the compiler detect key
> duplications.  It is easier for an automated code generator to check
> for duplications than it is for a human.
> 
> 5. "There is already pylint".  True, but it forces an additional step.
> 
> For context, someone ran into this problem in my team at Google (we
> fixed it using pylint).  I haven't seen any valid reason (in the bug
> or elsewhere) in favor of these constructor semantics.  From the
> discussions I have seen, it seems just an oversight in the
> implementation/specification of dictionary literals.  I'd be happy to
> hear stronger reasoning in favor of the status quo.
> 
> (additional search keywords: dict constructor, dict literal)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>