Message10181

Author jeff.allen
Recipients Lonebuddha, fwierzbicki, jeff.allen, zyasoft
Date 2015-08-30.07:31:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1440919906.32.0.441569002051.issue1423@psf.upfronthosting.co.za>
In-reply-to
Content
The root of the problem seems to be here:
https://hg.python.org/jython/file/tip/src/org/python/core/imp.java#l1140
I think the aim of the code is to introduce the names of the imported modules into the namespace of the importing module. This should (and does) happen in the Python code where the import statement occurs, when importFromAs returns, but the comment points us to bug #1900 about importing Python modules into Java code.

The other factor here is this call to imp.find_module:
https://hg.python.org/jython/file/tip/src/org/python/core/PyModule.java#l106
Here "find" includes "load" and it is this call which causes the repeated attempts to load the sub-modules in the OP's example.

Nearby, a call to loadFromClassLoader is disabled by a comment, as if it might have caused a similar problem. (Archaeology has shown this hack to be 15 years old.)

In the context it is used above, PyModule.impAttr is needed only to return modules that are already loaded, not to try loading them again. (The module exists in sys.modules, at this point, even though we haven't finished executing it.)

I don't understand the general contract of PyModule.impAttr. But I think the least intrusive fix is to make the call to imp.find_module conditional on failing to find the module already in sys.modules. However, my first attempt is failing ant importest.
History
Date User Action Args
2015-08-30 07:31:46jeff.allensetmessageid: <1440919906.32.0.441569002051.issue1423@psf.upfronthosting.co.za>
2015-08-30 07:31:46jeff.allensetrecipients: + jeff.allen, fwierzbicki, zyasoft, Lonebuddha
2015-08-30 07:31:46jeff.allenlinkissue1423 messages
2015-08-30 07:31:44jeff.allencreate