kicad-developers team mailing list archive

[Florian Delizy <florian.delizy@...>]

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

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