There has been discussion here and on the developer list about “standardizing” the Python API. Making it more stable through releases. I have been developing Python plugins (like KiCommand) since 2017, and have some ideas. Please consider this a community discussion on ways to stabilize the Python API.
The primary method put forward by developers is to code the API in the KiCAD source code in C.
I think the better way to involve more developers and decrease the burden on C core developers is to continue with the SWiG API for the core KiCAD classes and methods, and to add a Python sliver layer that implements a stable Python API. This could increase the developer contribution to those primarily contributing in Python (like myself).
I have spent many hundreds of hours converting the current SWiG API into a command-line suitable API and I think it has worked out fairly well. There have been many small changes to the current SWiG API as a result of source code change, but they have been relatively minor since early 4.0 releases and the changes required in Python have been easily fixable.
More important for developers, I think, is to keep pushing forward in making more capability available instead of trying to maintain backward compatibility.
My hope is that this frees up the KiCAD source code developers to add things like GUI control and access to eeschema, the footprint and symbol editors.
Core KiCAD developers, or suitable Python developers could then maintain the Python sliver (wrapper) for backward compatibility, and the Python API could then have incremental improvements and compatibility-breaking changes on a schedule that is different or slower than the SWiG API, which will change with the source code as needed.
I recommend you take this topic to the developer’s email list to make sure you are reaching all the devs, as not all of us are on this forum.
This is an interesting discussion to have. I personally think there is room for both (a more stable C++ API, and Python wrappers that provide extra convenience).
I agree there is room for both. However, one of my main observations is that, of the portion of the API that i’ve Used, the SWiG API has not been changing unreasonably. It is actually more of a burden that there is only one version of the Python API documentation available, and it isn’t clear to what KiCAD version it applies. Presumably it is either nightly or release, but I think it might be nightly as there are things that have appeared in the documentation that I don’t see in the current release (e.g. the version information) and things that are in the urgent release that I can’t find in the documentation (e.g. pcbnew.WindowZoom()). Not a complaint that must be addressed of course, just a (slight?) burden.
Edit: in any case, i’ve posted this on the developer list as well. Thanks for the suggestion!
One of the reasons for that is that we have been trying to avoid breaking it where possible, so deferring some changes that would break it until we can put a better alternative into place.
Very good point. So trying to keep the SWiG API stable has in fact been a burden on developers, preventing them (you?) from modifying code, possible for the sole reason to keep SWiG access stable. Maybe a Python wrapper could help with that so source code can change and the Python wrapper could maintain consistent API.
I find that going into scripting console and clicking on classes/methods gives same documentation as what doxygen provides, except you know for sure that it applies to the version you have open.
