[Michael Hudson] > Maybe modules should be removed from sys.modules when they fail to be > imported due to an exception? [Guido] > This has been suggested before, but *in general* this is not a good > idea. For example, you want to debug the remains of the failed > module. Ya, I've heard you say something like that before, but haven't understood what it meant. That is, I've never had, or been able to picture, a case where having a module object in an incomplete and unknown state is actually of use. OTOH, I've certainly burned my share of time recovering from that importing a broken module only fails the first time. It's like Python only raised an exception the first time somebody tried to open a particular non-existent file for reading, but the second time it returned a file object that may or may not fail in use, and may or may not work correctly when it doesn't fail, depending on what you do with it. > However, the test suite can easily guard against this, e.g. by > inserting "import thread" before "import threading" whereever it > occurs. So how come a failed attempt to import thread doesn't leave a bogus module object in sys.modules["thread"] too <0.9 wink>? This is obscure stuff. Is "debugging the remains" of sufficient use to make up for the conceptual complications?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4