If python_append.i is modified to use:
__slots__ = []
instead of
__slots__ = ["this"]
then this additional error checking prevents a crash and shows a stack trace and error:
AttributeError: 'ForSlots' object has no attribute 'this'
Related to issue #1674
Don't attempt to use the class's __dict__ for setting 'this' when
a user has extended a class with:
__slots__ = ['this'].
Was segfaulting. Now we fall back to a simple PyObject_SetAttr if the
usual approach to setting 'this' in __dict__ does not work.
Closes#1673Closes#1674
Instead of silenty ignoring them, now a "TypeError: f() takes no keyword arguments"
exception is thrown if keyword arguments are used. Hence constructors and normal
methods/functions behave in the same way.
Closes issue #1595
The typecheck typemaps succeed for non pointers (SWIGTYPE, SWIGTYPE&,
SWIGTYPE&&) when the equivalent to C NULL is passed from the target
language. This commit implements a fix for Python to not accept a Python
None for non-pointer types.
Issue #1202
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.
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
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.
An error was not being set if an implicit conversion was attempted
calling an explicit constructor.
Fixes:
Fatal Python error: a function returned NULL without setting an error
SystemError: <built-in function new_A> returned NULL without setting an error
File "Examples/test-suite/python/implicittest.py", line 106 in __init_
I've moved the initialization of statics a little earlier on - a little
safer as it is hard to follow exactly when some of these were being
used, such as SWIG_Py_None which sometimes replaces Py_None.
Avoid casts between incompatible function types where possible (when
keyword args are in use, it is not possible to avoid such warnings as
they are inherent in the design of Python's C API in that particular
case). Fixes#1259.
Fix Coverity issue reported for SWIG_Python_ConvertFunctionPtr:
"Execution cannot reach this statement: *ptr = vptr;"
Because if 'ty' is null, then desc becomes null and we return with
SWIG_ERROR. So 'ty' cannot be null at 'if (ty)'.
* coleb-python35_dtor_exception_fix:
Add test case for Python 3.5 assertion with a pending StopIteration
Amend python_destructor_exception runtime test
Call PyErr_WriteUnraisable if a destructor sets a Python exception (-builtin)
Extended zjturner's changes to encompass all function dispatch and use PyErr_WriteUnraisable to handle exceptions during __del__.
Python - Save and restore exception state before calling destroy.
* ahnolds-python34:
Python tp_allocs -> tp_next corrections
Cosmetic correction for Python tp_version -> tp_version_tag
Add -Wmissing-field-initializers to python Travis testing
Python 3.3 builtin missing field initializers added
Adding tp_finalize field to PyTypeObject for Python 3.4 and -builtin
Adding nb_matrix_multiply and nb_inplace_matrix_multiply fields to PyNumberMethods for Python version 3.5 and up
Adding tp_finalize field to PyTypeObject for Python version 3.4 and up
Fix error when append on a SWIG Object with -builtin:
x.append(10)
SystemError: error return without exception set
Having append and next methods on a SWIG object by default doesn't seem
right to me though.
PyObject_CallFunction has the potential to silently drop the active
exception. In cases where the user just finished iterating a
generator, StopIteration will be active. Most of the time this
is fine because destroy() won't raise an exception. On Python 3
however, and with a debug interpreter, you will get an assertion
failure inside of Python. And in the worst case scenario, if
destroy() does throw an exception, the intepreter probably won't
be able to correctly detect the end of the iteration.
