In IDLE for Py30a3 if you enter:

>>> class A(

as soon as you type the ( you get the following output to stderr (on
Fedora 8 with Tcl/Tk 8.4):

: *** Internal Error: rpc.py:SocketIO.localcall()

 Object: exec
 Method: <bound method Executive.get_the_calltip of
<idlelib.run.Executive object at 0xb70f2b4c>>
 Args: ('A',)

Traceback (most recent call last):
  File "/home/mark/opt/python30a3/lib/python3.0/idlelib/rpc.py", line
188, in localcall
    ret = method(*args, **kwargs)
  File "/home/mark/opt/python30a3/lib/python3.0/idlelib/run.py", line
316, in get_the_calltip
    return self.calltip.fetch_tip(name)
  File "/home/mark/opt/python30a3/lib/python3.0/idlelib/CallTips.py",
line 103, in fetch_tip
    entity = self.get_entity(name)
  File "/home/mark/opt/python30a3/lib/python3.0/idlelib/CallTips.py",
line 112, in get_entity
    return eval(name, namespace)
SystemError: error return without exception set

It does not appear to affect IDLE's functionality.

I don't think that this is an IDLE error.  It 
can be more generally exhibited as follows:

Without the subprocess we get the expected:

IDLE 3.0a4      ==== No Subprocess ====
>>> eval('a')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    eval('a')
  File "<string>", line 1, in <module>
NameError: name 'a' is not defined

With the subprocess there is an interpreter 
error when IDLE applies eval to 'a':

IDLE 3.0a4      
>>> eval('a')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    eval('a')
SystemError: error return without exception set

I did a cutdown where I ran the eval in a 
subprocess and didn't reproduce the error.  I 
suspect it's thread related (the subprocess 
uses its main thread to execute user code, and 
another thread to manage the socket connection 
to the GUI process).

issue1733757 is suggestive.

This is a 3.0 issue, it doesn't occur in the 
trunk.

The problem is just that in Python/pythonrun.c, the function run_mod()
calls flush_io() after executing the code. In our testcase, there is a
pending exception.
But flush_io() silently ignore errors (which is fine), and clears all
exception info (which is bad).
To correct the problem, I it is enough to calls to
PyErr_Fetch/PyErr_Restore.

This happens only with Idle, probably because the subprocess redirected
its stdout to a pseudo-file that does not support flush().

Committed r62157.

Will also investigate why exec() needs to flush sys.stdout...

Thanks, that does appear to fix the IDLE problem!

The pseudofile does have a flush method and I was able to 
call it from the IDLE subprocess; it returns None.  So I'm
not clear on why PyObject_CallMethod was returning False, or
why the problem only occurred when IDLE was running its subprocess.

PyObject_CallMethod is actually returning a
non-NULL result for sys.std{out,err}, and 
PyErr_Clear() isn't being run in flush_io.

The problem is deeper.  PyErr is being
used during unexceptional processing in
typeobject.c:slot_tp_getattr_hook() to
indicate that PyObject_GenericGetAttr() failed
and the __getattr__ method (used in IDLE) 
should be called.

Perhaps PyErr should be preserved in
slot_tp_getattr_hook(), instead.  Is this 
possibly a potential 2.6 issue for some uses
of getattr?  Or is the current solution 'good 
enough'?

ref issue1400.

I think this is good enough: you should not invoke python code with a
pending exception set (PyErr_Occurred()).