These remaining warnings are due to the design of Python's C API,
so suppress them by casting via void(*)(void) (which GCC documents
as the way to suppress this warning).
Closes#1259.
* vadz-better-param-names:
Enable keyword arguments for keyword_rename unit test
Update error messages test suite
Add more tests for Python parameter renaming
Improve handling parameters clashing with language keywords
- Static method wrappers were using the 'fastproxy' approach by default.
This is inconsistent with instance method wrappers. The fastproxy approach
is now turned off by default to be consistent with instance methods.
Static method wrappers can now also be controlled using the -fastproxy and
-olddefs options.
Example:
struct Klass {
static int statmethod(int a = 2);
};
generates:
class Klass(object):
...
@staticmethod
def statmethod(a=2):
return _example.Klass_statmethod(a)
instead of:
class Klass(object):
...
statmethod = staticmethod(_example.Klass_statmethod)
- Modernise wrappers for static methods to use decorator syntax - @staticmethod.
- Add missing runtime test for static class methods and using the actual
class method.
Previously, only Python tried to preserve the original parameter name
(by prepending or appending an underscore to it, but otherwise keeping
the original name) if it conflicted with one of the language keywords,
while all the other languages replaced the parameter name with a
meaningless "argN" in this case.
Now do this for all languages as this results in more readable generated
code and there doesn't seem to be any reason to restrict this to Python
only.
Global functions previously generated two definitions, eg:
def foo():
return _example.foo()
foo = _example.foo
The first definition is replaced by the second definition and so the second definition
is the one used when the method is actually called. Now just the first definition is
generated by default and if the -fastproxy command line option is used, just the second
definition is generated. The second definition is faster as it avoids the proxy Python
method as it calls the low-level C wrapper directly. Using both -fastproxy and -olddefs
command line options will restore the previously generated code as it will generate both
method definitions.
With this change, the wrappers for global C/C++ functions and C++ class methods now work
in the same way wrt to generating just a proxy method by default and control via
-fastproxy/-olddefs options.
Closes#639.
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
* adr26-master:
Cleanup accessing/decref of globals, to avoid code bloat in init function.
Fix ISOC build errors.
Fix unused variable warning.
#1360: Leak of SWIG var link object
Conflicts:
CHANGES.current
When using -builtin, the two step C-extension module import is now
one step and the wrapped API is only available once and not in an underlying
module attribute like it is without -builtin. To understand this, consider a
module named 'example' (using: %module example). The C-extension is compiled into
a Python module called '_example' and a pure Python module provides the actual
API from the module called 'example'. It was previously possible to additionally
access the API from the module attribute 'example._example'. The latter was an
implementation detail and is no longer available. It shouldn't have been used, but
if necessary it can be resurrected using the moduleimport attribute described in the
Python chapter of the documentation. If both modules are provided in a Python
package, try:
%module(moduleimport="from . import _example\nfrom ._example import *") example
or more generically:
%module(moduleimport="from . import $module\nfrom .$module import *") example
and if both are provided as global modules, try:
%module(moduleimport="import _example\nfrom _example import *") example
or more generically:
%module(moduleimport="import $module\nfrom $module import *") example
The module import code shown will appear in the example.py file.
The implementation for a renamed constructor for -builtin no longer
uses the same implementation for non-builtin mode which makes a call
into the compiled C module, eg _constructor_rename for a module called
constructor_rename. The output in the constructor_rename.py file is now:
RenamedConstructor = new_RenamedConstructor
instead of
def RenamedConstructor():
val = _constructor_rename.new_RenamedConstructor()
return val
when wrapping:
struct Foo {
%rename(RenamedConstructor) Foo();
Foo() {}
};
See the constructor_rename.i testcase.
This change has been made to make the wrapper more efficient and is a
step towards the next commit which will remove duplicating the symbols
in both the pure Python module and implementation C module
(constructor_rename and _constructor_rename respectively in this case).
When using the moduleimport option, such as:
%module(moduleimport="import $module") example
the minimum Python version check disappeared from the generated Python
file. The code has been refactored and _swig_python_version_info is
no longer deleted after initial use as it can be used in a few places,
in particular, when -builtin is used.
This option turned off the insertion of Python import statements
derived from a %import directive. For example given:
%module module_b
%import "module_a.i"
then module_b.py will contain:
import module_a
This option was originally added in 658add5, apparently to fix some sort
of circular import problem of which there are no details. It is
undocumented and is now removed as part of the simplification of the
SWIG Python command line options for SWIG 4.
Issue #1340.
Both the command line and %module options of the same name have been
removed. These were undocumented. The -outputtuple option returned a
Python tuple instead of a list, mostly typically in the OUTPUT
typemap implementations.
It unclear why a tuple instead of a list return type is needed and
hence this option has been removed as part of the simplification of
the SWIG Python command line options for SWIG 4.
Issue #1340.
The -cppcast option is still turned on by default. The -nocppcast option
to turn off the use of c++ casts (const_cast, static_cast etc) has been
removed. However, defining SWIG_NO_CPLUSPLUS_CAST will still generate C casts
instead of C++ casts for C++ wrappers.
This a revert of commit fc79264a48:
"Revert "Remove -cppcast and -nocppcast command line options""
The Scilab and Javascript casting problems are now fixed, so -cppcast
is now switched on as default.
The -cppcast option is still turned on by default. The -nocppcast option
to turn off the use of c++ casts (const_cast, static_cast etc) has been
removed. However, defining SWIG_NO_CPLUSPLUS_CAST will still generate C casts
instead of C++ casts for C++ wrappers.
This option controlled the __repr__ proxy class method.
Also removes:
-old_repr
-oldrepr
-new_repr
-newrepr
Note: -newrepr was and remains on by default. When -oldrepr/-old_repr
option resulted in code that did not run.
This option was for backwards compatibility with very old versions of
SWIG that generated a shadow 'XPtr' class derived from proxy class X.
If anyone is still using these, they are best off using the actual proxy
class, or otherwise add them in manually using %pythoncode.
Issue #1340.
This option was originally added to help users switch to using
-fastunpack so that typemaps using obj0 did not need changing by
providing an alias for swig_obj[0] to obj0. The correct solution was
always to replace obj0 with $self in the typemap. This is now mandatory.
However, the -nofastunpack option can still be used to circumvent using
the mandatory typemap change.
The -nofastunpack option has been left in as there isn't much code
simplification in removing the nofastunpack code. This is because the
nofastunpack code is still sometimes needed (eg varags and overloaded
functions).
Python fixed many APIs to use const char * instead of char * at around
Python 2.4. As we support 2.7 and later, we can now remove the non-const
string usage.
Types changed:
PyArg_ParseTuple
PyArg_ParseTupleAndKeywords
PyArg_UnpackTuple
PyDict_SetItemString
PyMethodDef
PyModuleDef
SWIG_Python_UnpackTuple
SWIG_Python_str_FromChar
SWIG_addvarlink
swig_const_info
This option, if used, has not had any effect on Python 3 code since commit a863d3 9 years ago.
I think we can assume that it is not needed for Python 3.
Running the examples and test-suite (Python 2) doesn't change the code
paths with and without -safecstrings because only SWIG_OLDOBJ and SWIG_NEWOBJ
are used in the typemaps and the following code is thus unaltered by -safecstrings
(which sets SWIG_PYTHON_SAFE_CSTRINGS):
%#if defined(SWIG_PYTHON_SAFE_CSTRINGS)
if (*alloc != SWIG_OLDOBJ)
%#else
if (*alloc == SWIG_NEWOBJ)
%#endif
{
*cptr = %new_copy_array(cstr, len + 1, char);
*alloc = SWIG_NEWOBJ;
printf("safe strings: %s\n", *cptr ? *cptr : "NULLSTRING");
} else {
*cptr = cstr;
*alloc = SWIG_OLDOBJ;
}
Note: nosafecstrings was also the default and -O didn't actually change this.
A custom implementation for Py_None was implemented in SWIG_Py_None().
This was used by default on Windows only. It isn't clear why this
was done just for Windows. Now Py_None is the real Py_None on all
operating systems.
This option runs the equivalent init code in Python C code instead of pure Python code.
The init code adds the C++ pointer into the 'this' variable.
If the variable already exists, it appends it. This
seems to only happen in directors and multiple inheritance, see
PyMulti in director_basic_runme.py.
We only still default to generate a no-op __del__ method for theoretical
compatibility with old code, and 4.0.0 is a good time to make a cut-off
should such code really still exist.
On the flip-side, the presence of a __del__ method seems to be able to
prevent garbage collection from kicking in (see #1215), so it's
definitely desirable to get rid of it when there's nothing for it to do.
Conflicts:
Source/Modules/python.cxx
This is a cherry-pick and merge from the patch in #1261
What SWIG calls "modern" classes are supported by Python 2.3 and up
which means they're supported by all the Python versions we aim to
support in 4.0.0.
Conflicts:
Source/Modules/python.cxx
This is a cherry-pick and merge from the patch in #1261
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
Fix when using -builtin and wrapping std::map, std::set, std::unordered_map or
std::unordered_set to ensure __contains__ is called. This is a wrapper for the STL
container's find method. Without it, Python will do its own slower sequence search.
