Only one import of the low-level C/C++ module from the pure Python module is attempted now. Previously a second import of the low-level C/C++ module was attempted after an ImportError occurred and was done to support 'split modules'. A 'split module' is a configuration where the pure Python module is a module within a Python package and the low-level C/C++ module is a global Python module. Now a 'split module' configuration is no longer supported by default. This configuration can be supported with a simple customization, such as: %module(package="mypackage", moduleimport="import $module") foo or if using -builtin: %module(package="mypackage", moduleimport="from $module import *") foo instead of %module(package="mypackage") foo See the updated Python chapter titled "Location of modules" in the documentation. Closes #848 #1343 |
||
|---|---|---|
| .. | ||
| vanilla | ||
| vanilla_split | ||
| Makefile | ||
| README | ||
These examples/tests are for when the SWIG generated wrapper module is split between two packages. Specifically the pure python part is part of a package and the C/C++ part is not in any package at all. Historically SWIG has supported this sort of thing. From SWIG 4.0.0 onwards, split modules are not supported by default. The %module directive needs to be customised with the moduleimport attribute in order to import the a global C/C++ module. vanilla # "plane Jane" module both halves in pkg1 vanilla_split # python 1/2 in pkg1 C 1/2 in global namespace