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