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

Ethan Furman ethan at stoneleaf.us
Wed May 4 08:42:47 EDT 2016

On 05/04/2016 02:48 AM, Paul Moore wrote:

> The problem is that it could also break code that works at the moment.
> Consider a mapping of constants to names:
> colors = {
>      RED: "Red",
>      BLUE: "Blue",
>      PINK: "Pink",
>      LIGHT_BLUE: "Light Blue",
>      DARK_BLUE: "Dark Blue",
> }
> On a certain output device, there may be no "light blue", and in that
> case the code sets LIGHT_BLUE = BLUE. That's entirely reasonable, and
> the author may be perfectly happy with the current behavior in that
> case.

Actually, that code is setting BLUE = "Light Blue".  ;)

> So I think it's important for backward compatibility that this change
> be *only* for the case of literal values as keys (which is what the OP
> proposed, of course). And given that it needs to just be for literal
> values as keys, I personally think that makes it a case of "Special
> cases aren't special enough to break the rules", so I'm -0 on the
> proposal (I don't think it's a *bad* thing, in the constants-only
> form, just that it's not worth the effort - but if someone else makes
> the effort, I won't object).

I object.  Having only /some/ duplicates checked for is overcomplicating 
without very good reason.

Perhaps the way forward is to check for all duplicates, but issue a 
Warning instead of raising an Exception?

To be honest, though, I'm starting to agree with Steven D'Aprano that 
sufficiently large dicts should be verified by other means, and those 
other means can also check for duplicates.


More information about the Python-ideas mailing list