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

[Luigi Semenzato]

On Tue, May 3, 2016 at 1:43 PM, Michael Selik <michael.selik at gmail.com> wrote:
> On Tue, May 3, 2016 at 4:00 PM Ethan Furman <ethan at stoneleaf.us> wrote:
>>
>> On 05/03/2016 12:21 PM, Michael Selik wrote:
>> > On Mon, May 2, 2016 at 5:36 PM Luigi Semenzato wrote:
>> >>
>> >> For context, someone ran into this problem in my team at Google (we
>> >> fixed it using pylint). I haven't seen any valid reason (in the bug
>> >> or elsewhere) in favor of these constructor semantics. From the
>> >> discussions I have seen, it seems just an oversight in the
>> >> implementation/specification of dictionary literals.  I'd be happy to
>> >> hear stronger reasoning in favor of the status quo.
>> >
>> > Do you feel that "prefer status quo" is not strong reasoning?

Correct.  In this particular case I think that the change is better.
It is simple, helpful, and doesn't seem to have huge implications (if
any) in terms of documentation.

>> > http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
>>
>> It is not strong enough to prevent every good idea, or Python would be a
>> static language (as in, no more changes except maybe bug fixes).

Correct.

> Of course. I'm no more saying "stop change" than you are saying "all change
> is good". Luigi, as with many who have ideas for new features, appears to be
> trying to shift the burden of proof. I think it's well established that the
> burden of proof (proving it's a good idea) rests on the one advocating
> change.

Which gives me one more opportunity to present this case:

A dictionary literal is a convenient input format for structured data,
and is used as such in many cases, for instance instead of equivalent
JSON, which requires an additional module, an additional parsing step,
and learning an additional syntax (a lot of Python programmers don't
know JSON).  The convenience, however, is hampered by the duplicate
key issue.

Some of the strong points of Python are: 1. easy to learn; 2. does the
right thing in most cases.  It just seems to me that the right thing
here would be to signal duplicate literal keys.

>> > Rob Cliffe mentioned the fact that repeated keyword arguments causes a
>> > syntax error. I see the parallel here, except that keyword arguments
>> > must be valid identifiers. Literal dicts syntactically may have any
>> > expression as the key.
>>
>> Which seems irrelevant to your argument: a duplicate key is a duplicate
>> key whether it's 123 or 'xyz'.
>
> If an expression includes an impure function, then the duplication of
> assignment to that key may have a desirable side-effect.

Yes, this is absolutely true, but probably very rare, and arguably not
a recommendable coding practice, therefore IMO it offers very little
support for the status quo.

>> > Creating a special case for the parser to enforce
>> > uniqueness of number and string literals as keys
>>
>> I'm pretty sure the OP would be happy with uniqueness of keys, whether
>> those keys were string literals, numeric literals, or function objects.
>
> How would you handle an expression that evaluates differently for each call?
> For example:
>
>     {random(): 0, random(): 1}

We discussed this already.  My request only applies to keys that are
literals.  (He's talking about function objects, not function calls.)

>>
>> > seems more trouble than its worth.
>>
>> Maybe.  That is what we are discussing.
>
> Indeed. Let me flip the original request: I'd like to hear stronger
> arguments for change, please. I'd be particularly interested in hearing how
> often Pylint has caught this mistake.

Pylint catches this mistake fine.  But many Python programmers don't
know about pylint either.  For instance, a bunch of hardware engineers
that wrote some python as a driver for a circuit simulator.

Anyway, thank you for making these points.