Hello Wayne,

Yet.  I'm sure they are going to have to implement it at some point.
You can always write your own swig wrapper something like this:
They had 5+ years to add support, they didn't. So I wouldn't count on it.
As some of you may or may not know, the new wxpython project phoenix is
using sip instead of swig so that in and of itself may put us in a
position where we have to change to sip.  I would rather wait and see
what shakes out with the new wxpython implementation rather than head
down a path that only has to be changed yet again.
And another break, will we support SWIG, SIP and an interop layer?
With this message I want to ask what is the common view whether it is
okay to have SWIG thumbscrew the project's source code, considering
there are alternative generators, and generatorless libraries like
pybind11. Of those alternatives I would *personally* prefer the latter,
as it is no black box and the binding generation is part of the normal
c++ source code.
Honestly, changing scripting language generators does not thrill me at
this point in the project.  It would most likely break all of the python
scripting work done thus far which would create a lot backlash.
It will only get worse as time is passing by building upon the current state.

I think we need
1) a specified python API
2) adapters that match the specified API to the source code
3) Helpers to generate the necessary binding from the API adapters. This can be done with the aid of libraries or manually.

It seems none of that is currently available, the current unspecified API holds the source code tight, with a generator that hinders refactoring to modern c++ style. So we only lose on both sides.


Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to