IDLE defaults to indenting with 4 spaces in editor windows, but hard TABs in the Python Shell window.  This is inconsistent with PEP 8; what's worse, it's makes copy-paste code between the shell and editor windows confusing and dangerous!

Recently I gave a 3-day Python course to 6 people.  I spent some time explaining the dangers of TABs with Python's indentation-sensitive syntax and telling them "just use 4 spaces and all will be OK".  A few hours later one of them asked me why IDLE is refusing to run his code.  Turns out he copy-pasted code he tried out in the shell, edited it and tried running it, which resulted in a mix of tabs and spaces (which triggered IDLE's tabnanny check) and a mixture of 4 and 8 indents (which is ugly).

I had to explain IDLE's confusing behavior, introduce them to Untabify, and apologize for the inconvenience.  All this TABs stuff (and Untabify) are things people should eventually learn - but they shouldn't bite them on their first day!  (This is what Ubuntu calls a "papercut".)

The rationale for the current behavior seems to be making indentation clear despite the prompt offsetting the first line by 4:

>>> for i in range(3):
        print i

There are 3 alternative behaviors that would be better:

 (1) Use 8 spaces instead of a TAB.
 (2) Use 4 spaces.
 (3) Use 4 spaces, but add a GUI left margin of 4 to continuation lines.

(3) would be ideal, making copy-paste work cleanly while looking good.  I'm not sure if it can be implemented easily, but I'll look into it.

If it's hard, (2) would still be a big improvement IMHO.  I think correct behaviour is more important than looking good after ">>> " - but others may disagree on this.

If there is doubt, (1) is still strictly an improvement.  It can lead to mixed 8/4 spaces - but at least there won't be invisible problems that the user doesn't understand.

[Configurability concerns: all I said above refers to the *default* behavior of IDLE, which should follow 4-spaces.  The user should be able to configure it to use another width, or TABs.  This option already exists - but it's ignored outright by the shell window.  Solutions (2) and (3) would make the shell window respect it.]

This is almost a duplicate of http://bugs.python.org/issue1196946
(though the solution there took a different direction).

Here's a simple patch to fix this bug.

The ">>> " prompt causes the first level of indented code to use 8 spaces. Further indented code should use 4 spaces, but still uses 8 spaces likely due to the bug described in #8285.

I closed #8285 as it merely reported a consequence of using tabs.

The Command Prompt window used for interactive Python on Windows only uses fixed-pitch fonts. Idle (tk) allows any font. I happen to use Lucida Sans Unicode (variable pitch) for what I think is the largest set of glyphs. (Perhaps Lucida Console (fixed) has the same set, I don't know. See #13802 for an idea to improve font selection in this regard.) Whatever we do should work well with either fixed or variable pitches. (The current patch does not -- see below.) Or we should prohibit variable pitch fonts and only allow fixed pitch fonts

Selection in CP selects a rectangle, so one can select code with or without the prompts. This is only possible with fixed pitch. Tk text boxes are limited to selecting a continuous stream of text, without excluding a margin.

This contrasts with, for example Notepad++. Its (tabbed) edit window has a gray left margin with line numbers. Then it has a narrow lighter gray column with [-] and [+] boxes to collapse and expand indented regions. Then it has a white text box for user entry and only user entry. Selections ignore the gray margins and only select within the white user text box. Perhaps this is done by tying three borderless windows to one vertical scroll bar, all inside one frame. I don't know. If we could do the same with tkinter, we could put prompts in a grayed margin, but I do not know if we can.

CP has tab stops at every 8 chars. So if one indents with tabs, the first indent is 4 spaces past the prompt and further indents are 8 spaces beyond the last. Not good. The alternative is hand spacing. Also not good if you do very much. Idle (Tk) appears to have tabs at fixed positions, regardless of the font. (Notepad++ acts like IDLE's edit windows -- a tab in converted to 4 spaces.) In Lucida Sans, a tab is physically the same as 16 spaces. Since each '>' is 3 spaces, an indent of 8 spaces instead of a tab is a dedent on the screen. So the patch does not work for me.

My conclusion is that having the shell write a prompt onto the user entry line, in the tk environment, is incompatible with the behavior we want. Fix 1 would be to put the prompt on a line by itself ('>>>\n' or 'input>\n'), use the same indents as the editor, and add an similar output marker ('###\n' or '<output\n'). Option 2 is to omit prompts, use editor indents, and prefix every output line with '#'. Fix 3 would be to put the prompt in a grayed margin. (If this can be done, we could also add line #s as an editor option.)

A separate idea is to give output a colored background.

Thoughts?