[Python-Dev] LC_NUMERIC and C libraries

[Gustavo J. A. M. Carneiro]

A Qua, 2003-07-16 =E0s 19:59, Martin v. L=F6wis escreveu:
> Christian Reis <kiko@async.com.br> writes:
>=20
> > > 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=
h a
> > > locale (de_DE uses the same convention). This is triggered by atof(=
3)
> > > changing its meaning, inside compile.c:parsenumber.
> >=20
> > Is there a good reason to prefer atof() over strtod(), if we already
> > have a locale-safe version of the latter?
>=20
> 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.

  Open issues:
	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!
=20
  I'm going to proceed with this, but any advice is welcome!

  Regards.

--=20
Gustavo Jo=E3o Alves Marques Carneiro
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>