Another point is that there are far more programmers around familiar with Python than Lisp/Lua.
In the extreme case there would be major problems if a core feature was written in an obscure language by an expert who then dropped out of the project.
Yeah I see how wxPython makes it difficult to find an alternative… and none of the bindings to other languages are well maintained it seems.
There are no plans to introduce any other scripting language than Python (and Lisp in particular - Kicad is an EDA tool, not an operating system like Emacs ;-).
The current Python API is not stable as it directly reflects the internal C++ model. Making a stable API wrapper is on our to-do list, but there’s no manpower. Any Python experts wanting to help here?
Tom
Hi @twl
you may have a look at @hyOzd work here:
Kicad has a python api which is automatically created from the C++ API using a tool called SWIG. This API isn’t very pythonic, it feels like a c++ library and doesn’t have the ease of use and flexibility of python. So, some developers decided to create a wrapper around this API, called kicad-python 7. I believe their aim was to create a simpler and better documented scripting interface for kicad.
Notice that kicad-python, doesn’t call the C++ API directly, so it isn’t a replacement of actual python API of kicad, but is a wrapper around it.
About my fork of kicad-python; it wasn’t actively developed at the time I saw it, so I decided to fork it and add some features. It’s far from complete, and I only add features as I need them.
To be able to use above code snippet, you should download/clone my kicad-python 3 repository and add it to python path so that interpreter can import modules;
import sys
sys.path.append("/path/to/kicad-python/")
A tip; you can use function execfile() function to run python scripts from the python command line.
and the repo from this one is forked
2 Likes
I think @pointhi also has some plans for such an abstraction layer. (I seem to remember either something from the mailing list or from a discussion here.)
Not sure if these two are aware of each others efforts.
1 Like
1 Like
Perhaps no plans but it would be trivial since you are already using SWIG… Lua and javascript,and Rust are all closer to C/C++ than python and would probably not even require a secondary layer to beautify the API since they are designed to interoperate with C/C++. Just a thought.
Beauty or ugliness of the Python interface does not consitute a problem here. We need an abstraction layer to separate the scripting interface from C++ code. Such tight binding makes the scripting API unstable, as every time we modify the data structures or function signatures, they will change the Python API too, effectively breaking the existing scripts.
1 Like
One option could be to write a wrapper C++ API and autogenerate different language bindings from that.
The suggestion is to write an abstraction layer to insulate scripts from the C++ code. However, that just punts the stability problem to the data model. When the KiCad internal data model changes, that will affect the abstraction layer also. You will need to translate KiCad data model to an abstract data model for the script API. That is a lot of work to create and maintain, and will not solve the problem.
A stable script API depends on a stable KiCad data model, and since KiCad data model develops in a pretty ad hoc fashion, that also affects the script API. Until a time where the KiCad data model is stable, the script API will always be changing.
In the meantime, exposing the C++ functions directly is the least amount of work, even if it causes pain.
Also the last thing that is desirable is a whole bunch of different APIs and scripts written in different languages. That would create a horrible mess.
I don’t know if this is sensible for two reasons:
- Only a handful of action plugin developers are affected by the API changes
- Given the focus of development for V5.1 and V6, pcbnew API should not change much if it will change at all
I like the way you excluded the eeschema API to make your point work 
2 Likes
Python is the defacto scripting language for many application suites. It’s simply not sensible to attempt to cater to every pet programming language that people wish to use - it fragments resources and creates too many moving targets in an already complex application suite.
I’d prefer solid support of one language through all of KiCad (especially with a good interface to eeschema AND pcbnew) rather than dodgy support of a few languages scratching random itches. Python is a great way to do this (readibility, ease of use, existing libraries, etc) and I’m glad that the project is continuing in that direction.
1 Like
Does eschema have a python API? If it does then my statement is obviously wrong. But as far as I know there is no such API.
If there are several dozen script writers, then the abstraction layer would create a stable data model for them. Then any changes in the underlying KiCad data model would be hidden from them. If the KiCad data model changed, then whoever is in charge of the abstraction layer can fix the incompatibilities for every script in one place without having to know how each individual script works.
The alternative is to make the script writers responsible, and in a lot of cases they’re not maintaining their scripts even if others have come to depend on them. That makes scripting less valuable for the KiCad community because they’ll never know if a given script will run or not. And scripts should be a valuable feature for the community because they bring new features without the delays and complexity of modifying the KiCad core. (Certainly Eagle has benefited from a large collection of scripts; they just chose to implement them with an ad-hoc, closed language which caused its own set of problems.)
5 Likes
Or the python api has testcases that check that nothing did break and every change to the underlying model must go through these checks. (Only changes that do not break the testcases are allowed in. Means everyone contributing to kicad is then responsible for keeping the api alive.)
I would also like to see something similar to file format related things. (right now different versions of kicad write files slightly differently. Some put in additional whitespace chars, some order lines differently, …) This just makes live hard for everyone who uses version control. (I think i already proposed this but i don’t think the devs take it very seriously. So i resort to simply bugging them with every change they make.)
4 Likes
I would also suggest that a reasonable set of libraries be supported as well… if scripts pull in external libraries you can be sure they will break sooner or later.
It would be nice if scripts like KiCost just worked out of the box in the KiCad maintained python enviornment…
I don’t know if that’s ever going to be practical. Something like KiCost uses libraries for things like web scraping and spreadsheet manipulation libraries. KiCad can’t drag the entire Python ecosystem around with it.
What would be nice would be to substitute an external Python interpreter and set of libraries for the internal ones used by KiCad. Then you could load the libraries you want. Maybe that’s possible now, I don’t know. If not, I don’t know all the changes that would be necessary to make it happen.
2 Likes
I think Scheme would be better than lisp in general. Mostly they’re compatible, it’s just scheme doesn’t have cons so doesn’t need to implement cons cells and so can have more efficient internal representation than lisp. Lists for example can be represented as arrays with no need for cdr’s.
Scheme (and lisp) has some big advantages over python. The most obvious is the ability to programmatically construct code, such as data filters or sort ordering functions based on complex criteria. For example, for footprint or component library searches (# of pins, substring, specific library or substring, patterns, etc) - where instead of a monolithic comparison function that takea a gazillion parameters, a function is created that constructs a comparison function based on search criteria, and then this is used by a generic search. It’s also easier to verify since the filter or comparison constructor function can be tested in isolation - feed it inputs and see what code it outputs, without actually have to unit test against a giant test data set.
Of course, the ecosystem is much better for python and there are libraries for virtually any task.
You are probably right, it would be nice if there could be a maintained set of libraries that large that just worked and allowed use to just run tools like KiCost but that’s a huge maintenance burden. Honestly I think python is overkill for what it sounds like people are wanting to do with it.
Scheme/Lisp is a bit too esoteric for most… I’ve never written too much serious in it other than a sudoku solver.
Lua really is the go to language for simple scripting though, thats why it was developed to being with… and there is an updated wxLua bindings library to go along with it. https://github.com/pkulchenko/wxlua
And since Lua is designed to interface with C/C++ you don’t end up with the whole problem of having a secondary wrapper for the swig based API…