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

[Michael Selik]

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

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.


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


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


> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160503/982742a8/attachment-0001.html>