GNOME Bugzilla – Bug 695089
Cannot override certain functions in GstBase
Last modified: 2018-11-03 15:36:31 UTC
Here is smallest code that reproduces the issue. Similar code did not cause issues in 0.10. >>> import gi >>> gi.require_version('Gst', '1.0') >>> from gi.repository import GstBase >>> class E(GstBase.BaseSink): ... def do_query(self,query): ... pass ... /usr/lib64/python2.7/site-packages/gi/_gobject/__init__.py:119: Warning: g_param_spec_boxed: assertion `G_TYPE_IS_BOXED (boxed_type)' failed type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gi/_gobject/__init__.py:119: Warning: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed type_register(cls, namespace.get('__gtype_name__')) Traceback (most recent call last):
+ Trace 231587
cls._setup_vfuncs()
ambiguous_base.__info__.get_name()))
Isn't this a bug somewhere else really (e.g. pygobject)?
I have no idea, sorry. I was instructed on #gstreamer@freenode.net to report it under gst-python. If you think there is more suitable place for it, then please assign it there so the right developers will be aware of it. Another reason I thought it should be here is that (to best of my knowledge) everything in GObject uses inheritance extensively, so it would be rather strange that such bug would be there for long without noticing.
The bug is that both classes GstBaseSink and GstElement have a virtual method with the exact same name (->query). The introspection can't really know which one we want to override when we set the do_query vmethod. We might do some trick in the override so that we have do_base_sink_query and do_query or something like that?
This is also a problem with the `fill` vfuncs on GstBaseSrc[0] and GstPushSrc[1] as seen on [2]. [0]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSrc.html [1]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstPushSrc.html [2]: https://stackoverflow.com/questions/45497507/using-pygi-how-can-i-override-a-virtual-method-from-a-gobject-class-that-has-th
I see two possible solutions: * Figure out a way in gst-python, not sure how bet I bet we can hack something around the issue * Add new vmethod on the basclass to differentiate the names, and deprecate the old ones (or not).
I'm trying to understand: the method _setup_vfuncs in MetaClassHelper class in types.py file first get the base classes in order using __mro__ and take just the first class that has a virtual method with the name of the overwriting method. After that, it checks if there are virtual methods with the same name more deeply in another base class, and if found, just give up. But when a class inherits another one, the methods of the base class with the same name as the methods of the derived class are overwritten. Hence, why check for this ambiguity, or better, it is really a ambiguity? More cleary, is really necessary run find_vfunc_conflict_in_bases (line 108 at types.py)? Btw, I removed this check as workaround and worked (at least in my case).
In the GObject case it is and ambiguity as if you have BClass subclass of AClass and both define AClass.some_vmethod and BClass.some_vmethod, those are different vmethods (different offset in the class structures etc) and calling ((AClass*) class_struct)->some_vmethod is different than calling (on the same structure) ((BClass*) class_struct)->some_vmethod. In the case of GstBaseSink::query, PyGobject can't know what a `do_query` wants to override, GstBaseSink::query vmethod or GstElement::query, and overriding one or another would lead to different behaviour.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-python/issues/1.