After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656872 - gio load_contents_finished return values changed
gio load_contents_finished return values changed
Status: RESOLVED DUPLICATE of bug 620912
Product: pygobject
Classification: Bindings
Component: gio
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-19 09:08 UTC by Michael Vogt
Modified: 2012-04-20 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Vogt 2011-08-19 09:08:43 UTC
The old static bindings for gio.File.load_contents_finish() returned:

gio.File.load_contents_finish

    def load_contents_finish(result)

result :
	a gio.AsyncResult.

Returns :
	a three tuple containing the contents of the file, the length of the contents of the file and the current entity tag for the file. 



With the new bindings it:
(success, content, etag(?)) - it would be nice to consider consistency with the old bindings.
Comment 1 Martin Pitt 2011-08-19 09:18:42 UTC
I assume "new bindings" are with PyGI?

gboolean g_file_load_contents_finish (GFile *file,
                                      GAsyncResult *res,
                                      char **contents,
                                      gsize *length,
                                      char **etag_out,
                                      GError **error);

This is supposed to return (return-bool, contents, etag), as the annotation already maps the "length" out argument to the length of contents; in language bindings the length field is rather uninteresting?

I think the questionable bit here is not the length out value, but the "success" flag. We had some similar cases where out values were undefined and using them caused crashes when the functions returned FALSE, e. g. in

  Gdk.color_parse(): http://git.gnome.org/browse/pygobject/commit/?id=5b1c875
  Gtk.TextIter: http://git.gnome.org/browse/pygobject/commit/?id=fc5c869486c7f

In these cases we added an override to only return the out values on success==True, otherwise return None. Do we need this here as well, i. e. are the returned values undefined when the function returns False?
Comment 2 Martin Pitt 2012-04-20 13:09:00 UTC

*** This bug has been marked as a duplicate of bug 620912 ***