> [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. [Tim] > 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. Maybe. It could be that the deep reason is mostly that the implementation doesn't have the information available to decide what to delete. > > 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? I'll think about this over the weekend. I know people have tried to convince me of changing this before, and I've tried to listen, but I've never changed it, so I guess there must be a good reason. It's worth trying to remember what it is! --Guido van Rossum (home page: http://www.python.org/~guido/)
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