[Python-Dev] Fix import errors to have data (original) (raw)

Tim Peters tim.peters at gmail.com
Tue Jul 27 17:57:01 CEST 2004

[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.

More information about the Python-Dev mailing list