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 666636 - Support marshalling list of strings into a GValue
Support marshalling list of strings into a GValue
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
Git master
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on: 688081
Blocks:
 
 
Reported: 2011-12-21 07:56 UTC by Mardy
Modified: 2013-07-26 01:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tests: Change GHashTable<string,GValue> marshaling test to use GValue (1.65 KB, patch)
2013-07-25 02:43 UTC, Simon Feltman
committed Details | Review
tests: Change GHashTable<string,GValue> marshaling test to use GValue (2.16 KB, patch)
2013-07-26 01:16 UTC, Simon Feltman
committed Details | Review

Description Mardy 2011-12-21 07:56:09 UTC
I've got one C method which takes a GHashTable<string,GValue>.
When I invoke this method from python,

======
  strings = ['one', two', three']
  data = {}
  data['plain_string'] = 'hi, this works'
  data['strings' = strings
======

the 'plain_string' is correctly converted into a GValue holding a UTF-8 string, but the 'strings' parameter holds a PyObject, and not a GStrv as I would expect (or maybe a GValueArray, if the list element are of different types).
Comment 1 Mardy 2012-01-13 17:10:34 UTC
I think a found a solution:

===========
class GStrv(list):
    __gtype__ = GObject.type_from_name('GStrv')

strings = ['one', two', three']
data = {}
data['plain_string'] = 'hi, this works'
data['strings'] = GStrv(strings)
===========

So, as far as I'm concerned, this bug can be closed. :-)

I'll leave it the decision to the python-gobject folks, because maybe they'd like to have this case working without this "hack".
Comment 2 Martin Pitt 2012-04-24 11:06:10 UTC
I applied that workaround in the tests for now, so that we can actually run this test case:

http://git.gnome.org/browse/pygobject/commit/?id=88d189ec3e3d900a96496a50c1d6e76615b19558

I need the test case for bug 637466, and it's good to have it anyway.

Thanks for the workaround!
Comment 3 Simon Feltman 2013-07-25 02:33:50 UTC
There is really no good way we can fix this in terms of being able to pass a list of strings directly. Basically we do not have a GI annotation describing the expected marshaling to a GStrv (only the actual code within the C function being called knows what is expected). We could attempt a deeper analysis of the Python data and use a heuristic when converting to a GValue (Python list of strings is always a boxed GStrv). But I think the right way to deal with this is for clients of the API to explicitly create the GValue which the API is expecting:

strings = ['first', 'second', 'third']
data['strings'] = GObject.Value(GObject.TYPE_STRV, strings)

This creates a properly marshaled and boxed Strv from Python strings which show up on the C end correctly. However, this depends on bug #688081 to be fixed (not the deprecation but the overrides for GValue.set/get_boxed).
Comment 4 Simon Feltman 2013-07-25 02:34:47 UTC
Depends on GValue.set/get_boxed override patch in bug #688081, not the deprecations.
Comment 5 Simon Feltman 2013-07-25 02:43:00 UTC
Created attachment 250087 [details] [review]
tests: Change GHashTable<string,GValue> marshaling test to use GValue

Patch for the tests.

For the record, I am not against adding GStrv to the GLib overrides (GLib.Strv) as a slightly cleaner workaround. In which case we should add tests for both cases.
Comment 6 Martin Pitt 2013-07-25 13:30:47 UTC
Comment on attachment 250087 [details] [review]
tests: Change GHashTable<string,GValue> marshaling test to use GValue

This looks slightly less hard to discover :-) and is shorter, thanks!
Comment 7 Simon Feltman 2013-07-26 01:16:44 UTC
I ended up adding the GObject.Value technique as an additional test rather
than replacing the list sub-class (GStrv(list)). I think the sub-class
is still useful and keeping the test will help us avoid regressions.

The following fix has been pushed:
f86701b tests: Change GHashTable<string,GValue> marshaling test to use GValue
Comment 8 Simon Feltman 2013-07-26 01:16:49 UTC
Created attachment 250166 [details] [review]
tests: Change GHashTable<string,GValue> marshaling test to use GValue

Add test to explicitly use a boxed GStrv GValue in addition to a
Python list sub-class.