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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4