blob: 131d5894cda8d086d7df0ee846d7b50280adea19 [file] [log] [blame]
This example tests the %import directive and python import from
This case is not correctly handled by swig 2.
The issue was reported as Source Forge bug #1297 and later as GitHub issue #7.
Use 'python' to run a test.
The example defines 2 different extension modules--each wrapping a separate C++
pyX/pkg2/pkg3/pkg4/foo.i - Pkg4_Foo class
pyX/pkg2/bar.i - Pkg2_Bar class derived from Pkg4_Foo
and the package pyX.pkg2 has:
pyX/pkg2/ - which imports something from "bar" module
For example with python 2.x the py2/pkg2/ imports Pkg2_Bar class as
from bar import Pkg2_Bar # [1]
Such cases doesn't work when fully qualified python module names are used by
swig to generate python import directives (SF bug 1297). The generated file
"py2/pkg2/" has following lines:
import # [2]
class Pkg2_Bar( # [3]
and it's not possible to import anything from py2.pkg2 subpackage, e.g.
import py2.pkg2
fails with the following exception:
Traceback (most recent call last):
File "", line 3, in <module>
import py2.pkg2
File "py2/pkg2/", line 4, in <module>
from bar import Pkg2_Bar
File "py2/pkg2/", line 71, in <module>
class Pkg2_Bar(
AttributeError: 'module' object has no attribute 'pkg2'
It seems like during the import [1], the subpackage pkg2 is not yet fully
initialized, so py2.pkg2 can't be used. The above exception is raised at
line [3]. The problem disappears, for example, if we force swig to use relative
package names.
The difference between this ('from_init3') case and the case
'from_init2' is that here we import base class from module, which is nested deeper than it was in
'from_init2'. This is just to ensure, that two (and more) levels of
subpackages get imported correctly by generated python code, i.e, not only
'' is handled properly (one-level subpackage) but the code works also
for '', and so on.
If everything works well, the package pyX.pkg2 shall load properly.
- Run make
- Run the test as described above