[Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18

[skip at pobox.com]

    Anthony> The plan for 2.4.4 is to have a release candidate on October
    Anthony> 11th, and a final release on October 18th. This is very likely
    Anthony> to be the last ever 2.4 release, after which 2.4.4 joins 2.3.5
    Anthony> and earlier in the old folks home, where it can live out it's
    Anthony> remaining life with dignity and respect.

    Anthony> If you know of any backports that should go in, please make
    Anthony> sure you get them done before the 11th.

John Hunter (matplotlib author) recently made me aware of a problem with
code.InteractiveConsole.  It doesn't protect itself from the user closing
sys.stdout:

    % ./python.exe 
    Python 2.4.4c0 (#2, Sep 26 2006, 06:26:16) 
    [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import code
    >>> c = code.InteractiveConsole()
    >>> c.interact()
    Python 2.4.4c0 (#2, Sep 26 2006, 06:26:16) 
    [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    (InteractiveConsole)
    >>> import sys
    >>> sys.stdout.close()
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "/Users/skip/src/python-svn/release24-maint/Lib/code.py", line 234, in interact
        line = self.raw_input(prompt)
      File "/Users/skip/src/python-svn/release24-maint/Lib/code.py", line 277, in raw_input
        return raw_input(prompt)
    ValueError: I/O operation on closed file

I think the right thing is for InteractiveConsole to dup sys.std{in,out,err}
and do its own thing for its raw_input() method instead of naively calling
the raw_input() builtin.  I outlined a solution for ipython in a message to
ipython-dev, but even better would be if InteractiveConsole itself was
fixed:

    John Hunter alerted me to a segfault problem in code.InteractiveConsole
    when sys.stdout is closed.  This problem is present in Python up to
    2.4.3 as far as I can tell, but is fixed in later versions of Python
    (2.5, 2.4.4 when it's released, svn trunk).  Even with that fix, if the
    user calls sys.stdout.close() you'll get a ValueError and your console
    will be useless.  I took a look at the code in Python that the
    InteractiveConsole class exercises and see that the cause is that the
    naive raw_input() method simply calls the raw_input() builtin.  That
    function gets the "stdin" and "stdout" functions from the sys module and
    there's no way to override that behavior.

    In my opinion, the best thing to do would be to subclass
    InteractiveConsole and provide a more robust raw_input() method.
    Ideally, I think you'd want to dup() the file descriptors for
    sys.{stdin,stdout} and use those instead of calling the builtin
    raw_input().  Something like (untested):

        class IC(code.InteractiveConsole):
            def __init__(self):
                code.InteractiveConsole.__init__(self)
                self.input = os.fdopen(os.dup(sys.stdin.fileno()))
                self.output = os.fdopen(os.dup(sys.stdout.fileno()))
                self.error = os.fdopen(os.dup(sys.stderr.fileno()))

            def raw_input(self, prompt=""):
                if prompt:
                    self.output.write(prompt):
                    self.output.flush()
                return self.input.readline()

            def write(self, data):
                self.error.write(data)

    Also, the runcode() method will have to be overridden to use self.output
    instead of sys.stdout.  Those couple changes should (hopefully) insulate
    IPython from such user wackiness.

I'm happy to work up a patch for 2.4.4, 2.5.1 and 2.6.0.  Does this group
think that's the right route to take?

Skip