[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Jonathan Fine added the comment: 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,

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Rémi Lapeyre added the comment: 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

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Jonathan Fine added the comment: 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.

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Gregory P. Smith added the comment: Raising an error on duplicates also has precedent: >>> dict(a=3, b=4, a=5) File "", line 1 SyntaxError: keyword argument repeated -- nosy: +gregory.p.smith ___ Python tracker

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Raymond Hettinger added the comment: FWIW, I agree with this rejection. -- nosy: +rhettinger stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Lukas Lueg added the comment: 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__ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

R. David Murray added the comment: 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.

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Lukas Lueg added the comment: 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

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Benjamin Peterson added the comment: 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:

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___ ___ Python-bugs-list mailing list

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Terry J. Reedy added the comment: (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

[issue16385] evaluating literal dict with repeated keys gives no warnings/errors

Changes by Benjamin Peterson benja...@python.org: -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16385 ___