← Back to team overview

kicad-developers team mailing list archive

Re: Python support -- SWIG and what about lua?

 

Thanks Tim.

Lua does sound interesting. But I have some reservations about it.

Before I forget, here is something of interest:

http://www.twistedmatrix.com/users/glyph/rant/extendit.html


There are difficulties for developers, and there are difficulties for users. There are benefits for developers, and there are benefits for users. Sometimes we developers can pay a price if the benefits to the users are to come later.


I think to ask a user to learn Lua is asking too much. Heck, even I don't know it, and I've been writing code for 25 years. I would not invest in learning it. So there, benefit lost on me as your user. There must be 100 python programmers for every lua programmer. Also, size does not matter on today's hardware. Disk-space and memory are abundant. What is a concern is packaging and installation for a user. All this is more important than the idea that Lua may actually be a better embeddable language than Python, faster smaller, whatever.

I like Python because of its uniform style. I find I simply cannot read C++ programs that don't follow my indenting style, it slows down productivity by 5. Python deals with this. Python is contemporary and gaining momentum. It has huge libraries in the area of XML, networking, etc. It a VERY LARGE toolbox.

And lastly, it seems we have a volunteer to do the Python integration. Would one exist Lua?


Dick



Tim Hanson wrote:
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 :)






Yahoo! Groups Links







--
Best Regards,

Dick

*** If he runs, I will be supporting Tom Tancredo for President in 2008. ***
http://tancredo.house.gov/
http://www.teamtancredo.com/
http://tancredo4prez.blogspot.com/







References