Are dicts supposed to raise comparison errors

[Peter Otten]

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".
> 
> Paul

I've looked into the actual code which has

# paraparser.py
f = isPy3 and asBytes or asUnicode
K = list(known_entities.keys())
for k in K:
    known_entities[f(k)] = known_entities[k]

It looks like known_entities starts out with the default string type, i. e. 
unicode in py3 and bytes in py2. 

While in py2 the code has no effect in py3 it adds the corresponding keys of 
type bytes. However, known_entities is then used in 
HTMLParser.handle_entity_ref(self, name) which passes the name as unicode in 
py3.

I didn't try, but I would suspect that the module keeps working as expected 
when you remove the lines quoted above.

If I'm correct running the program with the -b flag has at least helped in 
cleaning up the code in this case. 

In other cases it might detect sources of bugs, so IMHO it's better to have 
a close look at and possibly rewrite code that triggers the warning rather 
than to disable it.