Should PYI041 consider bool to be redundant with int?

[tylerlaprade]

Currently, this rule only flags int | float unions as redundant. Coming from other languages, I didn't even realize int was a subtype of float, but I learned about it because of this rule. However, I found a bug in my code where I was converting False to 0.0 - this was because in Python, bool is actually an int. I found that the tests for this rule very explicitly consider int | bool to not be a violation, however this would have prevented me from writing the bug as I did.

The bool to int relation is in some ways stronger than int to float since isinstance() only recognizes the former:

[charliermarsh]

@AlexWaygood - I defer to you on this one.

[zanieb]

I don't think this makes sense to me, they seem more distinct than int / float regardless of the isinstance behavior. I'm curious to hear more opinions though!

[tylerlaprade]

To me, they're very different in intended usage, but surprisingly related in actual effect, which threw me off, especially since the rule warned about the other scenario and not this one.

[maxyz]

I just stumbled into this rule, and I think the rule is wrong.

The PEP mentioned in the rule documentation ( PEP 3141 ) is talking about the numbers ABCs, these are, numbers.Complex, numbers.Real and numbers.Integral.

float is a particular class that implements numbers.Real, int is a particular class that implements. But they don't have a relationship between them.

Afaik, the numerical hierarchy defined in the pep-3141 can be seen/tested using:

import numbers

i = 1
f = 1.0

isinstance(i, int) # True
isinstance(i, float) # False

isinstance(f, int) # False
isinstance(f, float) # True

isinstance(i, numbers.Complex) # True
isinstance(i, numbers.Real) # True
isinstance(i, numbers.Integral) # True

isinstance(f, numbers.Complex) # True
isinstance(f, numbers.Real) # True
isinstance(f, numbers.Integral) # False

Am I missing something?

[AlexWaygood]

I just stumbled into this rule, and I think the rule is wrong.

The PEP mentioned in the rule documentation ( PEP 3141 ) is talking about the numbers ABCs, these are, numbers.Complex, numbers.Real and numbers.Integral.

The rule isn't wrong @maxyz, but you're right that it's quite misleading for the docs to mention PEP 3141. The rule is premised on the fact that type checkers do not support PEP 3141 (and never will) -- the ABCs introduced by that PEP are wholly incompatible with Python's static-typing system and impossible to annotate in a desirable way in typeshed.

For more, see:

• https://stackoverflow.com/questions/69334475/how-to-hint-at-number-types-i-e-subclasses-of-number-not-numbers-themselv/69383462#69383462
• int is not a Number? python/mypy#3186
• https://discuss.python.org/t/numeric-generics-where-do-we-go-from-pep-3141-and-present-day-mypy/17155
• Add more return types to the numbers module python/typeshed#11353
• Further improve return types in the numbers module python/typeshed#11375

The "numeric tower" that the docs should be linking to is this one here: https://peps.python.org/pep-0484/#the-numeric-tower. (If you think this situation is confusing, you're not alone :)

I'll make a docs PR to improve this situation.