Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDLE Shell: isolate user code input #82073

Closed
terryjreedy opened this issue Aug 20, 2019 · 8 comments
Closed

IDLE Shell: isolate user code input #82073

terryjreedy opened this issue Aug 20, 2019 · 8 comments
Assignees
Labels
3.10 only security fixes 3.11 only security fixes topic-IDLE type-bug An unexpected behavior, bug, or error

Comments

@terryjreedy
Copy link
Member

BPO 37892
Nosy @rhettinger, @terryjreedy, @taleinat, @csabella, @E-Paine
PRs
  • bpo-37892: Use space indents in IDLE Shell #25678
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/terryjreedy'
    closed_at = None
    created_at = <Date 2019-08-20.11:38:43.876>
    labels = ['expert-IDLE', 'type-bug', '3.10', '3.11']
    title = 'IDLE Shell: isolate user code input'
    updated_at = <Date 2021-05-07.03:42:54.606>
    user = 'https://github.com/terryjreedy'

    bugs.python.org fields:

    activity = <Date 2021-05-07.03:42:54.606>
    actor = 'terry.reedy'
    assignee = 'terry.reedy'
    closed = False
    closed_date = None
    closer = None
    components = ['IDLE']
    creation = <Date 2019-08-20.11:38:43.876>
    creator = 'terry.reedy'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 37892
    keywords = ['patch']
    message_count = 8.0
    messages = ['350000', '350055', '355853', '392179', '392184', '392298', '392576', '393166']
    nosy_count = 5.0
    nosy_names = ['rhettinger', 'terry.reedy', 'taleinat', 'cheryl.sabella', 'epaine']
    pr_nums = ['25678']
    priority = 'normal'
    resolution = None
    stage = 'needs patch'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue37892'
    versions = ['Python 3.10', 'Python 3.11']

    @terryjreedy
    Copy link
    Member Author

    The main operational difference between the standard Python REPL and IDLE's Shell is that the latter operates with complete Python statements rather than physical lines. Shell keeps the '>>>' prompt, but with the expanded meaning of "Enter a complete Python statement" rather than just "Enter the first line of a Python statement". It omits the consequently superfluous continuation prompts, which would mostly be a nuisance if left.

    Currently, the prompt precedes and indents the first line of code. This causes multiple problems. Internally, first lines have to be treated differently from the rest. This has lead to bugs, mostly but not all fixed. Externally, indentation depends on the prompt and does not look right or work right, compared to the same code in a proper editor. And it lead to the use of Tab for indents.

    The use of Tab for Shell indents was recognized as a problem by 2005.  python/cpython#41957 proposed using the same space indents as in the editor, resulting, for instance, in
    >>> if a:
        if b:
            print(a+b)
    KBK rejected this with "Doesn't really solve the problem."

    In 2010, bpo-7676 suggested 4 space indents again and added 2 variations: 8 space indents, and 8 followed by 4, etc. OP Cherniavsky Beni noted that Tab indents are "inconsistent with PEP-8; what's worse, it's makes copy-paste code between the shell and editor windows confusing and dangerous!" Raymond Hettinger later added that tabs are a "major PITA" and "a continual source of frustration for students".

    Starting with msg151418 in 1212, my response was much the same as KBK's. To me, the underlying problem is having the prompt physically indent the first physical line relative to the following lines. I consider this IDLE's single biggest design wart. I proposed then 3 possible solutions to avoid the first line non-significant indent. They are, with current comments, ...

    1. Prompt on a line by itself (vertical separation).
    This is easy, and allows for an expanded active prompt, such as
      >>> Enter a complete Python statement on the lines below.
    This says exactly what the user should do and should help avoid confusion with a command-line prompt.  ("I entered 'cd path' and got 'SyntaxError'".)

    Once a statement is entered, the instruction is obsolete. Only '>>>' is needed, to identify input from output. I think putting '>>>' above past input works less well than for current input. I will come back to this proposal below, after 3.

    1. No input prompt; instead mark output (with #, for instance).

    Possible, but confronting beginners with no prompt would likely leave them wondering what to do. But this is a possible savefile format, one that could be run or edited. (A savefile with only the code would do the same.)

    1. Prompt in a margin, as with line numbers (horizontal separation).

    In 1214, I realized that the 'margin' should be implemented as a separate sidebar widget, which was initially being developed for editor line numbers. We now have that, and a shell sidebar should be fairly easy. I will open a separate issue with a fairly specific design. Basically, the first lines of input, stderr output, and stdout output would be flagged with, for instance, '>>>', 'err', and 'out'. This should be done before the additional proposal below.

    IDLE's Shell should isolate user input not only from prompts. Debug on/off messages, warnings, and delayed program output can also interfere. I think that IDLE's Shell should consist of an input and output history area with sidebar, fixed prompt and separator line such as in 1. above, and active input area.

    The history area, as now, would be read-only except when responding to input() in the running code. The change is that it would receive all messages from IDLE and asynchronous program output. The input area would be a specialized editor area. When input code is run, it would be copied above the separator prompt with '>>>' added to the sidebar, opposite the first line.

    I believe that the easiest implementation would be to use a label for the fixed prompt line and a specialized editor that runs statements as entered. The editing and smart indents would be the same as in a regular editor. Once this is done, we could discuss refinements such as allowing pasting of multiple statements.

    @terryjreedy terryjreedy added 3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes labels Aug 20, 2019
    @terryjreedy terryjreedy self-assigned this Aug 20, 2019
    @terryjreedy terryjreedy added topic-IDLE type-bug An unexpected behavior, bug, or error labels Aug 20, 2019
    @terryjreedy
    Copy link
    Member Author

    Adding a Shell sidebar is bpo-37903.

    @terryjreedy
    Copy link
    Member Author

    One of the related changes is to add multiple options for saving the shell history.  For editing, one wants code without prompts and output either omitting or commented out.  For doctests, one wants code with '>>> ' and '... ' prompts and unmarked output.

    A second would be to *not* print SyntaxError and a new prompt, but to otherwise indicate 'error' and put the cursor after the already highlighted error, as done in the editor.

    A third would being able to submit multiline statements for execution with with F5 instead of having to go to the end of the last line and enter a blank line. This would be especially useful after correcting a syntax error or other typo.

    @E-Paine
    Copy link
    Mannequin

    E-Paine mannequin commented Apr 28, 2021

    Personally, I find the change quite weird and will take some getting used to. I hope people read the help at the top of the shell, but if not I can imagine numerous bug reports about the change. I have not used any shell that has the prompt above where you type, so while I think this should be an option for the user, I propose the sidebar is the default for familiarity (instead of the other way around).

    @E-Paine E-Paine mannequin added 3.10 only security fixes 3.11 only security fixes and removed 3.7 (EOL) end of life 3.8 (EOL) end of life labels Apr 28, 2021
    @terryjreedy
    Copy link
    Member Author

    I had a similar reaction, "weird", when I tried the isolated prompt a year or whatever ago. I don't remember if I also changed the indent for that. But when testing this patch, with space indents, a longer time, most of the weird feeling dissipated and I realized that I might possibly prefer this, at least sometimes.

    Another reason I proposed the isolated prompt as the *current* default is that some (many?) people like to save the shell as a record of their session. With prompts in the sidebar, saving the shell *currently* results in a text record with no prompts. (And, of course, no highlighting.) I can read it, but I expect that most people would prefer isolated prompts to no prompts

    I discussed the need for shell saving options both above and in msg392163, posted to bpo-37904 a few hours ago. I do not currently expect anything before next Monday. If a followup PR, zipping the sidebar with text when saving, were prepared before then, I would be more favorable to making sidebar the current default.

    I plan to ask for more opinions on idle-dev and python-list later today.

    @terryjreedy terryjreedy removed the 3.9 only security fixes label Apr 28, 2021
    @terryjreedy
    Copy link
    Member Author

    New changeset 8ec2f0d by Terry Jan Reedy in branch 'master':
    bpo-37892: Use space indents in IDLE Shell (GH-25678)
    8ec2f0d

    @taleinat
    Copy link
    Contributor

    taleinat commented May 1, 2021

    For doctests, one wants code with '>>> ' and '... ' prompts and unmarked output.

    Note that with the latest PR, the shell sidebar now adds a "Copy with prompts" context-menu option which does precisely this.

    @terryjreedy
    Copy link
    Member Author

    PR 25678 merged on top of the sidebar patch results in using space indents with the sidebar. An additional patch is needed to have the mode with '>>>' on a line by itself instead of having a sidebar.

    The shell prompt_last_line attribute is now obsolete (it is always '') and should be removed after uses, such as "if self.prompt_last_line" headers and the following code, are removed.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.10 only security fixes 3.11 only security fixes topic-IDLE type-bug An unexpected behavior, bug, or error
    Projects
    Status: Done
    Development

    No branches or pull requests

    3 participants