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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
