[Python-Dev] Cygwin Python 2.1c1 test_threadedtempfile problem

[Guido van Rossum]

> [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/)