I have a simple script from a while ago, I now try to run in V5 rc. (from ~ March ?)
This is not a complex task - it generates a netlist, by part scan, then net-scan.
It seems to strangely cough on items that used to work in previous main release ?
footprint = part.GetFPID().GetFootprintName()
fails but this replacement seems ok footprint = part.GetFPID().GetLibItemName()
nNodes = Net.GetNodesCount()
fails and for pad in Net.Pads():
also fails.
Google finds some chatter maybe related to the last one here https://lists.launchpad.net/kicad-developers/msg31672.html
that seems to talk about a patch to enable net->pads access.
ie I think that is what has suffered a regression here
Is the python access being reduced over time (rather than expanded ?)
Any suggestions for fixes to the above ?
Basically, the Python support is a mess. Like other features, it was hacked in instead of being done properly with the hope it would be a āquick winā and get support by the rest of the devs. Well, other devs donāt like the SWIG method, which exposes C++ directly, and think there should be an abstraction layer to decouple C++ code and provide a stable Python API.
Now wxPython project is morphing to Phoenix, and apparently dropping SWIG for SIP, which means a lot of work just to keep the current Python interface working at all. Core KiCad developers seem to regard Python support as āa nice to haveā but not essential to making PCBs.
For detailed changes, you probably need to dig around in pcbnew.py and maybe the KiCad source code. There are very few people who understand the Python API in depth.
Thanks, I saw that and I see is it similar to the workaround I used, which was to add another for loop to manually sweep to count nodes. That seems to be slower, but maybe thatās all GetNodesCount did anywaysā¦ ?
Hmm, not sounding good for stable support is it ?
I was hoping database access was going to improve, not have things pruned / removed ?
Good script support is āup thereā rather above just ānice to haveā for serious PCB development use.
eg This script I am using to tighten up version control, to provide a check a PCB has not changed by accident, since a known-good version.
KiCad needs better ECO pathways, not worse ones.
I would say it is a known Issue. I talked with Wayne about Python Support on the FOSDEM a bit, with the idea of an abstraction layer. His point of view was that it should not interfere much with the KiCad core development, but then would be ok.
I started some proposal of such an API later on, based on existing approaches: https://github.com/pointhi/kicad-python which should be at least capable enough for basic scripts now. The main idea is to still have a SWIG/SIP export of KiCad internals, but scripts should target a higher-level abstraction layer which maintains a stable interface, documentation and fixes some bugs present in the low-level interface. To guarantee compatibility it would be important to create a test-coverage of about 100% of the interface in the future and add it to the official ci-system.
I think that while Kicad is ānice to haveā, as compared to other PCB CAD software, what really makes it outperform the others is the scripting facility. Just now, I have scripts for two things:
re-generating gerbers for say, only the three PCBs changed (out of twenty or so in the project). It automatically checks the change dates of the PCBs and regenerates and zips the gerbers and drill files for the whole project. Without any manual opening of CAD files, and clicking to re-generate the gerbers. Plus, I am dead certain the gerber settings are always the same, as they are explicitly set by the script
semi-automated panelizing the final set of boards, including v-cut scores (adhering to gerber X2) and milled borders between the boards. I only need to position the included boards and the script does the rest.
Iād hate to see this go, the scripting interface saves me hundreds of man-hours.
It has been some work (including guesswork) to make this work with nightly builds going towards v5, but IMO it has been worth it.
I would be all for your suggestion. Iād even help with the coding, but as things look right now I donāt seem to have the time. Moral support will have to do for now.