RetroSearch Browse

Sun Aug 31 01:39:38 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-August/037882.html

James Henstridge <james at daa.com.au> writes:

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

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?

> One of the alternatives that some programs use to do locale
> independent conversions using code a bit like this:
>     char *oldlocale = setlocale(LC_NUMERIC, "C");
>     num = strtod(string, NULL);
>     setlocale(LC_NUMERIC, oldlocale);

Unfortunately, this is not thread-safe, so it is clearly out of
question.

> To sum it up, the current status-quo in Python w.r.t. locales is
> causing problems for some problems people want to use Python for.  It
> would be nice to fix this problem.

Certainly. However, incorporating glib code is not a
solution. *Calling* glib code (where available) might be a
solution. Also, the standard C++ library supports multiple concurrent
locale objects, so calling *that* (where available) might be an
option. Furthermore, the C++ library is often implemented on top of
some C-only library, so calling that library would be better, as it
would keep the C++ runtime library out of the Python prerequisites.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-August/037882.html below:

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