[Python-Dev] LC_NUMERIC and C libraries

[Christian Reis]

Hello there,

I've been tracking down some usability issues in our GUI apps lately, and
one of them has brought me through GTK+ [1] into the Python parser. The
problem is simple: as per [2],

    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
widgets correctly. 

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. 

[1] http://bugzilla.gnome.org/show_bug.cgi?id=114132
[2] http://www.python.org/doc/current/lib/embedding-locale.html

[*] 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.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL