GNOME Bugzilla – Bug 654859
Can't construct GVariant from format string in Python
Last modified: 2012-04-23 17:03:38 UTC
It seems that commit e61fa51 (bug #646635) adds annotation that skips g_variant_new. Not sure why. We depend on constructing GVariants from format strings in Caribou (bug #654852). This may be intentional. If it is, what is the alternative API for this functionality?
Add relevant people to CC
g_variant_new uses varargs, so it cannot be accessed from python (or any dynamic introspected language). GLib.Variant constructor in Python is an override, so I think the bug is in pygobject.
danw@desktop:pygobject (pygobject-2-28)> cat /tmp/foo.py from gi.repository import GLib GLib.Variant('b', False) danw@desktop:pygobject (pygobject-2-28)> jhbuild run python /tmp/foo.py Traceback (most recent call last):
+ Trace 227904
GLib.Variant('b', False)
(v, rest_format, _) = creator._create(format_string, [value])
v = constructor(args[0])
return info.invoke(cls, *args)
(In reply to comment #3) > danw@desktop:pygobject (pygobject-2-28)> cat /tmp/foo.py > from gi.repository import GLib > > GLib.Variant('b', False) > > danw@desktop:pygobject (pygobject-2-28)> jhbuild run python /tmp/foo.py > Traceback (most recent call last): > You are using to new a version of GLib and GLib Introspection. This was fixed in master and I am in the process of making master parallel installable with pygobject-2.28 (with introspection turned off). What is in master will be what ships with Gnome-3.2
I was a bit unclear with my above comment. What happened was GLib Introspection decided to mark Variants as fundamental types instead of foreign types which means when using a newer typelib generated by GObject Introspection, pygobject-2.28 fails to convert the Variant to the correct python wrapper because the foreign code path is not executed. We added explicit support for Variants in pygobject's master branch to fix this on our end. The support was not finished for 2.28 and for the most point unless it seems like we won't release in time for GNOME 3.2, I don't want to add the code to a stable branch.
should jhbuild be switched to master then? (It's currently building pygobject-2-28 for GNOME 3.2)
It needs to build both to support static bindings and for that to happen the parallel install stuff needs to be approved. Tomeu wants me to post to the relevant python mailing lists first since it complicates how we distribute. The other option would be to rename the module gi3 but that would be a pain for current Introspection apps.
(working around this in caribou for now by just not using gvariant)
Hmm; so what changed here is that g-i stopped exporting GVariant as foreign? Can't it be special cased in the pygobject-2-28 branch?
(In reply to comment #9) > Hmm; so what changed here is that g-i stopped exporting GVariant as foreign? > > Can't it be special cased in the pygobject-2-28 branch? We regenerated glib-2.0.c from glib sources (which never marked GVariant as (foreign)).
The overrides for GLib.Variant are covered by the tests, and work well. This does not affect pygobject 3.0 and 3.2, and we don't support GI in the old 2.28 branch (use the static bindings there), so I'm closing this. Thanks!