RE: [Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem
[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?
[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/)
On Sat, Apr 14, 2001 at 07:59:16PM -0500, Guido van Rossum wrote:
[Tim]
[..] 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.
Wouldn't the right place for the half-broken, import-failed module be in the traceback object ? In fact, isn't it already *in* the traceback object ? :)
It could be that the deep reason is mostly that the implementation doesn't have the information available to decide what to delete.
Deep magic can be added. Deep magic should be added, IMHO, unless ...
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!
... you come up with a real reason for it to be as it is ;)
Happy-easter-for-those-of-you-with-permanent-'net-connections-*snif*-ly y'rs,
--
Thomas Wouters
participants (3)
-
Guido van Rossum -
Thomas Wouters -
Tim Peters