[Python-Dev] LC_NUMERIC and C libraries (original) (raw)

Christian Reis kiko@async.com.br
Tue, 15 Jul 2003 19:24:22 -0300

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