Quitting interactive help when started without call duplicates prompt

[schuelermine]

Bug report

Bug description:

When exiting interactive help after starting it without calling help, i.e. just typing help on the prompt and hitting enter, the next prompt is duplicated.

Python 3.13.0b4 (main, Jul 18 2024, 09:41:38) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> help
>>> Welcome to Python 3.13's help utility! If this is your first time using
Python, you should definitely check out the tutorial at
https://docs.python.org/3.13/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To get a list of available
modules, keywords, symbols, or topics, enter "modules", "keywords",
"symbols", or "topics".

Each module also comes with a one-line summary of what it does; to list
the modules whose name or summary contain a given string such as "spam",
enter "modules spam".

To quit this help utility and return to the interpreter,
enter "q", "quit" or "exit".

help> quit

You are now leaving help and returning to the Python interpreter.
If you want to ask for help on a particular object directly from the
interpreter, you can type "help(object)".  Executing "help('string')"
has the same effect as typing a particular string at the help> prompt.
>>> >>> 

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-123024: Correctly prepare/restore around help and show-history commands #124485
• [3.13] gh-123024: Correctly prepare/restore around help and show-history commands (GH-124485) #129155

[schuelermine]

I have tested with 3.13.0rc1 as well, and the same behaviour occurs.

[picnixz]

Not sure if it's a duplicate or a special case of #121584 (or just if it's related).

cc @pablogsal since this issue is quite important (I also encountered it but thought it was already known...)

[pablogsal]

Thanks for the ping @picnixz. @ambv and I will look into this but although we take all issues seriously, this is not a security concern not a regression in some critical behaviour neither it impacts production workflows so I wouldn't say this issue is "important" (or at least more than any other REPL issue). I am only mentioning this to remark that we only have a finite amount of time so we need to prioritise all the issues (PyREPL and others) so this may take a while for us to tackle.

[picnixz]

Don't worry! (I shouldn't have said "important" though). Since I've got some time, I can also look at it and see if I can solve this issue.

[picnixz]

So, after some investigation the issue seems that some PS* string is printed. However I observed the following:

• Press F1 for help and then press q -> no duplication.
• Write help and then press q -> duplication -> press enter -> normal prompt.

It appears that the prompt is already put after we exit the help. As if it was always there. And I think the real position of the cursor is actually after that (I mean on the console). So when you prompt it a second time (after exiting the help), you'll paint it after the prompt that exists. This can be verified by using self.error and de-commenting the method in readline.py. There will be overlapping text.

One solution (but I'm not sure it's entirely portable) is to always clear the line after exiting the prompt before repainting over it. By the way, I don't know if it's already been reported but pressing ENTER when being in help is equivalent to exiting it (instead of just being a no-op) (I'm just noting it down here to remember).

[saucoide]

Not sure if it's a duplicate or a special case of #121584 (or just if it's related).

It's mentioned in that one together with a few other things (which maybe i should have split into different issues :) ) but it was more looking at the nesting of help-modes than the duplicated prompts anyway

btw it also happens when you enter/exit history repeatedly: F2 + q + F2 + q so it's not just for help, looks like coming back to the prompt always adds a >>> to whatever existed previously

[picnixz]

Yes, that's what I observed. I think that the cursor is not at the correct position and when we write the prompt we don't overwrite the previous prompt (and even if we did, we should probably first clear the line)