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
This examples tests the SWIG generated module being placed into a directory and
then renamed __init__.py to convert the module into a package. This ability
stopped working in swig-3.0.9. However, only Python 2.7 or 3.3 and later work. If
Python 3.2 support is needed, use moduleimport in %module to customise the import
code.
Issue #1282
Getting these kind of errors on Appveyor which uses mingw/cygwin to run
a Python interpreter:
Native windows Python 3.6 running under cygwin and mingw Python 3.7 running under mingw:
Fatal Python error: _Py_HashRandomization_Init: failed to get random
numbers to initialize Python
Cygwin Python 2.7 running under cygwin:
0 [main] python2.7 496 child_info_fork::abort: address space needed by '_foo.dll' (0x6D0000)
is already occupied
There were only needed to support Python < 2.2, and we now require at
least Python 2.6.
Conflicts:
.travis.yml
Examples/test-suite/python/autodoc_runme.py
Source/Modules/python.cxx
This is a cherry-pick and merge from patch in #1261
Complete the prototype removal in ca1431.
The script prevents SWIGTOOL=gdb from working as gdb can't be used to
debug a shell script, it requires a binary.
Add support for SWIGTOOL in all the examples.
SWIG_LIB_DIR and SWIGEXE must now instead be set by all Makefiles.
See issue #473.
-- The commit propagates the package option to the newly create
module node so it is recognized by SWIG
-- Added a relativeimport test for this combination
(in lack of py3 I was not able to test it with py3 but it
"should just work")
- 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
This changeset resolves several issues related to python imports.
For example, it's possible now to import modules having same module
names, but belonging to different packages.
From the user's viewpoint, this patch gives a little bit more control on
import directives generated by swig. The user may choose to use relative
or absolute imports (docs are provided in separate PR).
Some details:
- we (still) generate import directives in form 'import a.b.c' which
corresponds to absolute imports in python3 and (the only available)
ambiguous one in python2.
- added -relativeimport option to use explicit relative import syntax
(python3),
Tests are under Examples/python, these are in fact regression tests but
with the current swig testing framework it seems to be impossible to put
appropriate tests under test-suite.
Closes#7