Not sure if anyone has ever thought about this, but it would be nice if the interactive interpreter set the same indentation level as the previous line. Of course this isn't urgent, but what do others think?

I'm not exactly sure what you mean but, since this isn't a bug per se and is more of a subjective opinion on how the REPL should handle the indentation level, you should probably ask *first* on python-ideas to get input from other members. (See https://docs.python.org/devguide/faq.html#suggesting-changes)

I did not mark this as a bug. I marked it as an "enhancement" and I said that the priority was low.

"I'm not exactly sure what you mean"

In an IDE when developing in python, each time you press enter, the cursor is set to the same indentation level as the previous line so that you don't need to type spaces on every new line to return to the same indentation level. I am merely suggesting that the interactive interpreter do the same thing. 

"is more of a subjective opinion"

You are of course correct that this is a subjective opinion. But it's not just my subjective opinion. As I said, it's what nearly every IDE does including (maybe?) the one that you're using.

Posting an idea directly to the issue tracker is fine as long as it's done in a reasonable fashion (i.e. not rudely).

As for the specific idea, I assume this is for the REPL as used in a shell and not in IDLE. If you want to propose a patch that can work cross-platform in both a Windows and UNIX shell where dedenting works consistently then it might be considered.

I hope I haven't been rude; the idea here was to see what the feeling of the core developers was about this idea.

As for the patch, that will probably come after the Python workflow has been fixed because doing it then will save everyone time and as I have said, this is low priority.

No, I don't think you were rude, 12345 67890. I was just giving the standard explanation as some people are not pleasant and you never know who might read this issue later and benefit from the reminder.

Adding at least 'dumb indentation' (repeat last indent) to the REPL would make it at least a bit more usable.  (This still would not be a good as an IDE, like IDLE, that does smarter indentation, such as adding an additional indent after a compound statement header ends with ':'.)

The simplest patch would be to slice and echo the initial whitespace (spaces and tabs) of each line that needs to be followed with a secondary prompt.  What I don't know is whether, on every console, a printed tab always has the same effect as a tab entered by a user.
Testing would be needed.

Thanks for the standard explanation, Brett. I was just following the devguide too strictly and assumed python-ideas is the first place one should go :-).

As for the idea, it seems others wish/wished it too (first paragraph: https://docs.python.org/3/tutorial/interactive.html#alternatives-to-the-interactive-interpreter)

The point I was trying to get at above is that simply printing a prompt and making the use enter the entire line should work on every console, while anything fancier may not be so reliable.  Thinking more, I realize that my patch outline is incomplete. After 'line = input(prompt + indent)', line will not include the indent. A printed indent will have to be added to the input received from the user.  (In IDLE's Shell and editors, the indents that IDLE insert()s into a text widget are indistinguishable from those types by a user and *are* included in the user input that IDLE reads.)  An associated issue is that cross-platform automated tests would be difficult to impossible.

More experiment reveals the fatal problem: in REPL mode, python reads stdin and writes to stdout and stderr.  In the Windows console, and I am sure others, printed output cannot be deleted.  In particular, printed input spaces, such as the one at the end of '>>> ' cannot be deleted.  So dedenting, as in the following example, would not be possible.  One cannot input() a negative string.

if possible:
    print('I like it')
    write_patch()
    test()
else:
    print('too bad')
    reject_idea()

So unless I am wrong, the idea must be rejected.

It probably won't be trivial, but it definitely is possible. Suplemon has the exact functionality needed and it's only dependency is CPython. The only question is: how much code is this going to add?

[1]: https://github.com/richrd/suplemon

In addition, windows allows direct console control via the win32 API and the code for that isn't too lengthy.

Any autoindetation breaks pasting from the clipboard since there is no way to distinguish characters entered from the keyboard from characters pasted from the clipboard. In IDLE or other visual shell we can add a special menu entry and hotkeys for pasting from clipboards without autoindenting, but in a REPL in text terminal this is not possible.

IPython3 solved this issue by adding special magic functions, but this is not a way for CPython.

That one is pretty tricky. The only way that I can think of is to delay indentation until the first character is typed, and not to indent if it is a space or tab. 

From: Serhiy Storchaka
Sent: Wednesday, February 1, 2017 2:39 PM
To: xoviat@gmail.com
Subject: [issue29339] Interactive: Move to same indentation level as previousline

Serhiy Storchaka added the comment:

Any autoindetation breaks pasting from the clipboard since there is no way to distinguish characters entered from the keyboard from characters pasted from the clipboard. In IDLE or other visual shell we can add a special menu entry and hotkeys for pasting from clipboards without autoindenting, but in a REPL in text terminal this is not possible.

IPython3 solved this issue by adding special magic functions, but this is not a way for CPython.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue29339>
_______________________________________

> The only way that I can think of is to delay indentation until the first character is typed, and not to indent if it is a space or tab.

This will not help for "else" or "except".

The user is going to have to outdent anyway if we return them to the previous indentation level. Essentially it would be this:


[ENTER]

set_cursor_to_previous_indentation_level()

if first_char_in_is_space:
    erase_first_char_in()
    reset_cursor_to_zero_indentation()
    type_first_char()
else:
    pass


So if we have this line:

        some_line

[ENTER]

        some_line
        ^

[BACKSPACEX4]

        some_line
    ^
<---- cursor direction

The other case is

        some_line

[ENTER]

        some_line
        ^

[SPACEX4]

        some_line
    ^
----> cursor direction

Does that make sense?

I guess the workflow has been fixed so that I can submit a PR! I wasn't expecting this so soon, but I will get around to this as soon as I have time.

> IPython3 solved this issue by adding special magic functions, but this is not a way for CPython.

IPython 5 improve on that with prompt toolkit. It does not break paste, as prompt_toolkit has a bracketed-past mode, that most terminal emulator support  (control chars sent by terminal "hey I'm pasting", "hey I'm done pasting"). So it works nicely. IPython 6 even will remove the need for magics to activate paste mode.

Though it's far from trivial to implement and to get it "right".

Once you start giving indentation to user, they start to be demanding, like indenting 1 more on `:`, and one less on `return`, `pass`... , multiple line string. etc...

See https://github.com/ipython/ipython/issues/9283 for some of the issues and limitation you can hit.

If you decide to implement this kind of things, there are likely a lot you can borrow from IPython, the InputSplitter class has likely the sate needed to give you the indent level to use in readline.

Folks, I have decided that I no longer have the time to resolve this issue.

I am inclined to close this.  Any objection?