← Back to team overview

kicad-developers team mailing list archive

Re: Python support

 

If we do the Python binding well, then the features that it adds are
so compelling that I think the Python support gets to where it is no
longer optional. If we do it wrong, Python support just gets in the
way. I would like to see the Python be mandatory, but for that it
must be done well.


If we do it right, then the Python support will have earned the right
to impact the class inheritance hierarchy fundamentally, and that
means that PyCXX should be on the table for consideration.


It sounds like you have spent a good bit of time with SWIG, and so I
am now comfortable eliminating that from consideration as I realize
there is often more than one right way.


It sounds like you have done a lot of work that is not checked into
the SVN. Please please merge your work with the *latest* source, as I
have spent the last week running many of the source files through a
C++ beautifier, and that work cannot be lost or my head will explode.


Also, I would encourage you to look at PyCXX. Because as I said, if
we are committed to doing the Python support right and thorough, then
putting PyObject underneath the EDA_BaseStruct is no problem, we can
start to make Python the dog that wags the C++ tail. But the dog
needs to be handsome, well behaved, and fetch the paper for us.


I think Python is the right choice for a scripting language. I think
you deserve credit for pioneering this idea. But please, just don't
bring us a pitbull, they bite and kill people.


Thanks,

Dick



> > 1) How much time did you spend with SWIG?
> About a day or two reading all their doc, looking for what I needed, 
> asking people but it still lacks important features that are needed ... 
> (and I don't really want to code it ...)
> 
> >
> > 2) Are you aware that Boost.Python seems to require a different syntax
> > for various C++ compilers? (Microsoft) And that since it uses C++
> > templates it will ask more of the C++ compiler, i.e. pushing it?
> Give me some examples, since Boost.Python is quite multiplatform,
and it 
> compiles fine under gcc, VC, and codewarrior (without being touched ...)
> 
> Anyway we only build it under gcc ...
> 
> > 3) If we wanted a very clean binding, it might even make sense to
> > consider http://sourceforge.net/projects/cxx/ 
> > <http://sourceforge.net/projects/cxx/>
> never used it ...
> > Note that I have _a lot_ of experience with interfacing Java to C++,
> > and that experience tells me that a bolt on approach might not be as
> > good, long term, as an approach that could make the KICAD classes in
> > C++ be _fundamentally_ compatible with python.
> that's a quite a long job (more than 6months I'd say), so that's an 
> interesting long term approach, but I can not afford it ....
> 
> Many things need to be rewritten to follow that ...
> 
> > Therefore PyCXX, or something like it, at least needs consideration as
> > well. Let's just consider it and discuss it. We might be able to
> > tuck a base class underneath the existing C++ classes since they are
> > all derived from the same base class already.
> I have to read more about PyCXX, but I am opened to any discussion...
> 
> > And if we have not played with SWIG, let's play with it. A couple of
> > days spent experimenting will help us find the optimal solution.
> Have fun, I tried already to find essential features :
> - Python callable abstraction (call python code from python)
> - Python callback abilities
> - exception handling ....
> - ability to link against swig (not rebuild it anytime you want to 
> change the interface)
> 
> 
> and more I forgot ...
> 
> 
> > You wouldn't start framing a house until the floor plan is agreed to,
> > and in fact you wouldn't want the lumber laying around the jobsite,
> > getting in the way, until the concrete foundation is poured. That
> > lumber getting in the way is my big concern, long term.
> Well, sorry, but we are already painting that house ... Again, any 
> change already implies rewrite...
> 
> >
> > And yes, I want the nicest house possible.
> 
> So do I
> 
> 
> Anyway, if you want to discuss about it, pleae feel free to contact me 
> directly : florian DOT delizy AT gmail DOT com (google talk if you use 
> it too), I'm in Paris (CEST+1 timezone)
>








References