Skip to content

IDLE applies syntax highlighting to user input in its shell #64007

Closed

Description

@peterotten
BPO 19808
Nosy @terryjreedy

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 2013-11-27.08:42:42.028>
labels = ['expert-IDLE', 'type-bug', '3.7']
title = 'IDLE applies syntax highlighting to user input in its shell'
updated_at = <Date 2017-06-30.01:02:08.990>
user = 'https://bugs.python.org/peterotten'

bugs.python.org fields:

activity = <Date 2017-06-30.01:02:08.990>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2013-11-27.08:42:42.028>
creator = 'peter.otten'
dependencies = []
files = []
hgrepos = []
issue_num = 19808
keywords = []
message_count = 5.0
messages = ['204566', '204772', '204791', '204840', '297338']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'peter.otten']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19808'
versions = ['Python 3.6', 'Python 3.7']

Linked PRs

Activity

  1. peterotten commented on Nov 27, 2013

    peterottenmannequin
    MannequinAuthor

    For example when you type

    >>> input("What shall I do? ")
    Run for your life!

    in its shell window IDLE shows the 'for' as if it were a keyword. The same happens if you run a script that requires user interaction.

  2. changed the title [-]IDLE applys syntax highlighting to user input in its shell[/-] [+]IDLE applies syntax highlighting to user input in its shell[/+] on Nov 27, 2013
  3. terryjreedy commented on Nov 30, 2013

    @terryjreedy
    Member

    I checked and Idle does not color code the prompt. In 2.7, it only color-codes the response to input(prompt), which is eval-ed as Python code, but not the response to raw_input(prompt). (In 2.7, the code and input displayed raises SyntaxError.) So the bug in 3.3 and 3.4 is that 3.3 input is being treated like 2.7 input rather than like 2.7 raw_input.

    I suspect that we just need to find and delete the code that detects 'input()' and triggers highlighting.

  4. peterotten commented on Nov 30, 2013

    peterottenmannequin
    MannequinAuthor

    I think the prompt can easily be treated differently because it is written to stderr.
    I don't see a difference for user input between input() and raw_input() on Linux with Python 2.7.2+ -- syntax-highlighting is applied to both.

  5. terryjreedy commented on Nov 30, 2013

    @terryjreedy
    Member

    On a freshly booted machine, I retried 2.7.6/Windows/raw_input() 'for all the' and indeed I now see 'for' and 'all' colored.

    The colorizing is done char by char. 'fo' is black, 'for' turns orange, 'forr' turns black again. Similarly, 'al' is black, 'all is purple, and 'allo' is black again. It is not a critical bug, but certainly annoying, especially to a new user.

    For editor windows, colorizing is only done for .py(wo) files. I do not know how the colorizing is switched on after the file name is checked. The shell window is an editor window. It should switch to .py mode after printing >>> and back to .txt mode when \n or \n\n is entered to complete a statement. I believe the edit will be in pyshell.py

    I expect the prompt and echoed input are both written to stdout by the user process. Neither are errors and both are colored blue. Warnings and exception tracebacks on stderr are red. Both come into the idle process via the socket connection, which is different from the idle process stdin connected to the keyboard.

  6. terryjreedy commented on Jun 30, 2017

    @terryjreedy
    Member

    Still a problem in 3.6.

  7. self-assigned this
    on Jun 30, 2017
  8. transferred this issue fromon Apr 10, 2022
  9. serhiy-storchaka commented on Sep 17, 2026

    @serhiy-storchaka
    Member

    #157700 stops colorizing the text after the I/O mark while the Shell reads a line for input(). Output was never colorized; only the text typed after the last prompt was, whether it was code or a reply to input().

  10. added 4 commits that reference this issue on Sep 20, 2026
  11. terryjreedy commented on Sep 27, 2026

    @terryjreedy
    Member

    3.15 backport must be generated after prior 3.15 backports are merged after 3.15 branch is unblocked.

  12. added a commit that references this issue on Oct 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

topic-IDLEtype-bugAn unexpected behavior, bug, or error

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions