[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, 'a

[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 @gregory.p.smit

[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. Ple

[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

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 ___

[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 ___

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

Changes by Benjamin Peterson : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[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 mu

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

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[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: >>> d

[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 module-loading

[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. It