Thoughts on a possible move towards Python?

[chrisdebian]

Hello Stephane (and Nirgal, if you're able to weigh in),

I've been having a good read through grig and really enjoying the project — it's a clean, sensible take on rig control.

I noticed a note in AUTHORS for the 0.8.0 release, mentioning that it "may be one of the last versions before architectural changes, and an eventual rewrite into Python." I wanted to open a friendly discussion about that, well before any code gets written, partly because it's a big decision and partly in the spirit of #13, where you asked contributors to flag intentions early.

A few questions, if you have the time:

• Is the Python note in AUTHORS still something you'd like to see happen, or was it more of a passing thought at the time?
• Given Migration from GTK 2.x to GTK 3 #13 (GTK2 to GTK3) doesn't seem to have been picked up yet, would a smaller step like that be more useful first, rather than jumping straight to a language change?
• If Python is still of interest, Hamlib already has SWIG-generated Python bindings, and PyGObject would cover the GTK side, so the technical path looks reasonably smooth. That said, I know that's a separate question from whether it's the right time or priority for the project.
• Is this something you'd want to drive yourself, or would you be open to someone else picking it up under your guidance?

I'm conscious this touches on real maintainer time, so no pressure at all if now isn't the right moment — happy to help in whatever way is most useful, even if that's just keeping the discussion going for now.

Thanks for all the work on grig.

73,
Chris (2E0FRU)

[markjfine]

Frankly, having worked in Python (updated fork of nrsc5-gui), I find it very high maintenance. To me, Python's entered the Java stage where everything gets deprecated in a month (if that much) and it can't handle package changes very smoothly. Finding this a real problem between Python 3.13 and 3.14 and some packages yet to have been updated properly in the latter, such as cffi, cryptology, for example.

A major issue: PyGObject is ok in Linux and macOS, but Windows was a real problem with 3.14, as it failed to even build properly for me. Also, anything requiring POSIX on Windows is a problem. So trying to be truly cross-platform could be an issue, however cross-compiling using mingw of GTK things work just fine.

Bottom line: The bridge(s) to GTK4 from GTK2 (even from GTK 1.2) are hard, but after that it's a whole lot less work for quite a while.

Just my 0.02...

[chrisdebian]

Thanks for the detailed real-world experience — that's exactly the kind of input this issue was fishing for.

The Windows/PyGObject friction and the Python 3.13→3.14 package churn are both concrete costs, and they land against the AUTHORS note's original idea, not for it. Sounds like the more sensible path is what #13 already proposes: migrate the existing GTK2 code to GTK3/4 directly, rather than a language rewrite on top of a toolkit migration.

I'll leave the "is the Python note still current intent" question open for Stephane, since that's ultimately his call — but for my own part, this has shifted my thinking towards #13's approach being the better one to pursue, whenever there's appetite for it.

Thanks again for weighing in.

73,
Chris (2E0FRU)