GNOME Bugzilla – Bug 669016
Request for new annotation: “return value is just a success/failure indicator, hide it”
Last modified: 2018-02-08 12:13:39 UTC
We have a lot of APIs in GStreamer which in C returns a tuple of a boolean True/False value depending on if the call was successful and then the object in question. When accessing these API calls from languages like Python it would be nice to not get the boolean returned, if its true, and if it returns FAlse then have an exception be thrown. The current behaviour looks really ugly as seen by this example code, where you have to access your object from python with a [X] value: videostruct=Gst.Structure.from_string("video/x-raw") remuxcaps.append_structure(videostruct[0])
> The current behaviour looks really ugly as seen by this example code, where you > have to access your object from python with a [X] value: > > videostruct=Gst.Structure.from_string("video/x-raw") > remuxcaps.append_structure(videostruct[0]) This example is a bit misleading. For one, because there's no gboolean involved here, but also, because the C API is really quite ugly and should probably be changed. Here's a better example of the type of function: gboolean gst_structure_get_int (GstStructure * s, const gchar * field_name, int * value); The field may or may not exist, in which case you get a TRUE/FALSE return and the out variable will have been set or not. It is perfectly valid for this field not to exist. One could add a GError * for this, but that doesn't seem particularly desirable (and is unlikely to happen in any case). Now in pygi you have to write something like: ret, val = structure.get_int ("width") or ret, num, denom = structure.get_fraction ("pixel-aspect-ratio") whereas it would be nice if one could add an annotation that says 'throw some generic exception if ret is FALSE' or 'the out value will only be set in case this function returns TRUE'. Other examples: - g_file_get_contents() - g_module_symbol() I'm sure there are more in other libraries, these are just off the top of my head.
You can mark the return value (skip), which I think should work. (It was only intended for functions that throw GErrors, so maybe it won't work for others... but we could probably change/clarify that rule if so.) > Other examples: > > - g_file_get_contents() > - g_module_symbol() When "Returns: (skip):" was added, we intentionally didn't apply it to any already-existing APIs, since that would force an API break on existing bindings.
Tried adding this annotation to the .get_int call and it works in the sense that I now only get the wanted value back; not sure getting '0' back on a random value is what we want though? caps=Gst.Caps.from_string("video/x-raw, height=90, width=90") In [17]: print caps <GstCaps at 0x99fc740> In [18]: struct=caps.get_structure(0) In [19]: struct.get_int("height") Out[19]: 90 In [20]: In [20]: struct.get_int("xyz") Out[20]: 0
Christian: GStreamer probably needs a separate api for language bindings which uses GError so that exceptions can be raised. Probably too late for the 1.0 cycle to add that though.
> Christian: GStreamer probably needs a separate api for language bindings which > uses GError so that exceptions can be raised. Probably too late for the 1.0 > cycle to add that though. This annotation is being requested because most GStreamer developers think this is not the way to go, and it seems a valid request in general. We did not change the C API on purpose and see little point of supplementing it with API that has an additional mostly useless/redundant GError argument.
I think this is a good a idea, something like this needs to be done: a) Add an annotation, or reuse existing annotations to skip/ignore a return value b) Save that information in the gir c) Save it to the typelib and add a girepository API d) tests for all of the above e) update the language bindings to use the new girepository api. Personally I'm a bit overburdened to this in a reasonable timeframe, but I'll have time to do code reviewing.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
*** Bug 708301 has been marked as a duplicate of this bug. ***
*** Bug 626721 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/gobject-introspection/issues/63.