Python function annotations containing C/C++ types are no longer
generated when using the -py3 option. Function annotations support
has been moved to a feature to provide finer grained control.
It can be turned on globally by adding:
%feature("python:annotations", "c");
or by using the command line argument:
-features python:annotations=c
The implementation is designed to be expandable to support different
annotations implementations. Future implementations could implement
something like the following for generating pure Python types:
%feature("python:annotations", "python");
or typing module types to conform to PEP-484:
%feature("python:annotations", "typing");
Closes#1561
Issue #735
template_typedef_cplx2 files are generated by the template_typedef_import.multicpptest
but can also be cleaned by the template_typedef_cplx2.cpptest target.
* commit '8245277ad3':
Remove test for unsupported complex or _Complex by itself
More C99 complex fixes, plus Python tests
Restore _Complex as standalone type
Small corrections for handling C99 _Complex
Properly handle C99 complex types even in C++ mode
Conflicts:
Examples/test-suite/python/complextest_runme.py
* remove-dependency-on-2to3:
Remove need for Python 2to3
Modify examples to be both Python 2 and 3 compatible
Remove python3 specific runme3.py test files
Convert python tests using 2to3
Convert python test scripts to be Python 2 and 3 compatible
Convert swigobject python test to be python 2 and 3 compatible
Convert two tests to work with both Python 2 and 3
Improve director_exception Python test
Remove further print statements from Python tests
Improve Python testing catching exceptions
Improve contract Python testcase testing
Remove print statements from Python tests
All Python examples and tests have been written to be both Python 2 and Python 3
compatible, removing the need for 2to3 to run the examples or test-suite.
The 2to3 executable is not always available and even when available does not
always work, e.g. with pyenv. An alternative would be to use the lib2to3 Python
module instead, but this isn't available in some older versions of Python 3.
I had this problem on Ubuntu Bionic on Travis:
checking Examples/python/callback
pyenv: 2to3-3.8: command not found
The `2to3-3.8' command exists in these Python versions:
3.8
3.8.1
Reference issues:
https://github.com/pypa/virtualenv/issues/1399https://travis-ci.community/t/2to3-command-not-found-in-venv-in-bionic/4495
This error is given for any use of variable called "l" (and also "I" and
"O", but we don't seem to have any of those) and it doesn't seem to be
worth changing this variable name in the tests code, as it's really not
that meaningful there anyhow, so just disable the warning to let the CI
builds, which now use pycodestyle 2.6, instead of 2.5 which didn't have
this error and which is still the latest available in Debian Sid, pass.
This testcase was only run in Ruby and Python and implements an
obscure feature where a C++ class inherits from a std::wstring.
The li_std_wstring test is left in place to be modified in next commit
for more regular wstring testing across all languages.
- std::unordered_map compilation fix when just using std_unordered_map.i standalone
- std::unordered_multimap compilation fix when just using std_unordered_multimap.i standalone
- Add in the standalone unordered STL test cases
Closes#1319
When there is just a _runme3.py file and no _runme.py file, out of
source builds were not running the script.
Currently only applies to python_abstractbase_runme3.py.
Add optional moduleimport attribute to %module so that the
default module import code can be overridden. See the
"Searching for the wrapper module" documentation in Python.html.
Example:
%module(moduleimport="import _foo") foo
$module also expands to the low-level C/C++ module name, so
the following is the same as above
%module(moduleimport="import $module") foo
Issue https://github.com/swig/swig/issues/769
The metaclass (SwigPyObjectType) for SWIG objects was not defined in
a way that let importlib successfully import the Python wrappers.
The pickle module failed because it couldn't determine what module the
SWIG wrapped objects are in.
I've changed the definition of SwigPyObjectType using more normal
builtin type definitions. There are still some open questions:
- None of the builtin types, like swig_static_var_getset_descriptor and
SwigPyObject are added into any module. No call to PyModule_AddObject
is made, so isinstance cannot be used for any wrapped type, all of
which are derived from SwigPyObject.
Closes#808
If the wrong return type in the hash function was used, an error:
SystemError: error return without exception set
was raised
Add some tests for testing builtin slots
SWIG-3.0.5 and earlier sometimes truncated text provided in the docstring
feature.
SWIG-3.0.6 gave a 'Line indented less than expected' error instead of
truncating the docstring text.
Now the indentation for the 'docstring' feature is smarter and is
adjusted so that no truncation occurs.
Closes#475
Previously SWIG looked at the indentation of the first line and removed
that many characters from each subsequent line, regardless of what those
characters were. This was made worse because SWIG's preprocessor removes
any whitespace before a '#'. Fixes github issue #379, reported by Joe
Orton.
Default values are no longer generated as Python code by default.
They must be explicitly turned on using the "python:defaultargs" feature.
Closes#294Closes#296
The problems in these two issues when "python:defaultargs" is turned
on still need to be fixed and should be addressed in separate patches.
The important thing is the default code generation is now fixed.
