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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
