[Python-Dev] Idle, site.py, and the release candidates
Terry Jan Reedy
tjreedy at udel.edu
Sun Mar 31 04:34:32 CEST 2013
While trying to test the patch for
http://bugs.python.org/issue5492
on Windows, I discovered that quit() and exit() in the Idle Shell are
now disabled, it seems, for all versions on all systems rather than just
sometimes on Linux.
The problem is a change in idlelib that invalidated an assumption made
in site.py. Revs 81718-81721 for
http://bugs.python.org/issue9290
changed idlelib.PyShell.PseudoFile (line 1277 in 3.3) to subclass
io.TextIOBase, which subclasses IOBase. This gave PseudoFile and its
subclasses a .fileno instance method attribute that raises
io.UnsupportedOperation: fileno.
This is not a bug since the doc for io.IOBase.fileno says:
"Return the underlying file descriptor (an integer) of the stream if it
exists. An OSError is raised if the IO object does not use a file
descriptor."
(the particular error raised is not an issue here).
This is the code for Quitter.__call__ in site.py (line 368 in 3.3):
def __call__(self, code=None):
# Shells like IDLE catch the SystemExit, but listen when
# stdin wrapper is closed.
try:
fd = -1
if hasattr(sys.stdin, "fileno"):
fd = sys.stdin.fileno()
if fd != 0:
# Don't close stdin if it wraps fd 0
sys.stdin.close()
except:
pass
raise SystemExit(code)
The incorrect assumption is that if sys.stdin.fileno exits but raises,
the call did not come from a shell that needs .close called.
I do not know enough about other circumstances in which stdin.fileno
would do something other than return 0 to be sure of what the proper fix
would be. (I increasingly dislike bare excepts as they hide the
thinking and knowledge of the original programmer. What exception was
expected that should be passed away?)
Given that the callable constants exit and quit and are optionally
suppressed on startup and are not standard builtins
http://docs.python.org/3/library/constants.html#constants-added-by-the-site-module
it would be alright with me to ignore this regression and release as
scheduled. But I though people should be aware of it.
--
Terry Jan Reedy
More information about the Python-Dev
mailing list