Okay, I can’t believe I have to do this again.
This time, let’s leave the Hellsite out of it, and let’s try to be nuanced from the start. I’d like to avoid getting grief online.
The current state of the Python bindings for GObject-based libraries is making it really hard to recommend using Python as a language for developing GTK and GNOME applications.
PyGObject is currently undermaintained, even after the heroic efforts of Christoph Reiter to keep the fires burning through the long night. The Python community needs more people to work on the bindings, if we want Python to be a first class citizen of the ecosystem.
There’s a lot to do, and not nearly enough people left to do it.
Case study: typed instances
Yes, thou shall use GObject should be the law of the land; but there are legitimate reasons to use typed instances, and GTK 4 has a few of them:
At this very moment, it is impossible to use the types above from Python.
PyGObject will literally error out if you try to do so. There are technical
reasons why that was a reasonable choice 15+ years ago, but most language
bindings written since then can handle typed instances just fine. In fact,
PyGObject does handle them, since
GParamSpec is a
GTypeInstance; of course, that’s because PyGObject has some ad hoc code
Dealing with events and render nodes is not so important in GTK4; but not having access to the expressions API makes writing list widgets incredibly more complicated, requiring to set up everything through UI definition files and never modifying the objects programmatically.
Case study: constructing and disposing
While most of the API in PyGObject is built through introspection, the base
wrapper for the GObject class is still very much written in CPython. This
requires, among other things, wiring the class’s virtual functions manually,
and figuring out the interactions between Python, GObject, and the type
system wrappers. This means Python types that inherit from GObject don’t
have automatic access to the
GObjectClass.dispose virtual functions. Normally, this would not be an
issue, but modern GObject-based libraries have started to depend on being
able to control construction and destruction sequences.
For instance, it is necessary for any type that inherits from
ensure that all its child widgets are disposed manually. While that was
possible through the “destroy” signal in GTK3, in GTK4 the signal was
removed and everything should go through the
function. Since PyGObject does not allow overriding or implementing that
virtual function, your Python class cannot inherit from
must inherit from ancillary classes like
AdwBin. That’s even
more relevant for the disposal of resources created through the composite
Gtk.Template would take care of this, but since we
cannot plug the Python code into the underlying CPython, we’re stuck.
Case study: documentation, examples, and tutorials
While I have been trying to write Python examples for the GNOME developers documentation, I cannot write everything by myself. Plus, I can’t convince Google to only link to what I write. The result is that searching for “Python” and “GNOME” or “GTK” will inevitably lead people to the GTK3 tutorials and references.
The fragmentation of the documentation is also an issue. The PyGObject website is off to readthedocs.org, which is understandable for a Python projects; then we have the GTK3 tutorial, which hasn’t been updated in a while, and for which there are no plans to have a GTK 4 version.
It would be great to unify the reference sites, and possibly have them under the GNOME infrastructure; but at this point, I’d settle for having a single place to find everything, like GJS did.
What can you do?
Pick up PyGObject. Learn how it works, and how the GObject and CPython API interact.
Write Python overrides to ensure that API like GTK and GIO are nice to use with idiomatic Python.
Write tests for PyGObject.
Port existing tutorials, examples, and demos to GTK4.
Help Christoph out when it comes to triaging issues, and reviewing merge requests.
Ask questions and provide answers on Discourse.
What happens if nobody does anything?
Right now, we’re in maintenance mode. Things work because of inertia, and because nobody is really pushing the bindings outside of their existing functionality.
Let’s be positive, for a change, and assume that people will show up. They did for Vala when I ranted about it five years ago after a particularly frustrating week dealing with constant build failures in GNOME, so maybe the magic will happen again.
If people do not show up, though, what will likely happen is that Python will just fall on the wayside inside GNOME. Python developers won’t use GTK to write GUI applications; existing Python applications targeting GNOME will either wither and die, or get ported to other languages. The Python bindings themselves may stop working with newer versions of Python, which will inevitably lead downstream distributors to jettison the bindings themselves.
We have been through this dance with the C# bindings and Mono, and the GNOME and Mono communities are all the poorer for it, so I’d like to avoid losing another community of talented developers. History does not need to repeat itself.
python development languages gnome