On Thu, Jul 17, 2003 at 10:30:06AM +0100, Gustavo J. A. M. Carneiro wrote: > 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. I thought a bit about Martin's recommendation for float() and str(). Now this is a bit tricky, because if we *do* support LC_NUMERIC in a PyGTK interface, for instance, a spinbutton.get_text() that returned "50,00" would *not* be parseable by float(). The underlying truth is that locale-represented values will not be directly convertible to Python's C-locale values. 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. If the latter, we might like to change float() to parse *both* the standard format and the locale-determined format. There may be [broken] code that relies on float raising a TypeError if something like "50,00" is passed to it, however. Other than that it seems safe as a special-case. Similar considerations work the opposite way for str(); however there is no option for the double behaviour we can support in float -- either it generates a locale-formatted float, or not, and the latter seems `more correct'. We have locale.format() for that anyway. Your opinions are appreciated, -- 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