This is not ideal:

>>> if True:
...     
  File "<python-input-2>", line 1
    if True:
            ^
IndentationError: expected an indented block after 'if' statement on line 1
>>>

This is not ideal:

>>> if True:
...     
  File "<python-input-2>", line 1
    if True:
            ^
IndentationError: expected an indented block after 'if' statement on line 1
>>>

This fix is ​​to correctly handle the issue of Ctrl+D to exit multi-line mode. What do you think the expected behavior should be?
@StanFromIreland

@ambv FWIW I tested this PR on my Mac (main branch, latest, MacOS latest) and it works great. I tried throwing a bunch of other unclosed constructs (e.g. {, [, etc.) and none exhibited this error either.

@StanFromIreland Are you suggesting that the error message in the if True: case could be more clear?

The fact that the user isn't supplying a valid indented block after the if True: is indeed a problem the language needs to flag, so I'm curious what specific wording you think might be more clear. Also it seems to me like this could be a separate Github issue. Do you agree?

Looking at those lines again, I would probably refactor to bring the check for self.event[-1] == "\004" out in front, replacing the current if/elif structure with something like the following:

        if self.event[-1] == "\004":
            if b and b[-1].endswith("\n"):
                self.finish = True
            elif (
                r.pos == 0
                and len(b) == 0  # this is something of a hack
            ):
                r.update_screen()
                r.console.finish()
                raise EOFError

I tried looking at the test cases a little bit, but I haven't been able to figure out how best to add the tests yet. What I wanted to test was that the following happens:

• ^D in the middle of a line deletes the current character
• ^D at the end of a nonempty line does nothing
• ^D on a blank line with no preceding lines raises EOFError
• ^D on a blank line with preceding lines runs the code up to that point

I tested that at my own terminal (using the version of the code I pasted above), but I'm not sure the best way to encode that as test cases since multiline_input is unhappy with what I tried to feed it to simulate those cases.

@StanFromIreland, this behavior would be consistent with the pre-3.13 REPL, which is what I think we should be aiming for here.

Looking at those lines again, I would probably refactor to bring the check for self.event[-1] == "\004" out in front, replacing the current if/elif structure with something like the following:

        if self.event[-1] == "\004":
            if b and b[-1].endswith("\n"):
                self.finish = True
            elif (
                r.pos == 0
                and len(b) == 0  # this is something of a hack
            ):
                r.update_screen()
                r.console.finish()
                raise EOFError

I tried looking at the test cases a little bit, but I haven't been able to figure out how best to add the tests yet. What I wanted to test was that the following happens:

• ^D in the middle of a line deletes the current character
• ^D at the end of a nonempty line does nothing
• ^D on a blank line with no preceding lines raises EOFError
• ^D on a blank line with preceding lines runs the code up to that point

I tested that at my own terminal (using the version of the code I pasted above), but I'm not sure the best way to encode that as test cases since multiline_input is unhappy with what I tried to feed it to simulate those cases.

@StanFromIreland, this behavior would be consistent with the pre-3.13 REPL, which is what I think we should be aiming for here.

I tried to make some modifications and add more tests based on what you just said

I tried to make some modifications and add more tests based on what you just said

Thanks! I just tested this out and it feels right to me (at least if the goal is indeed to mimic the behavior of the old pre-3.13 REPL, which I think is the right thing to do here).

Unfortunately I don't have any authority here, but hopefully you'll get some additional code review 🙂

Thanks @deepwzh for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

Sorry, @deepwzh and @ambv, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 81959a0364f5bc15414d5bd61c5c0d019d486fe5 3.14

Sorry, @deepwzh and @ambv, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 81959a0364f5bc15414d5bd61c5c0d019d486fe5 3.13

GH-139850 is a backport of this pull request to the 3.14 branch.

GH-139851 is a backport of this pull request to the 3.13 branch.

Thanks @ambv!