This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Zero, epaine, gvanrossum, rhettinger, taleinat, terry.reedy
Date 2021-05-08.08:54:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1620464045.17.0.101766874609.issue37903@roundup.psfhosted.org>
In-reply-to
Content
Yes, lets discuss actual problems and various possible solutions.

Raymond's example is incomplete as it omits multiline statements, which is where the real problems lie and the reason a fix was sorely needed.  This has been more or less agreed on since at least 2005.

Old:
------------------------------
>>> if a:
        print('okay:'
else:
        if a is None:
                print('none:')
        else:
                print('else:')

else:
------------------------------

Possible confusion between input and output is a pre-existing issue.  For the default themes, Shell User Output has the same background color as Code or Normal Text.  The foreground is blue.  The lack of contrast is worse on the dark theme.  I think using the same background was a mistake, but so far changing the default has been considered off limits. The pre-existing fix for distinguishing output is to customize colors for Shell User Output, as I have done. I have also given Shell User Exceptions more contrast.  One can make both as different as one wants.

In 2014, #7676, Raymond said that the indent mess was a "major PITA" and the impossibility of copy-pasting correctly indented code into an editor  "has been a continual source of frustration for students in my Python courses as well.  I'm looking forward to it being fixed."

At the time, I had no more idea how to fix this than Kurt Kaiser did in the 2000s.  But I eventually realized that the problem is entirely due to the first line of multiline statements being indented relative to following code lines, unlike the REPL.  The fix (and the only acceptible fix) was and is to stop doing that.

The day before the beta1 release*, Tal and I merged a beta-quality release that we said would need improvement before production release.
------------------------------
>>> if a:
...     print('okay:'
... else:
...     if a is None:
...         print('none:')
...     else:
...         print('else:')
...
    else:
------------------------------
I am sure that a graphics designer would consider this improved.  Unindented code now lines up, and the indents are that same as in any decent python-aware editor.  In any case, the above is identical to the REPL except that in the REPL, the output starts at the left, under the prompts.

If one selects the above lines, easily done by clicking and dragging on the sidebar, just as with line numbers, right clicks, and selects 'Copy with prompts' on the context menu, one gets the above *with*  output 'else' to the left.  IDLE is now as useful for interactive snippets as the REPL.  This is mentioned in the IDLE What's New and News items.

I can imagine a possible alternative fix that would put output under the prompts in Shell, not just in the clipboard copy.  It would involve a fixed input prompt above the code entry area and side prompts in the history area.  This would be a variation on the two-text solution that I discussed on #37892.

As for copying code to paste into an editor: As I believe was mentioned above, we had 'Copy only code' on the context menus, but removed it because it also copied user input in response to user code prompts, which is currently tagged the same as code entered in response to the Shell's prompts.  Fixing this will be a high priority issue.  When it is, we will list both new option on the Shell menu.

I will soon open another issue for the sidebar colors.  I consider the current colors to be placeholders.  We set that aside to get the sidebar otherwise ready.  Some might prefer a background matching the general shell background so that there is no vertical separation.


* Not by choice.  We were delayed 6 months because Azure Pipelines, on Ubuntu and Windows, changes the test environment by grabbing sys.stdout.  Shell receives input on sys.stdout.  So when test code sent text to shell via sys.stdout, it went to Pipelines instead of Shell, breaking the tests.  We should have ignored those failures, but didn't.  Once we realized the problem, less that 2 weeks before the beta, we had the test steal sys.stdout back for each test and moved forward.
History
Date User Action Args
2021-05-08 08:54:05terry.reedysetrecipients: + terry.reedy, gvanrossum, rhettinger, taleinat, Zero, epaine
2021-05-08 08:54:05terry.reedysetmessageid: <1620464045.17.0.101766874609.issue37903@roundup.psfhosted.org>
2021-05-08 08:54:05terry.reedylinkissue37903 messages
2021-05-08 08:54:04terry.reedycreate