[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