[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
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
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 
(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.
                 fd = -1
                 if hasattr(sys.stdin, "fileno"):
                     fd = sys.stdin.fileno()
                 if fd != 0:
                     # Don't close stdin if it wraps fd 0
             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
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