GNOME Bugzilla – Bug 114132
GtkSpinButton and LC_NUMERIC are a problem for bindings
Last modified: 2011-02-04 16:12:02 UTC
Certain locales define special decimal separators (via LC_NUMERIC). I believe the GtkSpinButton in fact *does* support these naturally via LC_NUMERIC (which changes sprintf and friends internally to glibc). However, the Python interpreter forbids changes to LC_NUMERIC since they cause all sorts of breakage inside the interpreter. This doesn't play very nicely with libraries, of course, but I'm not sure if this issue has come up before here so I'm pointing it out: SpinButton in PyGTK does not support LC_NUMERIC setting and it causes inconsistent UI in commercial-grade apps. I'm filing this against the GTK+ product because it's the only place I see where we could provide a workaround for this issue. I'm not arguing this is a bug in GTK+ -- it's not; however, offering a convenience function might make it possible to work around this very complicated Python issue would be very appreciated. Non-US locales that want to use PyGTK to build interfaces will run into this very quickly, and even though it's really an issue with Python, the perceived result is that "PyGTK/GTK don't support localized decimal separators". Since all commercial-grade toolkits do support this, it would be nice to see a solution implemented. I'm filing this bug to make sure I have a way to track what solution we can think up to solve this problem. James and Johan are invited to give their opinions -- perhaps we can fix this at the PyGTK level alone? Maybe push a PEP?
Python guys might be interested in g_ascii_strtod() in glib, which is a strtod() that ignores LC_NUMERIC - I'm sure we can relicense that code under python license.
By using g_strtod() we could make gtkspinbutton accept *either* the locale separator or '.', which might be nice, but I don't see how it's possible to recover from having LC_NUMERIC unset. The information about what the locale separator is is being hidden from GTK+.
Thanks for the replies. Owen, your suggestion would at least unbreak the display side of the data, which is great already. I'm going to talk to the Guido and see what he thinks of the whole issue. He might want to see a PEP.
The difference with my change would simply be that when running with LC_NUMERIC set properly, you would see: 12,345 But could enter either 12.345 or 12,345. Putting on the 2.2.3 milestone, though I really think that this is probably a NOTGNOME bug.
This is almost definitely a NOTGNOME bug. The Python interpreter will not function correctly with LC_NUMERIC!=C: http://www.python.org/doc/current/lib/embedding-locale.html There really isn't anything for GTK to do. As Havoc mentioned, the correct fix is for Python to not use locale sensitive functions for parsing numbers.