Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.7k
Description
Bug report
Bug description:
To reproduce:
- The new REPL
❯ PYTHONSTARTUP=<(echo'raise SystemExit') ./pythonPython 3.15.0a3+ (heads/main:5b5263648f2, Dec 20 2025, 07:19:41) [GCC 15.2.1 20250808 (Red Hat 15.2.1-1)] on linuxType"help","copyright","credits" or"license"for more information.
- The basic REPL
❯ PYTHON_BASIC_REPL=1 PYTHONSTARTUP=<(echo'raise SystemExit') ./pythonPython 3.15.0a3+ (heads/main:5b5263648f2, Dec 20 2025, 07:19:41) [GCC 15.2.1 20250808 (Red Hat 15.2.1-1)] on linuxType"help","copyright","credits" or"license"for more information.
(both actually hit the same code path --Py_RunMain ->pymain_run_python ->pymain_run_stdin ->pymain_run_startup ->_PyRun_SimpleFileObject ->PyErr_Print ->PyErr_PrintEx ->_PyErr_PrintEx ->handle_system_exit)
While this is largely an edge case of the regular REPLs, copying this semantics just feels wrong in Python code.
I've run into this while addingPYTHONSTARTUP exception handling to the asyncio REPL inGH-140288.
Should I be keeping asyncio REPL in parity with Python-side REPLs behavior in this regard?
Do we want to fix this in the C code?
And lastly, as part of this issue we would document the exception handling ofPYTHONSTARTUP.
@ZeroIntensitystdlibinterpreter-coredocstopic-repl3.133.143.15
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux