Change Doxygen error codes to start at 740 instead of at 720 as the latter was
taken by Scilab in the meanwhile.
Resolve conflicts in autodoc_runme.py once again.
Setting properties on classic classes was broken in swig-3.0.3 by attempting to use __setattr__. This regression is fixed now by using __dict__ again when using -classic.
Fixes patch #232.
* ptomulik-fix/py-object-const:
constant_directive_runme.py and classic classes
additional fixes to %constant directive
make %constant directive to work with structs/classes
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.
Use the proper AUTODOC_METHOD for autodoc strings generation when using
"-builtin", there is no reason to use AUTODOC_FUNC here when AUTODOC_METHOD is
used by default (i.e. without "-builtin").
This allows to (almost) stop differentiating between the two cases in the
autodoc unit test, allowing to simplify it significantly.
Also fix this test to pass after the recent changes removing docstring
indentation in the generated code.
This is unnecessary and inconsistent with "builtin" case in which the
docstrings are not indented in the generated C++ code, thus making it
impossible to write tests working in both cases.
Most of the changes in this commit simply remove the extra whitespace from the
expected values in the tests.
* vadz/py-args:
Allow using enum elements as default values for Python functions.
Don't always use "*args" for all Python wrapper functions.
No real changes, just make PYTHON::check_kwargs() const.
Refactor: move makeParameterName() to common Language base class.
Remove long line wrapping from Python parameter list generation code.
Enum values are just (integer) constants in Python and so can be used as the
function default values just as well as literal numbers, account for this when
checking whether function parameters can be represented in Python.
Also rename is_primitive_defaultargs() to is_representable_as_pyargs() to
describe better what this function does.
Due to what seems like a bug introduced during Python 3 support merge, all the
generated Python functions used the general "*args" signature instead of using
the named parameters when possible.
This happened due to is_primitive_defaultargs() always returning false for the
functions without any default arguments as "value" passed to convertValue()
was NULL in this case and convertValue() always returns false for NULL.
Fix this by checking for value being non-NULL before calling convertValue().
Doing this exposed several problems with the handling of unnamed, duplicate
(happens for parameters called INOUT, for example) or clashing with keywords
parameter names, so the code dealing with them had to be fixed too. Basically
just use makeParameterName() consistently everywhere.
This doesn't play well with PEP8 checks which imposes very strict continuation
line indentation rules which need to be _visually_ aligned, i.e. the subsequent
lines must be indented by the position of the opening bracket in the function
declaration line, but the code generating the parameter lists doesn't have
this information and so it's impossible to do it while avoiding either E128 or
E123 ("continuation line {under,over}-indented for visual indent" respectively)
error from pep8.
Moreover, the wrapping code didn't work correctly anyhow as it only took into
account the length of the parameter list itself and not the total line length,
which should include the function name as well.
So just disable wrapping entirely, long lines shouldn't be a problem anyhow in
auto-generated code.
Make the rules for combining explicitly specified docstring, autodoc one and
the one obtained by translating Doxygen comments implicit in the structure of
the code itself instead of writing complicated conditions checking them.
This results in small changes to the whitespace in the generated Python code
when using autodoc, but this makes it PEP 8-compliant, so it is the right
thing to do anyhow.
Also cache the docstring built from translated Doxygen comments. The existing
code seemed to intend to do it, but didn't, really. This helps with
performance generally speaking (-10% for a relatively big library using a lot
of Doxygen comments) and also makes debugging Doxygen translation code less
painful as it's executed only once instead of twice for each comment.
Finally, avoid putting "r", used for Python raw strings, into docstrings in C
code, it is really not needed there.
Enum values are just (integer) constants in Python and so can be used as the
function default values just as well as literal numbers, account for this when
checking whether function parameters can be represented in Python.
Also rename is_primitive_defaultargs() to is_representable_as_pyargs() to
describe better what this function does.
Due to what seems like a bug introduced during Python 3 support merge, all the
generated Python functions used the general "*args" signature instead of using
the named parameters when possible.
This happened due to is_primitive_defaultargs() always returning false for the
functions without any default arguments as "value" passed to convertValue()
was NULL in this case and convertValue() always returns false for NULL.
Fix this by checking for value being non-NULL before calling convertValue().
Doing this exposed several problems with the handling of unnamed, duplicate
(happens for parameters called INOUT, for example) or clashing with keywords
parameter names, so the code dealing with them had to be fixed too. Basically
just use makeParameterName() consistently everywhere.
Sphinx is smart enough to use the docstrings following the constant definition
in Python code as its documentation, so doing this is still useful even if
Python itself doesn't support having docstrings for the variables (and this is
why it's impractical to write a unit test for the changes of this commit: we
can't easily extract the generated docstrings).
This makes the code more readable and more extensible as more flags are easier
to add in the future than more boolean parameters.
No user-visible changes.
Update Doxygen-specific Python unit tests to work with the new indentation.
Update one of Doxygen-specific Java tests to still build with the new handling
of srcdir.
This doesn't play well with PEP8 checks which imposes very strict continuation
line indentation rules which need to be _visually_ aligned, i.e. the subsequent
lines must be indented by the position of the opening bracket in the function
declaration line, but the code generating the parameter lists doesn't have
this information and so it's impossible to do it while avoiding either E128 or
E123 ("continuation line {under,over}-indented for visual indent" respectively)
error from pep8.
Moreover, the wrapping code didn't work correctly anyhow as it only took into
account the length of the parameter list itself and not the total line length,
which should include the function name as well.
So just disable wrapping entirely, long lines shouldn't be a problem anyhow in
auto-generated code.
