[gstreamer-bugs] [Bug 393458] pygobject.gobject_set_property does not handle enum values (well)

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=393458

  GStreamer | gst-python | Ver: 0.10.6





------- Comment #5 from Mark Nauwelaerts  2007-01-07 14:29 UTC -------
Indeed, I would not at all expect passing "4" to an enum property to perform
automagical conversion, but I would expect it to 'work' when passing to a
property of type int, long, etc, as I see no possibility for
ambiguity/collision in that case (though I agree the 'work' part should not be
on the pygobject level, i.e. it need not do this automagical stuff).

As such, more precisely, that's why the patched helper function does not
interfere when setting an enum property and just passes this straight to
some_object.set_property.  However, the helper function could/should still give
a hand in case of (u)int/u(long)/double etc properties, by performing (I
believe) the only possible meaningful conversion, e.g. int("4") (since
pygobject did not and need not begin doing this conversion).  And for a boolean
property, it could 'convert' things like "false", "off" or so (taste may vary)
to False, and others to bool(value), which again seems a reasonable,
unambigious thing to do (which again pygobject did not and need not begin
doing).

So, in the present (and presumably ok) state of bindings, it seems the "helper
function" likely still has some (additional) convenience to offer for some
property-types, when brought up to the proper (patched) form at least.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email