Are dicts supposed to raise comparison errors

[Steven D'Aprano]

On Wed, 01 Aug 2018 16:22:16 +0100, Paul Moore wrote:

> On Wed, 1 Aug 2018 at 16:10, Robin Becker <robin at reportlab.com> wrote:
>>
>> On 01/08/2018 14:38, Chris Angelico wrote:
>> > t's a warning designed to help people port code from Py2 to Py3. It's
>> > not meant to catch every possible comparison. Unless you are actually
>> > porting Py2 code and are worried that you'll be accidentally
>> > comparing bytes and text, just*don't use the -b switch*  and there
>> > will be no problems.
>> >
>> > I don't understand what the issue is here.
>>
>> I don't either, I have never used the  -b flag until the issue was
>> raised on bitbucket. If someone is testing a program with reportlab and
>> uses that flag then they get a lot of warnings from this dictionary
>> assignment. Probably the code needs tightening so that we insist on
>> using native strings everywhere; that's quite hard for py2/3 compatible
>> code.
> 
> They should probably use the warnings module to disable the warning in
> library code that they don't control, in that case.
> 
> If they've reported to you that your code produces warnings under -b,
> your response can quite reasonably be "thanks for the information, we've
> reviewed our bytes/string handling and can confirm that it's safe, so
> there's no fixes needed in reportlab".

I'm sorry, I don't understand this reasoning. (Perhaps I have missed 
something.) Robin says his code runs under both Python2 and Python3. He's 
getting a warning that the behaviour has changed between the two, and 
there's a dubious comparison being made between bytes and strings. 
Consequently, there's a very real chance that he has a dicts which have 
one key in Python 2 but two in Python 3:

- in Python 2, b'x' and u'x' are the same key;

- in Python 3, b'x' and u'x' are different keys;


# Python 2
py> {u'x': 1, b'x': 2}
{u'x': 2}


#Python 3
py> {u'x': 1, b'x': 2}
{b'x': 2, 'x': 1}


This means that Robin very likely has subtly or not-so-subtly different 
behaviour his software depending on which version of Python it runs 
under. If not an outright bug that silently does the wrong thing.

Even if Robin has audited the entire code base and can confidently say 
today that despite the warning, no such bug has manifested, he cannot 
possibly be sure that it won't manifest tomorrow. (Not unless the 
software is frozen and will never be modified.)


In another post, Chris says:

    I suspect that there may be a bit of non-thinking-C-mentality
    creeping in: "if I can turn on warnings, I should, and any
    warning is a problem". That simply isn't the case in Python.

I strongly disagree. Unless Chris' intention is to say bugs don't matter 
if they're written in Python, I don't know why one would say that 
warnings aren't a problem.

Every warning is one of three cases:

- it reveals an existing actual problem;

- it reveals a potential problem which might somebody become 
  an actual problem;

- or it is a false positive which (if unfixed) distracts 
  attention and encourages a blasé attitude which could
  easily lead to problems in the future.


Warnings are a code smell. Avoiding warnings is a way of "working clean":

https://blog.codinghorror.com/programmers-and-chefs/


Ignoring warnings because they haven't *yet* manifested as a bug, or 
worse, because you *assume* that they haven't manifested as a bug, is 
about as sensible as ignoring the oil warning light on your car because 
the engine hasn't yet seized up. Regardless of which language the 
software is written in.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson