IDLE doesn't support nor set sys.ps1 and sys.ps2.
>>> sys.ps1
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.ps1
AttributeError: 'module' object has no attribute 'ps1'
>>> sys.ps1 = "Test " #The next prompt doesn't start with Test
>>>

This would make the IDLE shell interface more consistent with the original interpreter. 

Presently, the ">>> " prompt is faked by "showprompt" in PyShell.py. It relies on "sys" from the IDLE gui process and not from the "sys" in the subprocess, so mimicking the changed prompt would require querying the subprocess for its sys.ps1 and sys.ps2. The "enter_callback" method will need modification to remove sys.ps2 from the text buffer before execution. Also, EditorWindow.py has code for handling sys.ps1 in "smart_backspace_event" and "newline_and_indent_event". 

If anything, this shell-specific, prompt-handling code needs some refactoring as it should only be in PyShell.py, not in EditorWindow.py.
Issue13039 is a result of prompt code side-effects in EditorWindow.py.

> so mimicking the changed prompt would require querying the subprocess for its sys.ps1 and sys.ps2.

Is that sensibly possible? Any line of code can change those, so IDLE would have to do the equivalent of
idle.ps1,idle.ps2 = sys.ps1, sys.ps2 before every new ps1 statement prompt. A configuration option might work better.
  
I would rather remove the prompts from the entry window itself, and use 4 char indents instead of 8, so that cutting does not pick up the prompts.  IDLE does not have to exactly imitate the Command Window interface. It could also give the user a choice.

> Is that sensibly possible? Any line of code can change those, so IDLE would have to do the equivalent of idle.ps1,idle.ps2 = sys.ps1, sys.ps2 before every new ps1 statement prompt.

It may be possible if the code gets refactored such that the subprocess handles the prompt and has stdin/stdout/stderr through RPCProxy treat the PyShell text widget as a dumb terminal.

> I would rather remove the prompts from the entry window itself, and use 4 char indents instead of 8, so that cutting does not pick up the prompts.  IDLE does not have to exactly imitate the Command Window interface. It could also give the user a choice.

This is #11838 and #1178.

What is the status of this bug?

This is an issue, not a bug, and the status is as it was: unclear just what to do; would require some major work.

For reference, IDLE-DEV is discussing the prompt: http://mail.python.org/pipermail/idle-dev/2012-June/003129.html

Buump...

Adding 16123 as a dependency. Resolving sys.ps1 and sys.ps2 will likely be simpler when only considering one execution mode.

I've attached a patch that attempts to get sys.ps1 for the prompt. Unfortunately it prints out blue because it is treated as output from running print(sys.ps1) as if the user had typed it in. Now that I have a better understanding of the issue, I may be able to work on the subprocess handling that Roger suggested.

I have reviewed the patch, and apart from setting the promt, I think it would be possible to set it at the beginning with the same approach:

    def getprompt(self):
        self.interp.runcommand(textwrap.dedent("""\
        try:
            print(sys.ps1, end="")
        except:
            import sys
            sys.ps1, sys.ps2 = ">>> ", "... "
            print(sys.ps1, end="")"""))

What I don't know is why ps1 and ps2 are the only attributes that are missing in the sys module within the ModifiedInterpreter. When I try InteractiveInterpreter in the original interpreter, it shows the 79 attributes that sys has originally.

Robin Zimmermann on docs@ raised this issue again.  Is this likely to be fixed soon, or would it be good to document this limitation of IDLE in the tutorial (since the tutorial is the most likely place for someone to be confused by this)?

If there is a discussion of sys.ps1 and sys.ps2 in the tutorial, then add a note that they are not supported in Idle. The only quick action on this issue would be to reject and close. I am still opposed to the proposal as presented, for reasons stated in my first message.

To expand a bit on what I said before: the prompts 'work', at least for the Windows console because
a) it is limited to fixed-pitch fonts, so that '>>>' and '...' have the same width;
b) its selection box is always a rectangle, so if one starts with the first character of a line and move down and right, the prompts are excluded.

I do not know what is true for *nix consoles, but neither is true for Idle. I would only tolerate the added nuisance of a secondary prompt if it were made to take up the same space (pixels) as the primary prompt so that indents could be 4 spaces instead of 8 space tabs.

If we were to get the prompts from the remote process, they should be sent as part of every normal response output instead of being a separate enquiry.

Part of my opposition to custom prompts is that the standard prompts, even though a nuisance, are instantly recognizable in messages. The can also be recognized and removed by code, as when pasting. See #1178, which I hope to act on soon. Neither is true of custom prompts.

I explained somewhere else that a secondary prompt would be wrong for Idle since the primary prompt  asks for a *statement*, not just the first line of the statement.  The advantage is being able to edit and recall entire statements, not just one line.  This is in addition to the absurdity of entering and then removing secondary prompts from the text buffer.

I still intend to at least add an option to move the prompt(s) to a sidebar and use 4 space indents.  At that point, it would not too much matter if '>>> ' were, as an option, followed by '... ' instead of '    ', although it would not look so good with a proportional font.

#31858 fixes pyshell and editor so that a user setting of sys.ps1 in a startup file continues to be used after turning debugger on, instead of erased. I consider this to be an IDLE documentation issue, to add something in the introduction.  Discussing IDLE differences in the tutorial might need more discussion than just here.

The part about startup files in my last message is probably wrong.  If one starts IDLE by 'import idlelib.idle' after setting 'sys.ps1 = 'me ', then the setting is recognized.  However, a startup file that runs in the user process will not affect sys.ps1 in the IDLE process.  We could add a command line option -p "prompt", but I don't see this as sufficiently important.

At least some shells and consoles recognize special characters in a prompt string to create the prompt.  For instance, the default setting on Windows is "$P$G", which I presume stands for 'working directory path' and 'greater than symbol', with a result such as "F:/dev/3x>".  (I have no idea where this is documented.)  Python and IDLE will print the literal string instead.  Custom prompts therefore seem like an advanced feature, not one aimed at beginners.

Starting with 3.10.0b1, Shell is being reworked in ways that make this issue, as formulated, out of date.  Solving the indent problems means that prompt must be removed from the first line of interactive input.  #37892.  The initial solution is to put >>> and ... prompts in a sidebar.  #37903.  The rules out customization.  A planned alternate solution is to put the prompt on a line by itself above interactive input.  A followup issue could be customizing the isolated prompt by a setting in the options dialog.