This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients barry, gvanrossum, jnoller, mishok13
Date 2008-07-17.05:06:27
SpamBayes Score 0.03637564
Marked as misclassified No
Message-id <1216271189.32.0.820251722471.issue3375@psf.upfronthosting.co.za>
In-reply-to
Content
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...
History
Date User Action Args
2008-07-17 05:06:29gvanrossumsetspambayes_score: 0.0363756 -> 0.03637564
recipients: + gvanrossum, barry, jnoller, mishok13
2008-07-17 05:06:29gvanrossumsetspambayes_score: 0.0363756 -> 0.0363756
messageid: <1216271189.32.0.820251722471.issue3375@psf.upfronthosting.co.za>
2008-07-17 05:06:28gvanrossumlinkissue3375 messages
2008-07-17 05:06:27gvanrossumcreate