I have a use-case when I need to forward InteractiveConsole through Unix/TCP socket. Expected implementation:

class InteractiveSocket(InteractiveConsole):
  def __init__(self, socket):
    self._socket = socket
    ...

  def raw_input(...):
    # read from socket

  def write(...):
    # write to socket

However, only syntax errors and tracebacks are written into a socket, while actual output still appears on servers stdout. Digging through it I realized, that the output happens inside exec call in InteractiveInterpreter.runcode and here is why:

>>> c=compile('42', '', 'single')
>>> dis.dis(c)
<<< 1           0 LOAD_CONST               0 (42)
                3 PRINT_EXPR          
                4 LOAD_CONST               1 (None)
                7 RETURN_VALUE

where PRINT_EXPR uses _Py_IDENTIFIER(displayhook);

I ended up with the following dirty hack in my derived class:

def runcode(self, code):
  class OutWriter:
    pass
  writer = OutWriter()
  writer.write = self.write
  old = sys.stdout
  sys.stdout = writer
  try:
    exec(code, self.locals)
  except SystemExit:
    raise
  except:
    self.showtraceback()
  sys.stdout = old

I think it would be nice to make InteractiveInterpreter extendable out of the box, though I don't have exact solution here.

Does it not work to create an unbuffered makefile object from the socket and assign that to stdout?  Regardless, if you need to set it and restore it around runcode you can use super() to call the base class method.

I think providing an easier API to change stdin/stdout/stderr is a reasonable RFE, though.

To me, this cries out for a public context manager ( believe there is a public one in test.support, or something), so one can write

with stdout(ob):
  print(stuff)

I am not sure, though, where the C.M.s should live.

Terry: perhaps you’re thinking of <https://docs.python.org/dev/library/contextlib.html#contextlib.redirect_stdout> :)

There is also redirect_stderr, but not for stdin.  I am not sure what specific issue is left here, of if this should be closed.

I agree with David. I've added a "stream" attribute to InteractiveInterpreter. I don't have a strong preference between a getstream method and a stream attribute(or something different) so I will add documentation changes and tests later.

I strongly prefer attribute, as in the patch.