With one process (installed 2.7.10, -n option):
>>> raise
Traceback (most recent call last):
  File "<pyshell#0>", line 2, in <module>
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType

With subprocess (default option):
>>> raise

Traceback (most recent call last):
** IDLE Internal Exception: 
  File "C:\Programs\Python27\lib\idlelib\run.py", line 325, in runcode
    exec code in self.locals
  File "C:\Programs\Python27\lib\idlelib\run.py", line 111, in main
    seq, request = rpc.request_queue.get(block=True, timeout=0.05)
  File "C:\Programs\Python27\lib\Queue.py", line 176, in get
    raise Empty
Empty

The 2.7.10 says " If no exception is active in the current scope, a TypeError exception is raised indicating that this is an error (if running under IDLE, a Queue.Empty exception is raised instead)."  The comment is not true with -n.  But adding changing 'IDLE' to 'IDLE without -n' might encourage people to think that they should use '-n'.

A workaround fix might be to add a special check to the internal error handling code to print the TypeError instead. I do not know of any other open issues about Internal Exceptions being printed.

This is a low priority issue, but it is peculiar that this seems to be the only exception so mangled. The only issue issue I found related to this section of the Idle code is #1190163.

This is a 2.7 issue only. In 3.4+, console or Idle in either mode:
>>> raise
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    raise
RuntimeError: No active exception to reraise

The Runtime error is what current py 3 raises.  TypeError is what 2.7.13 raises. Since the only problem is for someone who read the doc running 'raise' in IDLE 2.7  in -n mode, closing.