← Back to team overview

kicad-developers team mailing list archive

Re: Python support in kicad (yes, I am --very -- late)


Florian Delizy wrote:

I had really few time the past year to work on KiCAD, I started the
integration of python support into KiCAD but never finished it (really
sorry for that).

Since I finally have time to look at it, I start again today, I see
that my old code is still present (but unlikely to even compile), I’ll
start cleaning it out.

back then I used boost::python to include it, I consider now this as a
mistake (regarding the developements of boost), I’ll then turn to
SWIG. Here are my plan :

– Remove the old code (all of it)
– Remove dependency to boost::python (I saw that other code is using
boost elsewhere, so I wont remove boost, unless you think I should)
– Start over the thing with SWIG

Advantages of SWIG are (now) :

– Support 3.x flavor of python (SWIG community maintains it as it si
moving, so no hassle for us)
– Support for lot of other languages
– Can automate interface and doc generation
– Wx is bound using SWIG

what do you say ?

Hello Florian, one our python champions! Nice to hear from you again.

The last time we had notice of you was when you snuck into the kitchen for a midnight snack, and left python cookie crumbs all over the floor! :-)

My opinions follow:

1) Python has a warm place in my heart.

2) Python is undergoing transition from 2.x to 3.x, this affects the C API, and the python source code.

3) I only like 3.x python.

4) I think we should remove the python statements from Kicad C++ code altogether.

5) We are using boost elsewhere, so removing dependencies on boost is a no no.

6) I would like to start supporting python scripts, but *not from within the C++ code*, but rather from a "Wizard Fountain". This means no swig. No C++ to python bindings until later, see below.

The Wizard Fountain:
This is an incubator and launchpad for python scripts which users could use if they had wxpython installed. Any of the scripts invoked from here should operate like a wizard, you know like step-wise dialog boxes. The Wizard Fountain (WF) would be launched from the Kicad project manager with a new icon. Again, WF is written in wxPython. But it in turn can call python scripts that are placed into dedicated directories. There would be a directory tree dedicated for these scripts, and the directory tree names and structure would be mimicked by a menu system within WF. That is, WF would build a menu hierarchy exactly like the dedicated directory structure, using directory names as sub-menu names, and script names as menu choices.

So you could determine the menu used to invoke a script simply by placing the script in a sub-sub-sub-directory of a proper name.

Somebody that did not want this facility would not install wxpython, however I don't see a problem including the python scripts as part of the stock Kicad install.

Python scripts can communicate with Kicad by way of files. That is, we do not have a clear use case to bind python into the C++ code, because anything that we would need for that can best be done in C++.

Maybe we can pull in Patrick's python BOARD library.

Some day, should we ever re-write the BOARD storage model, I would suggest that we do that as a shared object (DLL) without user interface. Keep the UI code out of the data tree management DSO, but park it on top of the DSO, as a separate C++ link image that sits on top of the storage model DSO. Then at that point, you could argue that parking python on top of that C++ DLL would make sense. Until then, I will oppose any C++ to Python binding except in one other place, and that is in the footprint retrieval plugins, which are free to do anything they want to do. (Because anyone can write them, and by definition we will not have control over every one of them.)

Having said all this, I cannot get excited about python again until the python world fully crosses over into 3.x. I cannot find wxpython for python 3.1, and I think to make a big investment in python until it decides to follow its leader is a mistake. I have converted code from 2.x to 3.1, but why should we have to do that. It makes better sense to start with 3.1 or 3.x.

*I don't want to see any swig code munging the core C++ source.*

I don't know what Jean-Pierre or Wayne think about this.

So to summarize my opinion, what could you, Florian, do to best help the project?

A) remove the dis-functional python code from KIcad's C++ source.

B) Get into the wxpython mailing list and complain like a mad-man that it is way past time for them to support 3.x python. Make it happen, quote this list if you have to.

C) Then write the Wizard Fountain.


Follow ups