Guido van Rossum <[EMAIL PROTECTED]> added the comment: The order thing was a red herring. However, I understand what's going on now. Somebody else can fix it hopefully.
So what's going on: In the Python instance that runs setup.py, importing _multiprocessing fails. But if I start a new Python instance in exactly the same environment, it works. Why? Because at the *start* of running setup.py, the directory .../build/lib.macosx-10.3-i386-3.0 doesn't exist, and this is being cached in sys.path_importer_cache, which has a NullImporter instance for that key. Maybe the solution is to remove that cache entry (if it exists) in the code that creates that directory? I found this by (a) disabling the two except clauses in setup.py that catch exceptions from the attempt to import the module that was just built, and (b) adding a -i flag to the Python instance invoked by the Makefile to run setup.py. This gave me an interactive interpreter at the moment the "import _multiprocessing" failed. Poking around I could see that sys.path_importer_cache had a NullImporter instance for the directory from which _multiprocessing.so was to be imported. I could even delete that cache entry, and then the import would pass! Good luck fixing... _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3375> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
