Are dicts supposed to raise comparison errors

Robin Becker robin at reportlab.com
Wed Aug 1 04:36:16 EDT 2018


On 31/07/2018 16:52, Chris Angelico wrote:
> On Wed, Aug 1, 2018 at 1:28 AM, MRAB <python at mrabarnett.plus.com> wrote:
>> On 2018-07-31 08:40, Robin Becker wrote:
>>>
>>> A bitbucket user complains that python 3.6.6 with -Wall -b prints warnings
.............
>> The warning looks wrong to be.
>>
>> In Python 2, u'a' and b'a' would be treated as the same key, but in Python 3
>> they are distinct and can co-exist.
>>
>> Something for Python's bug tracker, I think!
> 
> It's a warning specifically requested by the -b option. The two keys
> in question have the same hash, which means they have to be compared
> directly; they will compare unequal, but because of the -b flag, the
> comparison triggers a warning. If that warning is spurious, *don't use
> the -b option*.
> 
> ChrisA
> 

I looked at the language documentation for 3.7 mappings

> These represent finite sets of objects indexed by nearly arbitrary values. The only types of values not acceptable as keys are values containing lists or dictionaries or other mutable types that are compared by value rather than by object identity, the reason being that the efficient implementation of dictionaries requires a key’s hash value to remain constant. Numeric types used for keys obey the normal rules for numeric comparison: if two numbers compare equal (e.g., 1 and 1.0) then they can be used interchangeably to index the same dictionary entry.



it says explicitly that numeric keys will use numeric comparison, but no mention is made of strings/bytes etc etc and there's an 
implication that object identity is used rather than comparison. In python 3.x b'a' is not the same as 'a' either the 
documentation is lacking some reference to strings/bytes or the warning is wrong. Using the excuse that normal comparison is being 
used seems a bit feeble. It would clearly improve speed if object identity were to be used, but I suppose that's not the case for 
other reasons.
-- 
Robin Becker




More information about the Python-list mailing list