GNOME Bugzilla – Bug 671025
Constants and identifiers starting with a number are not usable in many languages
Last modified: 2013-10-13 22:50:02 UTC
In looking into different Gdk event types, I found that some of the namings cause syntax errors as below and need to be renamed: >>> Gdk.EventType.3BUTTON_PRESS
+ Trace 229763
Gdk.EventType.3BUTTON_PRESS
>>> Gdk.EventType.2BUTTON_PRESS File "<ipython-input-217-aac91f4ac60f>", line 1 Gdk.EventType.2BUTTON_PRESS ^ SyntaxError: invalid syntax >>>
GDK declares them like that, but identifiers starting with a number are not allowed in Python and most other languages. The current workaround in Python is to do getattr(Gdk.EventType, '3BUTTON_PRESS') We don't want to maintain a huge static list of those in pygobject, so perhaps gobject-introspection could prepend a '_' in front of those when it creates an identifier starting with a number? Or they could be renamed in GDK itself, of course. In pygobject itself this is pretty much "wontfix", I'm afraid.
Reassigning to gobject-introspection for now, let's see what the maintainers say. If they don't want this '_' prepend trick (and there's probably good reasons for not having this), let's re-assign to GDK to add aliases for those constants which don't start with a number.
For starters, having a list of the constants that cause you problems would be good. There may be different answers for different groups of constants, I think...
grep -A3 -i 'member name="[^a-z_]' /usr/share/gir-1.0/*.gir turns up: EBook-1.2.gir: EVC_FORMAT_VCARD_21 -> "21" EVC_FORMAT_VCARD_30 -> "30" Could be fixed up with /*< >*/ annotations to become VCARD_21 and VCARD_30. Gdk-2.0.gir / Gdk-3.0.gir: GDK_2BUTTON_PRESS -> "2button_press" GDK_3BUTTON_PRESS -> "3button_press" Add GDK_DOUBLE_BUTTON_PRESS, GDK_TRIPLE_BUTTON_PRESS aliases? GLib-2.0.gir: G_SPAWN_ERROR_2BIG -> "2big" Add G_SPAWN_ERROR_TOO_BIG alias? (And maybe deprecate the existing name, which is based off E2BIG, but is still dumb.) GstRtp-0.10.gir: GST_RTP_PAYLOAD_1016 -> "1016" There is probably an alternative name for whatever that codec type is that could be used instead / in addition. GstRtsp-0.10.gir: GST_RTSP_VERSION_1_0 -> "1_0" GST_RTSP_VERSION_1_1 -> "1_1" Could be renamed "RTSP_1_0", etc, like the EBook example.
(In reply to comment #4) > grep -A3 -i 'member name="[^a-z_]' /usr/share/gir-1.0/*.gir > > Gdk-2.0.gir / Gdk-3.0.gir: > > GDK_2BUTTON_PRESS -> "2button_press" > GDK_3BUTTON_PRESS -> "3button_press" > > Add GDK_DOUBLE_BUTTON_PRESS, GDK_TRIPLE_BUTTON_PRESS aliases? Can we do this just in the nick annotation ? > > GLib-2.0.gir: > > G_SPAWN_ERROR_2BIG -> "2big" > > Add G_SPAWN_ERROR_TOO_BIG alias? (And maybe deprecate the > existing name, which is based off E2BIG, but is still dumb.) Agreed
(In reply to comment #5) > > GDK_2BUTTON_PRESS -> "2button_press" > > GDK_3BUTTON_PRESS -> "3button_press" > > > > Add GDK_DOUBLE_BUTTON_PRESS, GDK_TRIPLE_BUTTON_PRESS aliases? > > Can we do this just in the nick annotation ? I think we need to keep the old names as well; comment 2 implies people are currently using "getattr(Gdk.EventType, '3BUTTON_PRESS')" in python, and I think I've seen something similar in gnome-shell.
Created attachment 208858 [details] [review] gspawn: rename G_SPAWN_ERROR_2BIG to be more bindings-friendly Rename G_SPAWN_ERROR_2BIG to G_SPAWN_ERROR_TOO_BIG (while keeping the old name for compatibility), to fix problems with language bindings where the old name translates into something that would be syntactically invalid due to starting with a digit.
Created attachment 208859 [details] [review] gdk: add bindings-friendly alias for GDK_EVENT_2BUTTON_PRESS GDK_EVENT_2BUTTON_PRESS and GDK_EVENT_3BUTTON_PRESS can't be used from some bindings because they'd translate to something syntactically invalid. Add GDK_EVENT_DOUBLE_BUTTON_PRESS and GDK_EVENT_TRIPLE_BUTTON_PRESS aliases to work around that.
Review of attachment 208859 [details] [review]: honestly, I think we should ditch these event types, and use a click count field that gets incremented. we can still synthesize these events as a backward compatibility measure.
Review of attachment 208858 [details] [review]: Looks ok to me
(In reply to comment #1) > GDK declares them like that, but identifiers starting with a number are not > allowed in Python and most other languages. The current workaround in Python is > to do > > getattr(Gdk.EventType, '3BUTTON_PRESS') > > We don't want to maintain a huge static list of those in pygobject, so perhaps > gobject-introspection could prepend a '_' in front of those when it creates an > identifier starting with a number? Or they could be renamed in GDK itself, of > course. > > In pygobject itself this is pretty much "wontfix", I'm afraid. Thanks for the work-around.
Comment on attachment 208858 [details] [review] gspawn: rename G_SPAWN_ERROR_2BIG to be more bindings-friendly Attachment 208858 [details] pushed as deea0e3 - gspawn: rename G_SPAWN_ERROR_2BIG to be more bindings-friendly
Moving to gtk
(In reply to comment #1) > > We don't want to maintain a huge static list of those in pygobject, so perhaps > gobject-introspection could prepend a '_' in front of those when it creates an > identifier starting with a number? Or they could be renamed in GDK itself, of > course. > > In pygobject itself this is pretty much "wontfix", I'm afraid. I don't think this type of issue can be comprehensively fixed in g-i, because languages have varying rules for identifier naming. It's certainly possible that there exists both: * Languages where leading numerics are valid * Languages where leading '_' is invalid Clearly though for a lot of major languages leading numerics are invalid, but I think the right fix is a combination of: 1) Change it in the libraries 2) Bindings should have a generic mechanism to access these identifiers; for example in Python this might be foo.__dict__['2CLICK']. Yes, not beautiful, but at least you can use it.
(In reply to comment #14) > Clearly though for a lot of major languages leading numerics are invalid, but I > think the right fix is a combination of: > > 1) Change it in the libraries Yeah, I filed bug 671322, suggesting the scanner should warn people when it sees these.
Isn't the change to GSpawn an ABI break? For a program compiled against the older GLib, we've now shifted the values of all of the enumeration members after G_SPAWN_ERROR_TOO_BIG. So if you update GLib, and your code was previously checking for say G_SPAWN_ERROR_NOENT, you'll now get G_SPAWN_ERROR_NAMETOOLONG.
no, 2BIG and TOO_BIG have the same value, so everything after them is unchanged
(In reply to comment #17) > no, 2BIG and TOO_BIG have the same value, so everything after them is unchanged Nevermind, right, should have actually checked. Thanks!
The following fix has been pushed: 154ce01 gdk: add bindings-friendly alias for GDK_EVENT_2BUTTON_PRESS
Created attachment 213429 [details] [review] gdk: add bindings-friendly alias for GDK_EVENT_2BUTTON_PRESS GDK_EVENT_2BUTTON_PRESS and GDK_EVENT_3BUTTON_PRESS can't be used from some bindings because they'd translate to something syntactically invalid. Add GDK_EVENT_DOUBLE_BUTTON_PRESS and GDK_EVENT_TRIPLE_BUTTON_PRESS aliases to work around that.
*** Bug 710072 has been marked as a duplicate of this bug. ***