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

[Paul Moore]

On 4 May 2016 at 13:42, Ethan Furman <ethan at stoneleaf.us> wrote:
> 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".  ;)

You missed my point, I think. BLUE and LIGHT_BLUE are "constant"
values (set once at the top of the program). In some circumstances,
the programmer deliberately wants BLUE and LIGHT_BLUE to be the same
value (but not in others). The programmer is happy that a constant
BLUE will be decoded as "Light Blue" by the colors mapping in that
case.

This is IMO perfectly valid code, and having it rejected by an
over-zealous "duplicate check" is unacceptable.

As far as I am concerned, this example clearly demonstrates that any
duplicate check should only be applied to actual constant literal
values used as keys.

>> 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?

Warning on perfectly good code is just as obnoxious IMO.

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

As far as I'm aware, the people who have looked at the implementation
details seem to be saying that checking for duplicates on literals
only is too hard to be practical, and that's the only variation I'd be
willing to accept, so I agree - do duplicate checking by other means
(assertions in the code being the obvious option).

Paul