GNOME Bugzilla – Bug 709008
Fully expose GI API to Python
Last modified: 2013-10-07 22:51:46 UTC
There are a few methods which are missing in the static bindings for GI (pygi-info and pygi-repository). This ticket is for an audit of that code to flush out a fully exposed the GI API. Beyond fixing the need for occasional one off additions, having this API is important when doing analysis and potentially more.
Created attachment 256523 [details] [review] Move info tuple retrieval into generic function Create new generic function for retrieving a tuple of child infos. This greatly simplifies all the bindings which return tuples from a common pattern of functions on GIBaseInfo based instances.
Created attachment 256524 [details] [review] Move child info retrieval into generic function Add a generic function for bindings which return a single child info. This trivializes binding methods like PyGIObjectInfo.get_parent and fixes leaks in PyGIObjectInfo.get_class_struct and PyGIVFuncInfo.get_invoker.
Created attachment 256525 [details] [review] Move info string retrieval into generic function Add get_info_string for sharing binding of simple string retrieval on GIBaseInfo objects.
Created attachment 256526 [details] [review] Add GIBaseInfo.equal method Break PyGIBaseInfo rich compare into two methods: equal and richcompare. Equal is a direct exposure of the GI method and richcompare makes use of this with additional support for Pyton "==" and "!=" operators.
Created attachment 256527 [details] [review] Avoid calling g_base_info_get_name on GI_INFO_TYPE_TYPE Calling g_base_info_get_name on infos tagged with GI_INFO_TYPE_TYPE will cause a crash. Avoid this by adding _safe_base_info_get_name and using that throughout the bindings. Logged GI bug as: https://bugzilla.gnome.org/show_bug.cgi?id=709456
Created attachment 256528 [details] [review] Expose all GI enum and flags types Add new types for GIDirection, GITransfer, GIArrayType, GIScopeType, GIVFuncInfoFlags, GIFieldInfoFlags, GIFuncitonInfoFlags, GITypeTag, and GInfoType. These types are found in the gi._gi module exposed without the "GI" prefix and contain all of their values as class attributes. e.g. gi._gi.Transfer.EVERYTHING.
Created attachment 256529 [details] [review] Add missing methods on PyGIBaseInfo and sub-classes Expose all methods of GIBaseBase info and its sub-classes.
Review of attachment 256523 [details] [review]: Wow, nice cleanup!
Comment on attachment 256527 [details] [review] Avoid calling g_base_info_get_name on GI_INFO_TYPE_TYPE It would be nice to revert that once we start depending on a (future) g-i version which has this fixed, to avoid the extra function call. Do you know a standard way to do that? Could we perhaps add some #error "re-check if this bug got fixed" when building with g-i >= 1.40 or so?
Comment on attachment 256528 [details] [review] Expose all GI enum and flags types I'm a bit torn on the last two patches. They will make it much easier to debug introspection issues right in Python, but expose a lot of API of g-i which might change, is probably not ever used in production, and makes imports a bit slower? No veto from me though, so please go ahead. Thank you!
Attachment 256523 [details] pushed as cdd03a2 - Move info tuple retrieval into generic function Attachment 256524 [details] pushed as d2aef36 - Move child info retrieval into generic function Attachment 256525 [details] pushed as e7b758b - Move info string retrieval into generic function Attachment 256526 [details] pushed as c86b2fe - Add GIBaseInfo.equal method Attachment 256527 [details] pushed as 0120af6 - Avoid calling g_base_info_get_name on GI_INFO_TYPE_TYPE Attachment 256528 [details] pushed as e190eb7 - Expose all GI enum and flags types Attachment 256529 [details] pushed as a76b061 - Add missing methods on PyGIBaseInfo and sub-classes
Thanks for the reviews! (In reply to comment #9) > It would be nice to revert that once we start depending on a (future) g-i > version which has this fixed, to avoid the extra function call. Do you know a > standard way to do that? Could we perhaps add some #error "re-check if this bug > got fixed" when building with g-i >= 1.40 or so? This would be nice but I don't know of a way to do it. In general we should probably run an occasional grep on our tree for "bugzilla" and audit those lines. Granted we always give the bug url as comments for things we workaround or perhaps we could introduce a new "tag" like WORKAROUND: ... (In reply to comment #10) > (From update of attachment 256528 [details] [review]) > I'm a bit torn on the last two patches. They will make it much easier to debug > introspection issues right in Python, but expose a lot of API of g-i which > might change, is probably not ever used in production, and makes imports a bit > slower? In terms of performance, I don't see anything above "0m0.000s" with or without the new bindings with a simple script containing only "import gi". But things are probably cached and I have a beefy machine. Also keep in mind these APIs have been left somewhat "private" in the sense that a lot of it is only accessible on gi._gi (we only put needed stuff on "gi") and under classes like Gtk.Widget.__info__. However, method objects will expose CallableInfo items directly (Gtk.Widget.pressed.get_arguments()). But this has been the case since we did the load time optimizations. Beyond the benefits of debugging and better function docs, this will greatly help with analysis and experimentation. For instance, I've been playing with a static binding generator using these bindings which can regenerate these same bindings (I really hope it could be used for cairo as well). Similarly we can use this for jit binding generation managed in pure python (ala llvmpy or David Malcoms new jit work with gcc: libgccjit.so and pygccjit (https://github.com/davidmalcolm/pygccjit).