GNOME Bugzilla – Bug 393458
pygobject.gobject_set_property does not handle enum values (well)
Last modified: 2011-08-11 12:46:18 UTC
The helper function above is a convenient wrapper for set_property, but forces or expects values for an enum parameter to be int, whereas set_property does not (e.g. can handle (nick)names). Also, an unknown exception type seems to be used in this helper function.
Created attachment 79516 [details] [review] Possible patch * do not force or expect values of enum property to be int * do not prevent set_property from getting a chance (by raising exception in advance) * do not use unknown exception type * a few additional checks and cases for convenience
I'm not exactly sure what this helper function is needed for. I assume it stems from a time when the gtk/gobject bindings were of inferior quality such that values needed to be fixed before passing. In what case do you rely on this function? Or rather, where does some_object.props.some_property = some_value fail (or the old some_object.set_property ("some-property", some_value)?
On the one hand, it seems e.g. that both some_object.props.some_property = some_value and the old some_object.set_property ("some-property", some_value) fail when passing e.g. '4' (as a string) to an int-property. That is, a TypeError is raised, rather than the expected automagical conversion happening. Of course, knowing that it is an int-property makes for a trivial conversion, and that seems to be what this helper function is doing. On the other hand, this could of course be done or coded in many possible ways. As such, this particular function is not necessarily being "crucially relied upon", but it seems a matter of "clean housekeeping" to either remove this function (or disable or comment out etc) or have it at least functioning properly (and safely) all the way.
Why is passing the string "4" as a value to an int/enum property expected to work? I do not expect it to work at all, it makes no sense to accept it. The object you pass is only supposed to yield a well-defined value through the number protocol (which does _not_ include the equivalent of performing int("4"), which is an entirely different thing). For enum properties, strings are accepted additionally: The values' nicknames. This alone is a very good reason why you cannot accept "4" as 4: There could be a value with the nickname "4"! There even is at least one element in GStreamer that has such values, IIRC it is a compression setting somewhere and goes like: nick value -------------- "best" 0 "8" 1 "7" 2 ... ... "2" 8 "1" 9 "worst" 10 One can see how automagical conversion is not possible. Even if such a possibility for collision didn't exist, conversion from string to integer would be the wrong thing to do. pygobject simply is not Tcl/Tk :-) I totally agree that the function is broken and should not be kept around in this form. If my assumption is right (it compensated for binding deficiencies of the time), it can probably just call some_object.set_property directly.
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.
After reading this, the only thing that comes to mind is ... "Why on earth do we still have this method there ??". I'd be more inclined to just make that function a wrapper to gobject.GObject.set_property(...) The only person who could give sensible input would be johan, so I'm adding him to the CC.
(In reply to comment #6) > After reading this, the only thing that comes to mind is ... "Why on earth do > we still have this method there ??". I'd be more inclined to just make that > function a wrapper to gobject.GObject.set_property(...) > > The only person who could give sensible input would be johan, so I'm adding him > to the CC. > I can't remember writing that code, gst/extend didn't actually exist at the time I did most my gst-python hacking. webcvs tells me that thomas committed this, he might have based it of code I have written but I doubt it, check with him.
Ok, so what should happen now? :)
well, we have any news for this patch?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!