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

Christian Reis kiko@async.com.br
Thu, 17 Jul 2003 11:53:54 -0300

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: Pystrtod() and Pyatof(), and replaced all calls to atof and strtod with calls to these new functions. At the moment, Pyatof() calls atof(), and Pystrtod() calls strtod(). Soon, I will replace them with an implementation based on glib's gasciistrtod.

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