[Python-Dev] LC_NUMERIC and C libraries

[Christian Reis]

On Thu, Jul 17, 2003 at 10:30:06AM +0100, Gustavo J. A. M. Carneiro wrote:
>   I've been grepping through the Python source, and it seems both atof()
> and strtod() are used plenty.  I made two new functions: Py_strtod() and
> Py_atof(), and replaced all calls to atof and strtod with calls to these
> new functions.  At the moment, Py_atof() calls atof(), and Py_strtod()
> calls strtod().   Soon, I will replace them with an implementation based
> on glib's g_ascii_strtod.

I thought a bit about Martin's recommendation for float() and str(). Now
this is a bit tricky, because if we *do* support LC_NUMERIC in a PyGTK
interface, for instance, a spinbutton.get_text() that returned "50,00"
would *not* be parseable by float(). The underlying truth is that
locale-represented values will not be directly convertible to Python's
C-locale values.

I'm not sure this is correct. If it isn't I suggest two alternatives:
offer an additional float() that *does* support LC_NUMERIC
(float_localized?), or change float() semantics. If the latter, we might
like to change float() to parse *both* the standard format and the
locale-determined format.

There may be [broken] code that relies on float raising a TypeError if
something like "50,00" is passed to it, however. Other than that it
seems safe as a special-case.

Similar considerations work the opposite way for str(); however there is
no option for the double behaviour we can support in float -- either it
generates a locale-formatted float, or not, and the latter seems `more
correct'. We have locale.format() for that anyway.

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