After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 114132 - GtkSpinButton and LC_NUMERIC are a problem for bindings
GtkSpinButton and LC_NUMERIC are a problem for bindings
Product: gtk+
Classification: Platform
Component: Widget: Other
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2003-05-31 16:02 UTC by Christian Reis (not reading bugmail)
Modified: 2011-02-04 16:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2

Description Christian Reis (not reading bugmail) 2003-05-31 16:02:31 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?
Comment 1 Havoc Pennington 2003-05-31 17:24:24 UTC
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.
Comment 2 Owen Taylor 2003-05-31 17:57:29 UTC
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+.
Comment 3 Christian Reis (not reading bugmail) 2003-06-02 21:01:37 UTC
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.
Comment 4 Owen Taylor 2003-06-02 21:42:51 UTC
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.
Comment 5 James Henstridge 2003-06-03 04:38:34 UTC
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
parsing numbers.