Issue2854
Created on 2019-12-26.17:48:35 by jeff.allen, last changed 2019-12-26.17:48:35 by jeff.allen.
History | |||
---|---|---|---|
Date | User | Action | Args |
2019-12-26 17:48:35 | jeff.allen | create |
Created on 2019-12-26.17:48:35 by jeff.allen, last changed 2019-12-26.17:48:35 by jeff.allen.
Messages | |||
---|---|---|---|
msg12906 (view) | Author: Jeff Allen (jeff.allen) | Date: 2019-12-26.17:48:35 | |
I noticed when tracing through the statement: from javax.swing.text.Utilities import * that once having found (created) the module (a PyJavaType) for "javax.swing.text.Utilities" the thread dives into org.python.core.imp.importAll(PyObject, PyFrame) to populate the locals of the frame with the attributes of the module. So far, so good. A couple of things are worthy of question: 1. module.__dir__() involves (what seems to be) an inordinately repetitive traversal through the bases (and bases of bases) of the class to collect the names: why not just the MRO? 2. For every name collected in step 1, and not starting "_", we call module.__findattr__(sname), which may return null. (How often?) The first example is attribute "class" (a bean accessor from java.lang.Object.getClass()). __findattr__("class") returns null, and this triggers a call to __builtin__.__import__(), here to look for a module called "Utilities.class" with default (level=-1) semantics. This involves looking in quite a few places, twice. Parking my suspicions here for later investigation. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2019-12-26 17:48:35 | jeff.allen | create |
Supported by Python Software Foundation,
Powered by Roundup