kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.
>  
> --
>  
> About the pythonish API:
> Although this sounds good, I'm sceptical - simply because the very
> limited ressources of the KiCad developers,
> something like this has to be regularly maintained. This means
> documentation too, both C++ and Python.
>  
> As Miguel has written, there is already some work by Piers Titus van der
> Torren, see
> https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
>  
> I've not used that, because I've found it easy enough to work with the
> swigged functions.
> Even when internals are refactored, in most cases I've found it easy to
> adapt my scripts, this is only an issue between
> the releases - even with an abstraction layer you don't know if
> something has to be changed.
>  
> Python helper functions would be nice, but I'd still like to have full
> access to as much as possible PCBNEW methods.
>  
> --
>  
> In my opinion the work should be invested elsewhere - for instance a
> launcher for python scripts is missing.
> Sure there is a console, but ideally I'd like to press a button, a
> keystroke or similar to launch my script.
> Also several functions are not yet wrapped, like the P&S router or the
> tool framework (working with selections etc.).
>  
> Thanks,
> Torsten
>  
>> when activating python bindings on my msvc build with a few refactor
>> commits applied, it came to my attention that SWIG simply does not
>> support std::unique_ptr.
>>
>> 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.
>> There's been a discussion on the irc channel regardings this and also
>> the dependency on having wx exported as well. So I thought the logical
>> consequence would be to broaden the audience and move the discussion here.
> 
> Hi Michael,
> 
> It may sound controversial, but I'd say using SWIG is a bad idea: we
> expose for the people the internal APIs of pcbnew that we intend to
> refactor in the near future. Any change to the BOARD storage model means
> a change to the scripting API. IMHO we should have a more pythonish API
> that hides all C++ stuff from the python side completely and is
> independent from the changes in pcbnew's core.
> 
> Cheers,
> Tom
>  
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>