← Back to team overview

kicad-developers team mailing list archive

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


Florian Delizy wrote:
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! :-)

Well, I can’t agree more, last time we (my company) decided to use
KiCAD for several projects, but they were eventually outsourced, so I
kind of lost the time I had for it …

really sorry about that, I start over on my own now

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.

I feel the same

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

will do

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

good to hear that

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:

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

at least you made your point clear. I didn’t think about WF (didn’t
now the concept before even reading you), why not, I will read about

about the use cases, here are some I had in mind :

- Export/Import scripts in python (IGES, industry proprietaries, Mentor etc etc)
- Automate production files generation
- Integration with source revision control (eg svn)
- Integration with other CAD systems (for industrial use) (exporting
importing mechanical constraints, thermal simulations etc)
- Integration with other part management systems (automate BOM, and
order, calculate pricing and lead times)
- Integration with simulation software (integrate directly simulation
results in pcb/board editor)
- Allow simultaneous work by multiple peoples (for complex boards)

well, I understand your points about the « no binding » policy (and
respect that), but then again, I don’t see how to perform all of that
in C++ (ok ok, we can make them plugins, but generally, python or any
script is more flexible to use).

Patrick has some python code that can load a BOARD (*.brd) file. The Wizard Fountain is a new idea I just had 5 days ago, does not exist, is an incubator from which pure python solutions can arise to solve real problems, without munging the C++ source code or acting like a ball and chain on the evolution of the C++ code.

I have an enormous amount of experience bridging languages like what swig wants to do. Recall I even wrote a JVM, that means I wrote the JNI support. Then I wrote an enormous amount of stuff that sits on JNI, etc. I know how cumbersome it can get.

For now, what I am saying is let python solutions be done entirely in python, let someone else maintain the python to UI code, (the wxpython project) and let's for the first time provide a place where python scripts can live within the Kicad project, and do so in way where the user does not have to become a python genius. I think this is all good, and you have a chance to direct the evolution of the structure of the python scripts and how they interact with your Wizard Fountain.


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

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

will do

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.

hum, why not, but I am not sure that would much help :)

C) Then write the Wizard Fountain.

if we agree on that, will do too

oh, and btw, the python 3.x thing is one good point of swig : it is
not us who will maintain the resulting binding, only a small part of
it needs to be changed (the c++ calling system)

Follow ups