On Tue, May 3, 2016 at 4:00 PM Ethan Furman <ethan@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.