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
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:
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:
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