You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Preserve command-line history after interpreter crash #127495
When the CPython interpreter crashes - recent history entries are lost. An easy reproducer (on any Linux):
$ ulimit -v $((1024*256))
$ pip install -q gmpy2
$ python # started with empty history
Python 3.14.0a2+ (heads/main:e2713409cf, Dec 2 2024, 07:50:36) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gmpy2 import mpz
>>> mpz(2222222222222211111111122222222222222)**33322222
GNU MP: Cannot allocate memory (size=503998640)
Aborted
$ python # history is empty, again :(
...
That "works" both in the old repl and in the new repl. Sometimes you even can't recover all session from the terminal screen.
IMO, if it's a feature - it's a misfeature. I would expect, that all entered input will be preserved in the history. Or such behavior can be optionally turned on. BTW, this feature "doesn't work" in the IPython shell.
I'm wondering if this has something to do with bash. I'm not sure what processing the python-shell does when it is interrupted, but the handling of history is in bash.
No, it's not about bash at all, it's history is fine in the given example. It's all about python repl (>>> ) history.
The shell session shown here just to demonstrate a close-to-real-life example (extension doesn't handle well out of memory condition and abort the python interpreter process). But you could just do kill -SIGABRT <python interactive interpreter> (or it's analog in Windows).
I seem to understand that you may need a file similar to .history to store the history of the previous pyrepl. Even if the interpreter crashes, it can be restored through the file.
Or similar methods to recover the loss of records caused by crashes.
I seem to understand that you may need a file similar to .history to store the history of the previous pyrepl.
There's .python_history already, which normally stores the history. The issue is that it's written at interpreter exit, which doesn't happen in case of a crash (or os._exit()):
@pablogsal, I'm on the right way? BTW, as noted in the description: I think it's rather a bug than the feature request. The IPython shell e.g. keeps history well.
Can you do a quick check of whether it impacts performance by pasting a long block of e.g. a = "a" * 100 lines? If it's writing to the history file once per line (not sure it is), it might slow things down (which probably isn't a big issue for the REPL use case).
If there's a significant impact, it might be better to write history when a new history entry is created, as IIUC it would only write once for the whole long block.
Activity
rruuaanng commentedon Dec 2, 2024
I'm wondering if this has something to do with bash. I'm not sure what processing the python-shell does when it is interrupted, but the handling of history is in bash.
skirpichev commentedon Dec 2, 2024
No, it's not about bash at all, it's history is fine in the given example. It's all about python repl (
>>>) history.The shell session shown here just to demonstrate a close-to-real-life example (extension doesn't handle well out of memory condition and abort the python interpreter process). But you could just do
kill -SIGABRT <python interactive interpreter>(or it's analog in Windows).rruuaanng commentedon Dec 2, 2024
I seem to understand that you may need a file similar to
.historyto store the history of the previous pyrepl. Even if the interpreter crashes, it can be restored through the file.Or similar methods to recover the loss of records caused by crashes.
skirpichev commentedon Dec 2, 2024
Perhaps. I was planning to work on the issue, but I've no review-ready patch yet. Let me know if you would like to work on this.
rruuaanng commentedon Dec 2, 2024
I'm not going to deal with that, feel free to do so. But I will take this opportunity to learn pyrepl :)
devdanzin commentedon Apr 8, 2025
There's
.python_historyalready, which normally stores the history. The issue is that it's written at interpreter exit, which doesn't happen in case of a crash (oros._exit()):cpython/Lib/site.py
Lines 578 to 586 in 53908bd
skirpichev commentedon Apr 8, 2025
This patch works for me:
@pablogsal, I'm on the right way? BTW, as noted in the description: I think it's rather a bug than the feature request. The IPython shell e.g. keeps history well.
devdanzin commentedon Apr 8, 2025
Can you do a quick check of whether it impacts performance by pasting a long block of e.g.
a = "a" * 100lines? If it's writing to the history file once per line (not sure it is), it might slow things down (which probably isn't a big issue for the REPL use case).If there's a significant impact, it might be better to write history when a new history entry is created, as IIUC it would only write once for the whole long block.
skirpichev commentedon Apr 8, 2025
It already on that way: writing is not per-line, but per history entry.
On another hand, using something like
readline.append_history_file()would be better, of course.Edit:
Version with append_history_file() to play with
pythongh-127495: append to history file after every successful statem…
skirpichev commentedon Apr 9, 2025
PR is ready to review: #132294
skirpichev commentedon Apr 11, 2025
Related d.p.o thread: https://discuss.python.org/t/better-pyrepl-history-file-format/87918
gh-127495: Append to history file after every statement in PyREPL (GH…