Pyright fails to find type error if argument uses a high exponent

[ottumm]

Describe the bug
When an expression involving an integer and a high exponent (e.g. 2**31) is passed into a function expecting a non-integer type, Pyright doesn't catch the error. I've tried this with lower exponents (e.g. 2**2) and Pyright does correctly catch the error.

Code or Screenshots

def bar(f: str) -> int:
    ...


bar(2**31)

(pyright playground link)

VS Code extension or command-line
Command-line, version 1.1.361, strict mode on.

[ottumm]

It appears this is because 2**31's type is being inferenced as Any.

[erictraut]

Yes, this behavior is correct based on the typeshed stub for int.__pow__. It has several overloads, but the fallback overload used in this case is:

    def __pow__(self, value: int, mod: None = None, /) -> Any: ...

[erictraut]

Closing because pyright is doing the right thing here given the type information it's provided.

[ottumm]

I've found that the cut-off here is 2**26. 2**25's type is inferred as int and 2**26 is inferred as Any. Is it really expected behavior that that is the cut-off?

[ottumm]

If there was an option to prevent Pyright from accepting an Any type when a more-specific type is required, that would also have helped me avoid the bug in this case.

[ottumm]

Also for what it's worth, mypy reports the same example as a type error: https://mypy-play.net/?mypy=latest&python=3.12&gist=4474b98a1574fa206eaab2ee0d05e692

[ottumm]

For future explorers, here are some relevant discussions I found:

• Pow doesn't infer types when variables are used python/mypy#16635
• More improvements to pow stubs python/typeshed#7737 (comment)
• Improve stubs for __pow__ python/typeshed#6287 (comment)
• Mypy's logic for inferring more cases of positive or negative literal exponents

[erictraut]

Pyright is not using type inference in this case. It's applying standard type rules (as specified in the Python typing spec) to type information provided by typeshed stubs.

Mypy provides special-case logic that overrides the type information provided in the typeshed stubs in this instance. That's something I generally don't do in pyright. I've done it a few times in the past, and I've regretted it every time because it leads to compatibility and maintenance issues.

[ottumm]

That makes sense; thank you for the explanation. It seems like the correct place for me to take this up is with typeshed's policy of avoiding union types for return values.