Can't infer type of `fileinput.input()` iterator

[Molkree]

Describe the bug
Pyright can't infer the type of fileinput.input() iterator, it infers to Unknown. Present since 1.2.247.

To Reproduce
Check provided code below.

Expected behavior
AnyStr@input type inferred? It was the behaviour before 1.1.247.

Screenshots or Code

import fileinput

for line in fileinput.input():  # line is Unknown
    pass

Tooltip on function in VS Code shows the correct type. 😅

VS Code extension or command-line
I usually run it as part of Pylance but just for the sake of this issue have installed Pyright as a separate extension and confirmed the same (still present in 1.1.248 which is newer than the latest Pylance release).

Additional context
It doesn't seem like something caused by updated typeshed stubs because the last time this module was touched in typeshed was a month ago, many Pyright versions ago.

[JelleZijlstra]

Not sure what changed in pyright, but the stubs appear to be wrong here: https://github.com/python/typeshed/blob/6e18441a2c1e5836eca4e6763a9590d2b9270378/stdlib/fileinput.pyi#L32.

Only the openhook argument constrains the TypeVar, but it has a default, and if the argument is not given there's nothing for the type checker to use to decide on the value of the TypeVar. The typeshed stub should be changed to add a separate overload where openhook is not given.

[erictraut]

I've made changes recently in the handling of TypeVars that go unsolved when a call expression is evaluated. In previous versions, such TypeVars often "leaked" outside of the call. With recent changes, I've added logic to change these to Unknown types in many cases.

I say "many cases" because there are heuristics that handle some edge cases specially. For example, if the return type is annotated as T | str and T is unsolved, pyright evaluates the result as just str rather than Unknown | str.

Unsolved TypeVars are also still allowed to "leak" if the return result is a Callable because these TypeVars can be solved in the context of a call to the resulting Callable.

I agree with Jelle that the right solution here is to improve the type stub to prevent the TypeVar from going unsolved when the optional argument is not provided.

Perhaps it would be worthwhile to add a rule that checks for a TypeVar used only in parameters that have default arguments? This would help catch these problems in typeshed.

[JelleZijlstra]

Perhaps it would be worthwhile to add a rule that checks for a TypeVar used only in parameters that have default arguments? This would help catch these problems in typeshed.

I was going to suggest the same thing, it would be great if pyright could flag this.

[erictraut]

I've filed a separate feature request to track that.

@Molkree, I'm going to close this issue because I think pyright is doing the right thing here. Feel free to file a bug (or a PR) in typeshed. Pyright frequently picks up new versions of stubs from typeshed.

[Molkree]

@Molkree, I'm going to close this issue because I think pyright is doing the right thing here. Feel free to file a bug (or a PR) in typeshed. Pyright frequently picks up new versions of stubs from typeshed.

Sure, I've opened an issue in the typeshed repo.