Looks good to me. I'd like the following questions clarified before we proceed:

• will bracketed pasting avoid appending to history until it's finished? (it should);
• will this work with multiple concurrently open REPLs? (looks like it would, although the written history will be now intermingled, which I guess is better than entirely losing history of the REPL that shut down sooner).

will bracketed pasting avoid appending to history until it's finished? (it should);

history entry will be appended only if the statement was finished. (Well, at least this was an intention and it seems working in the current implementation.)

will this work with multiple concurrently open REPLs? (looks like it would, although the written history will be now intermingled, which I guess is better than entirely losing history of the REPL that shut down sooner).

Good catch, thanks!

I was thinking about multiple repls and this IMO deserve own issue. We can't just write to the same file in a plain text. IPython-like approach seems most sane if we would like to share history file for all repls.

Meanwhile, write_history_file() just save whole stuff, as before. Who will quit later - win.

Edit: "gh-127495: Append to history file after every successful statement in PyREPL" seems to be more correct as a title.

Hmm, it seems the IPython stores statement right before execution. Maybe I should adjust pr to do same?

Meanwhile, write_history_file() just save whole stuff, as before. Who will quit later - win.

Yeah, maybe we shouldn't do write_history_file() anymore since append_history_file() ensures the file is up-to-date as it is? You're right that we can discuss this in a separate issue.

"#127495: Append to history file after every successful statement in PyREPL" seems to be more correct as a title.

"Successful" suggests it executed without an exception. I would want to avoid suggesting too much. In fact, you are asserting that sleep() is in history while it's not a "successful" statement since the process got killed before it finished. Since this doesn't matter much, I think the current wording is less misleading.

Hmm, it seems the IPython stores statement right before execution.

I think that would be overdoing it. It would slow down getting the response from each command. Let's keep it as is.

maybe we shouldn't do write_history_file() anymore since append_history_file() ensures the file is up-to-date as it is?

Yes, it seems working.

One my concern here is that for multiple interpreters history will be interleaved. Maybe it's even better - all entries should be saved, just in some random order.

You're right that we can discuss this in a separate issue.

I opened https://discuss.python.org/t/87918 to discuss more big improvements in history handling.

Since this doesn't matter much, I think the current wording is less misleading.

Yes. I think we should kept more simple wording and just decide if we would like to store statement before (as now) of after it's executed.

I think that would be overdoing it. It would slow down getting the response from each command.

Sure, I'll revert it (unless you had a second thought).

But I think that above concern isn't valid. User can't distinguish this slowdown from time, required to execute and show output. Same will be true if statement will be saved after it's executed (as before). The only real difference: in the later case we might loose last statement (i.e. which crashed the interpreter).

But I think that above concern isn't valid.

It is valid, you just don't see it. When you save the history before execution, the time to save is spent before the command is executed and therefore before the user sees output. When you save the history after execution, the user already sees the output and only then the time to save is spent. So it's only the prompt that returns later.

If your $PYTHON_HISTORY is on a network-connected drive, this will make the execution in the REPL appear slower to the user.

It is valid, you just don't see it.

Maybe) Below my 2c in defense.

When you save the history after execution, the user already sees the output and only then the time to save is spent. So it's only the prompt that returns later.

But user has only one unquestionable signal that the output is complete - it's the new prompt. You can suspect some additional lag, but only if you know how exactly looks like finished output.

I'm not sure if there is a big difference (and compatibility with IPython looks more important to me), but possible lost of history entry seems more severe, than the lag you might guess.