You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The stubs at the moment look quite buggy indeed! From my reading of the source code, I don't think it's actually the openhook parameter at all that determines whether the object returned is of type FileInput[str] or FileInput[bytes]. Instead, it's the value passed into the mode parameter. (You can see this by looking at the FileInput._readline method, which is called from FileInput.__next__.)
IO modes can be tricky to type in stub files, but it should be possible.
Activity
AlexWaygood commentedon May 22, 2022
The stubs at the moment look quite buggy indeed! From my reading of the source code, I don't think it's actually the
openhookparameter at all that determines whether the object returned is of typeFileInput[str]orFileInput[bytes]. Instead, it's the value passed into themodeparameter. (You can see this by looking at theFileInput._readlinemethod, which is called fromFileInput.__next__.)IO modes can be tricky to type in stub files, but it should be possible.
fileinput: Fix TypeVar usage
`fileinput`: Fix `TypeVar` usage (#7934)