I normally use dictionaries for configuration purposes in python, but there's a problem where I have a dictionary with many key<->values and one of the keys is repeated.
For example:

lives_in = { 'lion': ['Africa', 'America],
             'parrot': ['Europe'],
             #... 100+ more rows here
             'lion': ['Europe'],
             #... 100+ more rows here
           }

will end up with animal_lives_in['lion'] = 'Europe'. There's no way to detect that I've written a mistake in the code because python won't tell me there's a duplicated key assigned. It's easy to see when you have few keys but hard when you've got many.

I think it should atleast raise a warning when this happens.

This is an unavoidable behaviour of the hash tables (dictionaries)
I don't see much use cases of a warning.

Retract earlier statement. I didn't read the comment fully.

You should be using json for configuration purposes anyway.
This is low priority as only few programs use dictionaries with a gazillion keys.

I would use json, but it allows me to set list/strings, etc.. not python objects like I'd want

sorry: *it only allows me

also, it creates confusion when this happens

It is a nice suggestion, but it is also probably a non-trivial change to the parser.  If you want to try coming up with a patch we would consider it, but I suspect there is a limit to how much complexity we'd be willing to add to the parser code for this.

It would also be a backward incompatible change, so it could only go into a new release regardless.

(On the other hand Benjamin might take a look at this and say "oh, that's easy" and make some magic happen.  You never know :)

This could be avoided by


lives_in_init = (('lion': ['Africa', 'America']), ('lion': ['Europe']))
lives_in = {}
for k, v in lives_in_init:
    assert k not in lives_in
    lives_in[k] = v
del lives_in_init

Which is fast enough if executed only during module-loading

An error is out of the question for compatibility reasons. I think the idea for a warning should be brought up on the python-ideas list. Silently rejecting duplicates has a lot of precedent, though. For example, set literals and the dict constructor:

>>> dict((("dfs", 2), ("dfs", 3)))
{'dfs' : 3}

(Benjamin, did you mean 'silently accepting duplicates'?)

Without more use cases and support (from discussion on python-ideas), I think this should be rejected. Being able to re-write keys is fundamental to Python dicts and why they can be used for Python's mutable namespaces. A write-once or write-key-once dict would be something else.

As for literals, a code generator could depend on being able to write duplicate keys without having to go back and erase previous output. A lint-type code checker program could check for duplicate keys. OP: have you checked to see if PyLint or PyChecker or ... already do this? I think this is the appropriate place for such a thing. Lukas' code could be modified to do this also.

Keeping keys alphabetical (possibly within sections) should also solve this specialized problem.

FWIW, I agree with this rejection.

PyLint or PyChecker can only do this if the keys are all simple objects like ints or strings. Consider a class with a custom __hash__

Raising an error on duplicates also has precedent:

>>> dict(a=3, b=4, a=5)
  File "<stdin>", line 1
SyntaxError: keyword argument repeated

I mention this issue, and related pages, in
[Python-ideas] dict literal allows duplicate keys
https://mail.python.org/pipermail/python-ideas/2019-March/055717.html

It arises from a discussion of PEP 584 -- Add + and - operators to the built-in dict class.

Please send any follow-up to python-ideas (or this issue).

Guido van Rossum said in https://mail.python.org/pipermail/python-ideas/2019-March/055726.html: "this was an explicit design
decision that I made nearly 30 years ago".

I think the best way to avoid silently accepting such values would be to use @gregory.p.smith to use a function call to create the dictionary since duplicate keyword arguments raise an exception there.

I suggest to close this bug report since it works as expected.

This is was closed and tagged as resolved in 2012. The status has not been changed since then.

Using dict(a=1, ...) provides a workaround, but only when the keys are valid as variable names. The general workaround is something like
    helper([
        (1, 'a'),
        (2, 'b'),
        #etc
    ])

The helper is necessary:
>>> [(1, 2)] * 5
[(1, 2), (1, 2), (1, 2), (1, 2), (1, 2)]
>>> dict([(1, 2)] * 5)
{1: 2}