Make sys.stdin/out/err Optional

[The-Compiler]

According to the Python documentation, sys.stdin/out/err can be None: https://docs.python.org/3/library/sys.html#sys.__stderr__

Note: Under some conditions stdin, stdout and stderr as well as the original values __stdin__, __stdout__ and __stderr__ can be None. It is usually the case for Windows GUI apps that aren’t connected to a console and Python apps started with pythonw.

To work properly in those scenarios, code should be aware of that and check them against None before using them.

---

FWIW I'm not 100% sure this is a good idea - it's more correct and would've prevented my application crashing in that scenario - but at the same time, it makes things harder for people who just don't care about that scenario.

[srittau]

Related: #3225. I'm normally a proponent of the stubs following the implementation as closely as possible. In this case, though, even simple things like print("...", file=sys.stderr) would need an assertion.

[The-Compiler]

In this case, though, even simple things like print("...", file=sys.stderr) would need an assertion.

Why so? The file argument to print is defined as Optional[_Writer].

[srittau]

Good point, I didn't know that. Still, I'd like some more feedback on this from people with big code-bases.

[The-Compiler]

Agreed! It's tricky to say what the implications are, so treat this as an RFC for now.

[JukkaL]

I believe that this will require too many assertions to be worth it.

This would also cause problems with code that does things like sys.stdout.flush(), sys.stderr.write(...) or sys.stdin.readlines(). These are quite common, and typical code I've seen never checks if some of the streams are None. I was able to find about 700 cases like this in an internal codebase.

(Brainstorming: If stubs had a concept that we could call "strict mode", the streams could be made conditionally optional in the strict mode, and left as they are in the default mode. Maybe some functions that currently return Any could also be declared to return union types instead in this strict mode.)

[gvanrossum]

Yeah, we just can't do this. Feel free to continue the conversation in an issue.

[Michael0x2a]

If stubs had a concept that we could call "strict mode", the streams could be made conditionally optional in the strict mode

Could be another possible use case for PEP 593 annotated types?

E.g. maybe something like stdin: Annotated[TextIO, ExactType(Optional[TextIO])] or some such.

[ilevkivskyi]

Could be another possible use case for PEP 593 annotated types?

Potentially yes. But I think we need more examples before making this a supported pattern/annotation.