homepage

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

AltStyle によって変換されたページ (->オリジナル) /