[Python-Dev] LC_NUMERIC and C libraries

[Christian Reis]

On Fri, Jul 18, 2003 at 12:49:08AM +0200, Martin v. L=F6wis wrote:
> Christian Reis <kiko@async.com.br> writes:
>=20
> > The underlying truth is that locale-represented values will not be
> > directly convertible to Python's C-locale values.
>=20
> That is not true. locale.atof should allow you to parse the string.
>=20
> > 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.=20
>=20
> I think this is unacceptable. In some languages, "." is used as the
> thousands-separator. Then, should "1.000" be 1e3, or 1e0?

Okay, that's a good enough justification for me.

We should be all set; I discussed this a bit with Gustavo this morning.
The locale-safe versions of float() and str() should live in locale [*],
and semantics for float() and str() stay unchanged.

[*] Is there a reason why we only have atof() and not float() in locale?
I'm asking because we *do* have str().  Would=20

    locale.float =3D locale.atof
   =20
be a good idea, for consistency's sake?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL