kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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
> > altogether.
>
> will do
>
>
> > 5) We are using boost elsewhere, so removing dependencies on boost is a no
> > 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
> it.
>
> 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.

Dick


> > 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.
>
> 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)