GNOME Bugzilla – Bug 692515
Differentiate Python created GType enum names to avoid registration problems
Last modified: 2013-01-31 01:53:12 UTC
Trying to use Gstreamer in the latest Ubuntu Raring results in a runtime error. How to reproduce: $ python3 >>> from gi.repository import Gst >>> Gst.init(None) [] >>> pipeline = Gst.Pipeline() >>> pipeline.set_state(Gst.State.PLAYING) This will result in: /usr/lib/python3/dist-packages/gi/module.py:153: Warning: cannot register existing type `GstState' Traceback (most recent call last):
+ Trace 231438
return getattr(self._introspection_module, name)
wrapper = enum_register_new_gtype_and_add(info)
The example above works in Quantal with python-gi 3.4.0-1ubuntu0.1 but in Raring, using 3.7.3-0ubuntu2 we get the RuntimeError above.
Looks like this is fallout from the fix for bug 690455. Details: Enums now are created with proper names in pygobject. This exposed another bug with how gi/module.py uses g_registered_type_info_get_g_type. Note the docs for this method specify a return of G_TYPE_NONE has a "special meaning": http://developer.gnome.org/gi/unstable/gi-GIRegisteredTypeInfo.html#g-registered-type-info-get-g-type Currently when TYPE_NONE is returned it is assumed the type is not registered and pygobject tries to create and register a new type. Instead pygobject should test if the type is already registered not only with gi but glib. I do not see a "g_type_is_registered" method, so we might have to do something a bit more hacky like catching an exception raised from g_type_from_name (GObject.type_from_name). See: http://git.gnome.org/browse/pygobject/tree/gi/module.py?id=3.7.4#n137
It turns out the root cause of this and bug 690455 seems to be that Gst.State does not supply a "get_type" method in the typelib. This compounded by pygobject trying to register new GTypes for enums and flags which don't supply this method does not help. We can add a quick fix to pygobject which obfuscates enum and flags types it creates and registers with GLib. But we really need to find out why gir creation is not supplying GstState with a "glib:get-type" property. For instance, with GstVideoFormat we see a fully filled out gir definition: <enumeration name="VideoFormat" glib:type-name="GstVideoFormat" glib:get-type="gst_video_format_get_type" c:type="GstVideoFormat"> GstState only shows the following annotation: <enumeration name="State" c:type="GstState"> In the eyes of pygobject (or any introspection based bindings) this is a "typeless" enum and so it tries to create a GType for it causing different problems depending on if Gst.init is called before or after accessing it.
Created attachment 234516 [details] [review] Obfuscate names of typeless enum and flags for GType registration Prefix names given to g_flags_register_static and g_enum_register_static with "Py". This avoids conflicts with GTypes of the same name being registered later by a library which does not provide a "get-type" annotation.
Dropping priority on this because the problem has been fixed by bug 691185. However, I still think the proposed patch should go in to further differentiate pygobject created enum GTypes from others because they are only temporarily used for the purpose of creating and filling out an enum.
Pushing as this is a simple fix that probably doesn't need review. The following fix has been pushed: 571e0cb Prefix names of typeless enums and flags for GType registration
Created attachment 234878 [details] [review] Prefix names of typeless enums and flags for GType registration Prefix names given to g_flags_register_static and g_enum_register_static with "Py". This avoids conflicts with GTypes of the same name being registered later by a library which does not provide a "get-type" annotation.