[Python-Dev] LC_NUMERIC and C libraries
Tue, 15 Jul 2003 19:24:22 -0300
I've been tracking down some usability issues in our GUI apps lately, and
one of them has brought me through GTK+  into the Python parser. The
problem is simple: as per ,
The setlocale() function in the locale module gives the Python
programmer the impression that you can manipulate the LC_NUMERIC
locale setting, but this not the case at the C level: C code will
always find that the LC_NUMERIC locale setting is "C". This is
because too much would break when the decimal point character is set
to something else than a period (e.g. the Python parser would break).
This presents a problem to PyGTK in particular (and to other toolkits
which are `numeric-aware') since the library it wraps, GTK+, depends on
LC_NUMERIC being set correctly to be able to handle input in certain
Case at hand: GtkSpinButton, which allows the entry of values with
decimal separator. The decimal separator needs to be localized, since
our locale (pt_BR -- as do many others) uses commas instead of dots to
separate decimals. Because Python always sets LC_NUMERIC to C, however,
this doesn't work -- commas are rejected, as GTK+, while parsing the
string, doesn't recognize it as a valid `float' (in the C locale).
I've spoken briefly to Guido about this, and he's suggested python-dev
as the place to ask. I'd really like to know how bad "too much would
break" is, and if anybody contemplates a way to fix it [*]. I'd volunteer to
work on the change, of course.
[*] Havoc Pennington, from the GTK+ team, has offered a
LC_NUMERIC-agnostic strtod() implementation, but I get the feeling this
is more involved than just that.
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL