swig/Examples/python/import_packages/from_init2
Karl Wette f574a34155 Allow examples and test-suite to be built out of source tree
- Examples/Makefile.in rules use SRCDIR as the relative source directory

- ./config.status replicates Examples/ source directory tree in build
  directory, and copies each Makefile to build directory, prefixed with
  a header which sets SRCDIR to source directory

- Examples/test-suite/.../Makefile.in set SRCDIR from Autoconf-set srcdir

- Examples/test-suite/errors/Makefile.in needs to filter out source
  directory from SWIG error messages

- Lua: embedded interpreters are passed location of run-time test

- Python: copy run-time scripts to build directory because of 2to3
  conversion; import_packages example copies __init__.py from source
  directory; test-suite sets SCRIPTDIR to location of run-time tests

- Javascript: binding.gyp renamed to binding.gyp.in so that $srcdir
  can be substituted with SRCDIR; removed './' from require() statements
  so that NODE_PATH can be used to point Node.js to build directory
2014-05-11 23:21:10 +02:00
..
py2 Allow examples and test-suite to be built out of source tree 2014-05-11 23:21:10 +02:00
py3 Allow examples and test-suite to be built out of source tree 2014-05-11 23:21:10 +02:00
Makefile Allow examples and test-suite to be built out of source tree 2014-05-11 23:21:10 +02:00
README Fixed SF bug #1297 (Python imports) 2013-12-24 17:22:25 +00:00
runme.py Fixed SF bug #1297 (Python imports) 2013-12-24 17:22:25 +00:00

This example tests the %import directive and python import from __init__.py.

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 runme.py' to run a test.

Overview:
---------

The example defines 2 different extension modules--each wrapping a separate C++
class.

     pyX/pkg2/pkg3/foo.i     - Pkg3_Foo class
     pyX/pkg2/bar.i        - Pkg2_Bar class derived from Pkg3_Foo

and the package pyX.pkg2 has:

     pyX/pkg2/__init__.py  - which imports something from "bar" module

For example with python 2.x the py2/pkg2/__init__.py imports Pkg2_Bar class as
follows

    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/bar.py" has following lines:

    import py2.pkg2.pkg3.foo                     # [2]
    class Pkg2_Bar(py2.pkg2.pkg3.foo.Pkg3_Foo):  # [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 "runme.py", line 3, in <module>
      import py2.pkg2
  File "py2/pkg2/__init__.py", line 4, in <module>
      from bar import Pkg2_Bar
  File "py2/pkg2/bar.py", line 71, in <module>
      class Pkg2_Bar(py2.pkg2.pkg3.foo.Pkg3_Foo):
AttributeError: 'module' object has no attribute 'pkg2'

It seems like during the import [1], the subpackage pkg2 is not yet fully
initialized, so pyX.pkg2 is not known. 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_init2') case and the case
'from_init1' is that here it's not sufficient to import relative module
by just ignoring the package part of the fully qualified module name. IOW
it is not correct to force swig to put:

    import foo
    class Pkg2_Bar(foo.Pkg3_Foo)

into pyX/pkg2/bar.py (note, that this would work for 'from_init1' case).
The import directive shall be rather:

    import pkg3.foo

for python 2.x and:

    from . import pkg3
    import pkg3.foo

for python 3, and the class definition shall begin with:

    class Pkg2_Bar(pkg3.foo.Pkg3_Foo)

If everything works well, the package pyX.pkg2 shall load properly.

Unix:
-----
- Run make
- Run the test as described above