F1 help mode in the REPL

Bug report

Bug description:

I've recently discovered F1 key bind to enter help mode in the REPL and found some problems:

1. Pressing F1 multiple times will "stack" help modes. If you press F1 3 times, you now have to exit 3 times.

2. Whatever the buffer is, help mode will write immediately past the buffer:

   

3. If you press F1 while tab-completing, help banner will glitch on top of the overlay and then the overlay will leak into help mode:

   

4. If you enter paste mode (F3), enter help mode (F1), leave paste mode (F3), leave help mode (exit), you get back to paste mode (expected prompt mode). This looks similar to a lock ordering deadlock.

   If you enter help mode with help and then enter and leave paste mode, this doesn't happen and we're correctly back at prompt mode.

   There might be more edge cases to this (prompt strings getting confused, etc.).

F1 is not a suggested feature anywhere in the REPL (unless you, well, type help and read about F1 there), so it is very likely that people don't know it exists. I only found that it was mentioned in https://docs.python.org/3/whatsnew/3.13.html#a-better-interactive-interpreter and https://peps.python.org/pep-0762/.

We could build guardrails that F1 isn't re-entrant and is pressed at the right moment (which could be challenging to do from the UX perspective because error reporting overlays are disabled by default at the runtime level), but I'm not sure if it is worth the complexity.

The F1 binding appears to provide limited user value (help exists already) while introducing many state-management edge cases. I think the easiest fix to all these issues is to remove the ability to press F1 entirely.

The welcome banner always suggested typing help for help (typing help is the same--resorts to _sitebuiltins._Helper()--except help> isn't colorized then).

Unless F1 is worth keeping?

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

• gh-121668