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

Michel Desmoulin desmoulinmichel at gmail.com
Tue May 3 03:22:35 EDT 2016


That would introduce a very weird special case. All those would work:

foo = 1
bar = "1"

{1: True, 2 - 1: True, foo: True, int(bar): True, int("1"): True, **{1:
True}}

But not this:

{1: True, 1: True}

It would be very confusing.

Le 03/05/2016 09:08, Gregory P. Smith a écrit :
> It'd still be possible to do it for literal listed keys only if someone
> wanted to figure out how to do it at parsing time rather than runtime.
> 
> On Tue, May 3, 2016 at 12:06 AM Michel Desmoulin
> <desmoulinmichel at gmail.com <mailto:desmoulinmichel at gmail.com>> wrote:
> 
>     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 <mailto:Python-ideas at python.org>
>     > https://mail.python.org/mailman/listinfo/python-ideas
>     > Code of Conduct: http://python.org/psf/codeofconduct/
>     >
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto:Python-ideas at python.org>
>     https://mail.python.org/mailman/listinfo/python-ideas
>     Code of Conduct: http://python.org/psf/codeofconduct/
> 


More information about the Python-ideas mailing list