[Python-Dev] Fix import errors to have data

[Tim Peters]

[Jim Fulton]
...
> No, it won't.  For example, suppose foo imports B. B tries to import
> C, but fails.  B is now broken, but it is still importable.  Actually,
> both foo and B can be imported without errors, even though they are
> broken.

Then you're proposing a way for a highly knowledgable user to
anticipate, and partially worm around, that Python leaves behind
insane module objects in sys.modules.  Wouldn't it be better to change
Python to stop leaving insane module objects in sys.modules to begin
with?  That's harder, but seems to me it would do a lot more good for
a lot more people.

Indeed, Python's own test suite fails on Windows often when run with
-r (randomize test order) because of broken modules left behind by
trying to run Unix tests.  Typically one test imports pty, which fails
because it can't import termios, but then a later test importing pty
succeeds (getting an insane pty) -- and despite this insanity in
pty.py already:

# Absurd:  import termios and then delete it.  This is to force an attempt
# to import pty to raise an ImportError on platforms that lack termios.
# Without this explicit import of termios here, some other module may
# import tty first, which in turn imports termios and dies with an
# ImportError then.  But since tty *does* exist across platforms, that
# leaves a damaged module object for tty in sys.modules, and the import
# of tty here then appears to work despite that the tty imported is junk.
import termios
del termios
import tty

That's a good example of the crazy brittleness we endure now.  I
really don't want to see more brittle code worming around a problem
that "shouldn't" be there at all.

That said, I have no objection to giving ImportError exceptions a
module_name attribute.  My objection is to the idea that it solves the
real problem.