Python 3.13: Pressing the Tab key while in the REPL prints 4 spaces instead of 1 tab (breaking backspace)

[milosivanovic]

Bug report

Bug description:

Tested on 3.12:
In the <=3.12 Python REPL on Linux, I can press the tab key, and a tab character is printed in the console. I can then use the backspace key to undo that whole tab character.

Tested on 3.13:
In the 3.13 Python REPL on Linux, if I type a tab character, it seems to convert it to 4 spaces, and thus pressing the backspace key once only deletes 1/4 of the indentation.

---

This is either a bug, or if it's a feature, it should be configurable and without changing the sane defaults from <=3.12.
How can I get back to the <=3.12 behaviour?

CPython versions tested on:

3.12, 3.13

Operating systems tested on:

Linux, macOS

[nineteendo]

How about using shift tab (\x1b[Z)?

[milosivanovic]

@nineteendo I'm not sure what you mean. If I try pressing SHIFT+TAB in the Python 3.13 REPL, nothing happens.

It's worth noting that I shouldn't need to press shift, of course, so I assume your question was just to help narrow down the issue.

[terryjreedy]

On Windows, backspace deletes up 8 spaces of indent. It should be just (up to) 4.

[nineteendo]

I'm not sure what you mean. If I try pressing SHIFT+TAB in the Python 3.13 REPL, nothing happens.

What I meant is that we could implement de-denting with shift-tab.

[milosivanovic]

If you mean that the new REPL has the ability to highlight multiple lines, and we want to allow the user to de-indent all of those, then I agree that supporting de-indenting with SHIFT+TAB would be a great feature. However, that's not what this bug report is concerning. This bug report is concerning the fact that pressing tab creates 4 spaces, and backspace only removes 1, which is different to <=3.12 and unintuitive.

In the new Python 3.13 REPL, pressing tab should either:

1. Create a tab character, which will be backspaced with one press of the backspace key. This is preferred as it's the existing <=3.12 functionality.
2. Create 4 space characters, ALL 4 of which will be backspaced with one press of the backspace key.

However, I really don't like the second option as that changes sane defaults that have been around since the beginning, but it technically would be one way to resolve this. Some text editors that use spaces for tabs do do this. But I personally use tabs for my Python code, so I would want the REPL to not override my choice.

What I meant is that we could implement de-denting with shift-tab.

The suggestion to use SHIFT+TAB to de-indent just one line that a cursor is on (not highlighting anything) doesn't make much sense and doesn't mimic conventional implementations of such a feature in common text editors. Normally, text editors will allow to de-indent with tab only if multiple lines are selected. And, of course, if I mistakenly press tab, I want to use the backspace key, not shift, to undo my mistake.

[gaogaotiantian]

Personally, I don't think inserting a <tab> is a good choice.

First of all, backward compatibility to pre-3.12 repl does not quite make sense now - it's a completely new repl, there are a lot of things that are different, and that's by design. If you really want the old behavior, you can always set PYTHON_BASIC_REPL environment, which I believe is 100% backward compatible.

So it's basically whether to keep <tab>. There is a fundamental issue for <tab> now - it looks like 4 spaces for the first indentation just because of accident (or carefully design). >>> takes 4 spaces so the first indent would be 4, but the next would be 8.

>>> if True:
...     if True:
...             pass

You can potentially change sys.ps1 to change >>> to something else and <tab> would look even worse. I like 4 spaces, that's clean and I believe that's the default for many editors.

However, I agree that if backspace can back a full indent when the line is empty, it would be nicer. Not sure if this is difficult with all the readline issues.

[nineteendo]

The suggestion to use SHIFT+TAB to de-indent just one line that a cursor is on (not highlighting anything) doesn't make much sense and doesn't mimic conventional implementations of such a feature in common text editors.

VS Code allows you to do this, no matter where you are on the line.