[Python-Dev] ImportWarning flood

["Martin v. Löwis"]

Ralf W. Grosse-Kunstleve wrote:
>> There can be many reasons why an import could fail: there might be
>> no read permission for the file,
> 
> The warning in 2.5b1 doesn't fire in this case:

Sure, but it would produce your "note", right? And the note would be
essentially wrong. Instead, the ImportError should read

ImportError: No module named junk; could not open junk.py (permission
denied)

>> or the PYTHONPATH might be setup
>> incorrectly.
> 
> That's impossible to detect.

Right. So the ImportError should not guess that there is a problem
with packages if there could be dozens of other reasons why the
import failed.

> I am thinking you'd need to build up a buffer of potential warnings while
> trying to resolve an import. If the import succeeds the buffer is discarded, if
> it fails it is added to the exception message, or the warnings are "flushed"
> right before the ImportError is raised. Does that sound right? 

That might work, yes.

> How would this interact with threading (it seems you'd need a separate 
> buffer for each thread)?

There are several solutions. I think you are holding the import lock
all the time, so there can be only one import running (one would have
to check whether the import lock is really held all the time); in
that case, a global variable would work just fine.

Another option is to pass-through all import-related data across all
function calls as a parameter; that may actually cause a reduction
in the number of parameters to the current functions, and simplify
the code. Define a struct to hold all the relevant data, allocate
it when entering the import code, pass it to every function,
fill it out as needed, and deallocate it when leaving the
import code. Allocation of the struct itself could likely be done
on stack.

Yet another option is to put the data into thread storage (although
care is needed wrt. recursive imports within one thread).

Regards,
Martin