[Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]

Tim Peters tim.one at comcast.net
Sat Aug 30 22:25:41 EDT 2003


[James Henstridge]
>> As Christian said, there is code in glib (not to be confused with
>> glibc: the GNU C library) that could act as a basis for locale
>> independent float conversion functions in Python.

[Martin v. Löwis]
> I very much doubt that this statement is true. Are you sure this code
> supports all the platforms where Python runs? E.g. what about the
> three (!) different floating point formats on a VAX?

Well, you should look at the patch:  it doesn't know anything about internal
fp formats -- all conversions are performed in the end by calling the
platform C's strtod() or snprintf().  What it does do is:

1. For string to double, preprocess the input string to change it to
   use current-locale spelling before calling the platform C strtod().

2. For double to string, postprocess the result of the platform C
   snprintf() to replace current-locale spelling with a "standard"
   spelling.

So this is much more string-munging code than it is floating-point code.
Indeed, there doesn't appear to be a single floating-point operation in the
entire patch (apart from calls to platform string<->float functions).

OTOH, despite the claims, it doesn't look threadsafe to me:  there's no
guarantee, e.g., that the idea of current locale g_ascii_strtod() obtains
from localeconv() at its start is still in effect by the time
g_ascii_strtod() gets around to calling strtod().  So at best it solves part
of one relevant problem here (other relevant problems include that platform
C libraries disagree about how to spell infinities, NaNs and signed zeroes;
about how many digits to use for an exponent; and about how to round results
(for example,

>>> "%.1f" % 2.25
'2.3'
>>>

on Windows, but most (not all!) flavors of Unix produce the IEEE-754
to-nearest/even rounded '2.2' instead)).

It's easy to write portable, perfectly-rounding string<->double conversion
routines without calling any platform functions.  The rub is that "fast"
goes out the window then, unless you give up at least one of {portable,
accurate}.




More information about the Python-Dev mailing list