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

[Gregory P. Smith]

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>
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
> > 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
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160503/c997cff6/attachment-0001.html>