v1.1.329 incorrectly assuming type of a division is an int

[btalb]

In v1.1.328 this would pass linting:

(11 / 5).is_integer()

In v1.1.329 it fails with this error:

  debug.py:1:9 - error: Cannot access member "is_integer" for type "int"
    Member "is_integer" is unknown (reportGeneralTypeIssues)

The release notes suggest some changes here, but just want to confirm this isn't a bug. I can make it go away with something like:

float(11 / 5).is_integer()

But this seems like changing code for the sake of the linter given I can't see any case where the type will actually be an int? e.g.:

In [11]: type(2/1)                                                  
Out[11]: float

[erictraut]

One minor point of semantics... Pyright isn't a linter. It's a type checker. Linters (like pylint and ruff) enforce coding conventions and style. Type checkers (like pyright and mypy) enforce a type consistency rules.

Now, to the issue at hand... This is intended behavior, not a bug. PEP 484 indicates that the type annotation float implies both float and int (effectively, float | int) even though int is not an actual subclass of float. This means if you have a value whose type is annotated as float, you cannot safely call a method that is defined for the float class if it is not also defined for the int class. This doesn't come up often because most methods that are available on float are also available on int, but there are a few exceptions. The method is_integer is one such exception — at least prior to Python 3.12, which adds this method to int.

Versions of pyright prior to 1.1.329 did not catch this class of errors. Version 1.1.329 now enforces this type rule, catching a class of potential bugs that were previously undetected.

The __truediv__ method in the class int is defined as follows:

class int:
    ...
    def __truediv__(self, __value: int) -> float: ...

That means the expression 11 / 5 evaluates to float, which type checkers must assume can be either a float or an int even if the runtime limits the answer to only float. Unfortunately, there's currently no way in the Python static type system to specify in a type annotation that a value is a float but not an int, so there's no way to properly annotate the return type of int.__truediv__.

You can guarantee to a type checker that you're talking about a float and not an int by directly calling the float constructor, as you've discovered.

So, your options to work around this issue:

1. Upgrade to Python 3.12, which provides an is_instance method for the int class.
2. Call the float constructor, as you've done in your code sample above.
3. Use a # type: ignore or # pyright: ignore comment at the end of the line to suppress the type error.

[btalb]

Nice. That makes perfect sense. Thanks for the great answer @erictraut !

[benjamind2330]

I am also experiencing this issue. However, i have made a script:

debug.py

float(11 / 5).is_integer()

(1.2).is_integer()

The result from pyright is:

pyright debug.py 
debug.py
  debug.py:1:15 - error: Cannot access member "is_integer" for type "int"
    Member "is_integer" is unknown (reportGeneralTypeIssues)
  debug.py:3:7 - error: Cannot access member "is_integer" for type "int"
    Member "is_integer" is unknown (reportGeneralTypeIssues)
2 errors, 0 warnings, 0 informations 

This is with:

pyright --version
pyright 1.1.329

I think this must be a bug right?

[erictraut]

@benjamind2330, thanks for your post. Yes, pyright should be able to tell in those two cases that the resulting object is definitively an instance of float rather than some value that is in the set of types described by float | int. This is somewhat different than the original bug report, but it's related. I've reopened the issue and will address this in the next release.

[erictraut]

This is addressed in pyright 1.1.330, which I just published. It will also be included in an upcoming release of pylance.