kicad-developers team mailing list archive

[Tim Hanson <tim@...>]

I agree. I've used SWIG in a large C++ program with embedded python, and it was mostly not worth 
the effort; we had to keep around some perl scripts to make the generated SWIG code & headers mesh 
with the rest of the compile. not at all clean. That said, I don't know anything about boost.python 
(other than that boost itself is quite huge - is this true for boost.python?)

I have tried Lua and it is great (for an embedded scripting language) compared to python! small, 
lightweight, simple, designed to be embedded, and no excess junk functionality. I also tried Java 
(like Dick H), and it was a bit of a pain - but that was 4 years ago so I'm no expert. Lua has wx 
bindings too.

> For the python support to be complete, we need to develop a bridge
> into the C++ classes BOARD, MODULE, and 12 or so other classes. After
> that, a person could use python to write import and export scripts,
> BOM scripts, and font size change scripts, and complete UI extensions.

this seems sweet to me. if there is a clever way to automate bridge construction in the code (so to 
speak), then all the better!

DELIZY Florian wrote:
> _._,___
>
> > I looked into the existing python support today. It did not seem
> > complete, and unless I don't understand something, it was less than
> > 15% complete.
>
> Well, I didn't have time to submit it to svn sorry :)
>
> >
> > So I ask:
> >
> > 1) whether we want to support Python?
>
> Yes, I am on it
>
> >
> > 2) if yes, should we consider using SWIG instead of Boost.Python?
> >
> > I think SWIG might be better for this project, because:
> >
> > A) wxPython is based on swig, and wxPython is part of the kicad to
> > python solution. If SWIG is good enough for wxPyton, it would be good
> > enough for KICAD-python.
> >
> Yes, but that's not a concern
>
> > B) Boost.Python may be a bigger tool, but the build environment is
> > overkill and probably harder to get working on both Windows and Linux.
>
> Not true boost.python is multiplatform
>
> >
> > C) If we use, SWIG, we can get bindings to other languages besides
> > Python, such as Java.
>
> You'll still have to write code for that case
>
> > D) The resultant SWIG binaries are easier to distribute if SWIG is
> > used: they are smaller and there is distutil to install them into a
> > python environment.
>
> The resultant of boost is statically linked, and so is definitely
> faster/easier/smaller than SWIG
>
> Plus :
>
> - SWIG is a real pain to interface with
> - SWIG makes use of its own build system
> - You always have to re-build SWIG as part of your dev process
> - SWIG uses a self language (not C++) to describe interface
>
> and some more I forgot ...
>
> > Scope of Work
> > ------------
> >
> > -
> >
> > For the python support to be complete, we need to develop a bridge
> > into the C++ classes BOARD, MODULE, and 12 or so other classes. After
> > that, a person could use python to write import and export scripts,
> > BOM scripts, and font size change scripts, and complete UI extensions.
> >
> > I am in favor of it, and could get it done, but I don't have the time
> > to do it now, (if I were only retired, or funded...).
> >
> > Is the original developer of the python interface still around and
> > interested and capable?
> >
>
> Right now working on it :)