<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 3, 2016 at 4:00 PM Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/03/2016 12:21 PM, Michael Selik wrote:<br>
> On Mon, May 2, 2016 at 5:36 PM Luigi Semenzato wrote:<br>
>><br>
>> For context, someone ran into this problem in my team at Google (we<br>
>> fixed it using pylint). I haven't seen any valid reason (in the bug<br>
>> or elsewhere) in favor of these constructor semantics. From the<br>
>> discussions I have seen, it seems just an oversight in the<br>
>> implementation/specification of dictionary literals.  I'd be happy to<br>
>> hear stronger reasoning in favor of the status quo.<br>
><br>
> Do you feel that "prefer status quo" is not strong reasoning?<br>
> <a href="http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html" rel="noreferrer" target="_blank">http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html</a><br>
<br>
It is not strong enough to prevent every good idea, or Python would be a<br>
static language (as in, no more changes except maybe bug fixes).<br></blockquote><div><br></div><div>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 <span style="line-height:1.5">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.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Rob Cliffe mentioned the fact that repeated keyword arguments causes a<br>
> syntax error. I see the parallel here, except that keyword arguments<br>
> must be valid identifiers. Literal dicts syntactically may have any<br>
> expression as the key.<br>
<br>
Which seems irrelevant to your argument: a duplicate key is a duplicate<br>
key whether it's 123 or 'xyz'.<br></blockquote><div><br></div><div>If an expression includes an impure function, then the duplication of assignment to that key may have a desirable side-effect.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Creating a special case for the parser to enforce<br>
> uniqueness of number and string literals as keys<br>
<br>
I'm pretty sure the OP would be happy with uniqueness of keys, whether<br>
those keys were string literals, numeric literals, or function objects.<br></blockquote><div><br></div><div>How would you handle an expression that evaluates differently for each call? For example:</div><div><br></div><div>    {random(): 0, random(): 1}</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> seems more trouble than its worth.<br>
<br>
Maybe.  That is what we are discussing.<br></blockquote><div><br></div><div><span style="line-height:1.5">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.</span><br></div></div></div>