[issue26910] dictionary literal should not allow duplicate keys

[Jonathan Fine]

Jonathan Fine  added the comment:

I mention this issue, and related pages, in
[Python-ideas] dict literal allows duplicate keys
https://mail.python.org/pipermail/python-ideas/2019-March/055717.html

It arises from a discussion of PEP 584 -- Add + and - operators to the built-in 
dict class.

Please send any follow-up to python-ideas (or #16385).

--
nosy: +jfine2358

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26910] dictionary literal should not allow duplicate keys

[R. David Murray]

R. David Murray added the comment:

Since this has been previously rejected, I'm closing this issue as a duplicate.

If you want to reopen the discussion of the merits, the python-ideas mailing 
list is the appropriate forum.  I encourage you to raise it there.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> evaluating literal dict with repeated keys gives no 
warnings/errors

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26910] dictionary literal should not allow duplicate keys

[Luigi Semenzato]

New submission from Luigi Semenzato:

This was already discussed and rejected at https://bugs.python.org/issue16385.  
I am reopening because I am not convinced that the discussion presented all 
arguments properly.

The original problem description:

lives_in = { 'lion': ['Africa', 'America],
 'parrot': ['Europe'],
 #... 100+ more rows here
 'lion': ['Europe'],
 #... 100+ more rows here
   }

The above constructor overwrites the 'lion' entry silently, often causing 
unexpected behavior.

These are the arguments presented in favor of the rejection, followed by my 
rebuttals.

1. "An error is out of the question for compatibility reasons".  No real 
rebuttal here, except I wonder if exceptions are ever made and under what 
circumstances.  I should point out that a warning may also create 
incompatibilities.

2. "There are ways to rewrite this as a loop on a list".  Yes of course, but 
the entire point of the dictionary literal is to offer a concise and convenient 
notation for entering a dictionary as program text.

3. "Being able to re-write keys is fundamental to Python dicts and why they can 
be used for Python's mutable namespaces".  This is fine but it applies to the 
data structure, not the literal constructor.

4. "A code generator could depend on being able to write duplicate keys without 
having to go back and erase previous output".  Yes, but it seems wrong to 
facilitate automated code generation at the expense of human code writing.  For 
hand-written code, I claim that in most (all?) cases it would be preferable to 
have the compiler detect key duplications.  It is easier for an automated code 
generator to check for duplications than it is for a human.

5. "There is already pylint".  True, but it forces an additional step, and 
seems like a cop-out for not wanting to do the "right thing" in the language.

For context, someone ran into this problem in my team at Google.  We fixed it 
using pylint, but I really don't see the point of having these constructor 
semantics.  From the discussions I have seen, it seems just an oversight in the 
implementation/specification of dictionary literals (search keywords: dict 
constructor, dict literal).  I'd be happy to hear stronger reasoning in favor 
of the status quo.

--
components: Interpreter Core
messages: 264657
nosy: Luigi Semenzato
priority: normal
severity: normal
status: open
title: dictionary literal should not allow duplicate keys
type: behavior
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com