kicad-developers team mailing list archive

[Greg Smith <ecomputerd@xxxxxxxxx>]

I started a discussion on the forums 
https://forum.kicad.info/t/python-api-development-discussion/
and it was suggested I post here.

There has been discussion here and on the forums 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 changes, 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 changes with the source code as needed.

Thoughts?


Greg S.