gh-141615: Check stdin instead of stdout for use_rawinput in pdb

[gaogaotiantian]

• Issue: pdb checks stdout, instead of stdin for use_rawinput #141615

[gaogaotiantian]

Maybe I'm crazy but @iritkatriel could you double check this? It's very hard for me to believe this has been in our code base for 20 years.

[iritkatriel]

Yeah, I guess nobody tried it.

I was able to reproduce the bug and see that this PR fixed it.

Cam you think of anything that used to work and will not with this change?

[gaogaotiantian]

There are some very theoretical and artificial behavior changes.

For example, if the code used the default stdin, but a customized out, the prompt would now be passed to stdout instead of customized out now - which is the correct behavior. Also the completer would work properly now.

I think the key is - pdb does not do much with the stdin and stdout argument - it just passes them to the underlying cmd.Cmd.

I think this is just a typo and it does not quite make sense to determine whether to use raw input based on stdout.

[iritkatriel]

I agree, it's a big fix. But I think worth a whatsnew entry in case someone is surprised by something.

[gaogaotiantian]

This feels like really minor to be put on whatsnew. I doubt if anyone is affected by this. To be honest, if someone is using it, we should've gotten a bug report in the last 20 years...

[gvanrossum]

Are you all sure? The way I see it, since input("prompt") writes to sys.stdout and reads from sys.stdin, it makes sense to suppress this behavior when stdout is not sys.stdout. So ideally it should check for stdin is None and stdout is None. Right?

Not that I fully understand pdb.py any more... There are many calls to input() that aren't protected for a check for use_rawinput.

[gaogaotiantian]

I actually thought about that. The reason I did not convince myself is this:

If you want a given stdin to be used, make sure to set the instance’s use_rawinput attribute to False, otherwise stdin will be ignored.

But now that @gvanrossum mentioned it, I took a look at the docs of use_rawinput:

A flag, defaulting to true. If true, cmdloop() uses input() to display a prompt and read the next command; if false, sys.stdout.write() and sys.stdin.readline() are used. (This means that by importing readline, on systems that support it, the interpreter will automatically support Emacs-like line editing and command-history keystrokes.)

FIrst of all, it's obviously wrong about sys.stdout, it should be self.stdout (or the provided stdin, stdout) - I can fix it later. But from this docs, it seems like checking both stdout and stdin might make sense.

However, I'm still not 100% convinced. Let's say we are using the real keyboard as stdin, and we are trying to redirect the output data to a different out. Would it make more sense to have a prompt showing on my screen to "prompt" me for typing, or to send the prompt to the out channel and leave me an empty screen? Is the latter more intuitive than the former?

[gvanrossum]

I see. It is indeed defensible that with stdin=None, stdout=<something> we would want the prompt to be written to the console even though stdout doesn't go there -- the prompt is somewhat ephemeral and deserves to be shown when reading from sys.stdin (using input()). The behavior of writing the prompt somewhere that may not be seen on the console but reading from the console is confusing for the user.

So I will approve your change.

[gaogaotiantian]

Thanks. I'll leave this PR open for a day or two and see if anyone objects this.