J5 has had the great idea of proposing a GNOME Foundation-sponsored hackfest to bring needed pushes to Python 3 and GObject Introspection support to PyGObject.
The situation in which we are today is not very comfortable, as more and more people are wanting to move their projects to Python 3.x and the old static bindings are not being able to cope with new API added to existing libraries and with new GObject-based libraries. A lot of people out there are known to be using PyGTK in long-term projects, so we really need to get our act together.
AFAICS, the plan on the table right now is to make PyGObject and PyGI run on Python 3.x and drop the static bindings, instead of having to port all of them to Python 3.x. Another possibility is to drop PyGObject altogether and have standalone python bindings for GObject Introspection, but that would reimplement lots of stuff already in PyGObject.
Have started a thread in the PyGTK mailing list: http://www.daa.com.au/pipermail/pygtk/2010-February/018222.html
Please pass this idea to whoever you think could be interested, more details will come soon.
UPDATE: have started a proposal in the GNOME wiki: http://live.gnome.org/Hackfests/Python2010. Once we have a better idea of who is interested in attending, I will complete it further.
How will this afford any better API than what can already be attained using ctypes?
ReplyDelete> How will this afford any better API than what can already be attained using ctypes?
ReplyDeleteBy default, you will get whatever can be inferred from the C API, which is quite similar to the API that provided the ctypes bindings.
For further pythonization and compatibility with existing code, PyGI provides a way to override the introspected API with python code.
ctypes is also significantly slower than direct bindings IIRC.
ReplyDelete> By default, you will get whatever can be inferred from the C API, which is quite similar to the API that provided the ctypes bindings.
ReplyDeleteSorry, meant generated Python/C code instead of ctypes there.
PyGI will provide by default a much more pythonic API than ctypes could give.
Through the overrides mechanism we'll be able to implement the API that generated bindings added, mainly for compatibility.
> ctypes is also significantly slower than direct bindings IIRC.
ReplyDeleteSee my clarification, no ctypes will be involved AFAICS.