[martin@v.loewis.de]
While the feature is desirable, I don't like the patch it all. It copies the relevant code of Gnome glib, and I a) doubt it works on all systems we care about, and b) is too much code for us to maintain, and c) introduces yet another license (although the true authors of that code would be willing to relicense it)
OTOH, even assuming "C" locale, Python's float<->string story varies across platforms anyway, due to different C libraries treating things like infinities, NaNs, signed zeroes, and the number of digits displayed in an exponent differently. This also has bad consequences, although one-platform programmers usually don't notice them (Windows programmers do more than most, because MS's C library can't read back the strings it produces for NaNs and infinities -- which Python also produces and can't read back in then). So it's not that the patch is too much code to maintain, it's not enough code to do the whole job <0.9 wink>.
It would be better if system functions could be found for a locale-agnostic atof/strtod on all systems. For example, glibc has a strtod_l function, which expects a locale_t in addition to the char*.
Well, a growing pile of funky platform #ifdefs isn't all that attractive either.
It would be good if something similar was discovered for VC. Using undocumented or straight Win32 API functions would be fine.
Only half joking, I expect that anything using the native Win32 API would end up being as big as the glib patch.
Unfortunately, the "true" source of atof (i.e. from conv.obj) is not shipped with MSVC :-(
Would that help us if we could get it? I'm not sure how. I expect the true source is assembler, for easy exploitation of helpful Pentium FPU gimmicks you can't get at reliably from C code. Standard-quality float<->string routines require simulating (by hook or by crook) more precision than the float type has, and access to the Pentium's extended-precision float type can replace pages of convoluted C with a few machine instructions.