[Python-Dev] LC_NUMERIC and C libraries
Gustavo J. A. M. Carneiro
17 Jul 2003 10:30:06 +0100
A Qua, 2003-07-16 =E0s 19:59, Martin v. L=F6wis escreveu:
> Christian Reis <email@example.com> writes:
> > > I added the special-casing of LC_NUMERIC when I found Python can't
> > > parse floating point literals in Python source code anymore, in suc=
> > > locale (de_DE uses the same convention). This is triggered by atof(=
> > > changing its meaning, inside compile.c:parsenumber.
> > Is there a good reason to prefer atof() over strtod(), if we already
> > have a locale-safe version of the latter?
> I don't think so - it is the same on systems where strtod is supported.
> However, I think Python uses atof since strtod might not be available.
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.
1- Naming: I'm hacking the Python source for the 1st time; Should I be
using any other name, rather than Py_atof() and Py_strtod()?
2- float->string conversion: We need to get this replaced too, I
guess. This one is more tricky. snprintf seems to be used for this, and
it can produce strings with variable precision. glib has g_ascii_dtostr,
but it always outputs numbers with the maximum precision that allows
conversion back with g_ascii_strtod() without information loss.
3- Of course, I am not touching the locale module!
I'm going to proceed with this, but any advice is welcome!
Gustavo Jo=E3o Alves Marques Carneiro