I'm going to make an executive decision here so this doesn't drag on.
In short, swig stays. Any other python bindings would either be on top
of or along side current swig bindings. Swig is a valid tool for
generating scripting language bindings. Lots of other projects use it
with great success so it can't be all bad. We already have a large
investment of time in the current swig bindings along with lots of
project and user scripts that use them. I do not want to discard that
investment of time and effort. If anyone feels so inclined to write
some other python interface, there cannot be namespace clashes with the
current python bindings.
On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:
Hi Tom & Michael,
I'm using the scripting interface quite often and had never that much
trouble with it.
The currently missing std::unique_ptr is not an argument, it is still
possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
I'm quite sure that in the future almost any C++ 11 features will be
supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is
exactly the downside.
You have to write wrappers yourself, while with swig you're simply
including headers in the *.i files.
