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 759646 - Impossible to work with vala APIs
Impossible to work with vala APIs
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-18 19:06 UTC by Xavier Claessens
Modified: 2018-01-10 20:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add GObject.__wrap__() class method (3.15 KB, patch)
2015-12-18 19:06 UTC, Xavier Claessens
reviewed Details | Review

Description Xavier Claessens 2015-12-18 19:06:28 UTC
Vala APIs usually won't use GList/GHashTable but libgee types. See for example this gir from folks:

<method name="list_backends" c:identifier="folks_backend_store_list_backends">
	<return-value transfer-ownership="full">
		<type name="Gee.Collection" c:type="GeeCollection*">
			<type name="Folks.Backend" c:type="FolksBackend*"/>
		</type>
	</return-value>
</method>

In theory pygobject has the needed info to convert this into a proper python list, but that means it must know about libgee API. As workaround, pygobject could let user create their PyObject wrapper when they know the expected type. The above API would then be used in python like this:

l = []
collection = store.list_backends()
i = collection.iteractor()
while i.next():
  l.append(Folks.Backend.__wrap__(i.get(), True))
Comment 1 Xavier Claessens 2015-12-18 19:06:57 UTC
Created attachment 317641 [details] [review]
Add GObject.__wrap__() class method

This helps working with badly introspected APIs that returns gpointers.
In that case, if user knows it is a GObject they can create a wrapper
manually.
Comment 2 Simon Feltman 2016-03-03 08:18:53 UTC
Review of attachment 317641 [details] [review]:

While I think the conversion of pointers to int's was probably a mistake, it would be an API break. Although we may be able to get away with it if it is only limited to function returns/output args or callback input args.

::: gi/pygobject.c
@@ +1995,3 @@
+    GObject *obj;
+
+    if (!PyArg_ParseTuple(args, "OO:GObject.__wrap__", &capsule, &steal))

Use PyArg_ParseTupleAndKeywords() so the steal parameter can be explicitly named for readability. Even better would be to have two methods, one for wrapping with stealing the pointer and one which also adds a ref (think g_value_set_boxed() and g_value_take_boxed()).

@@ +2144,3 @@
     { "__copy__", (PyCFunction)pygobject_copy, METH_NOARGS },
     { "__deepcopy__", (PyCFunction)pygobject_deepcopy, METH_VARARGS },
+    { "__wrap__", (PyCFunction)pygobject_wrap, METH_CLASS|METH_VARARGS },

I would name this something like "_from_pointer_" to avoid conflicting with builtin "dunder" names, see bug 732403.
Comment 3 GNOME Infrastructure Team 2018-01-10 20:52:18 UTC
-- 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/pygobject/issues/107.