Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
the fact of having a defined point where we switch from python imports to java imports would greatly simplify the work I'm on: better messages than 'no module named java', or importing more than the package manager can know.
I'll check your patch as soon as I'm back.
Thanks a lot,
Bugs 1421812 and 1246413 both look like they stem from the java import
mechanism being called before the python importers since it was put on
meta_path as part of the new PEP 302 system. In 1421812 Samuele has a
nice summary of the problem where he suggests either putting the
python importer before the java importer on the meta_path or having
the java importer be in a separate entry point that gets applied after
everything else. The Open Issues section of PEP 302 it mentions that
they don't have a mechanism to run hooks after sys.path is processed.
They suggest adding a "cookie" to the end of sys.path that triggers a
special import hook after everything else has had a chance to try to
import an entry. That sounded exactly like the second option Samuele
mentioned and it had the nice benefit of not pushing the java importer
off into a special case. So in the attached patch I've appended a
"__classpath__" entry to sys.path and switched the JavaImporter from
meta path to a path hook. It only comes into effect on the path
"__classpath__". It passes the new bug test I added for when the bad
java imports come into play, and doesn't cause any new failures in the
Does this sound like an adequate solution?
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
Jython-dev mailing list