We are using python as an embedded scripting environment in our ERP-product.
Since upgrading to python2.7 we have serious issues with floats:

>>> 28710.0
'2870:.0'
>>> round(28710.0)
2870.0

We are embedding Python in a Delphi-application.

The problem was already discussed in issue9980 and has to do with Delphi setting the FPU precision to 64bit (and relying on this setting) while the standard with Microsoft Tools is 53bits.
The routines _Py_dg_dtoa and _Py_dg_strtod in dtoa.c rely on the FPU precision set to 53bits.

Issue9980 was closed as "won't fix" but I propose to reconsider this decision for the following reasons:

- Delphi is still an important development environment for native win32 applications and has excellent Python embedding support through PythonForDelphi (http://code.google.com/p/python4delphi).

- Ensuring 53bit before calling python code is not practical in an embedded python environment with extensions in delphi (python may also call code that is implemented in delphi).

- The changes needed in pythoncore are minimal. Tests documented in issue9980 found no measurable performance impact.

- FPU precision switching is needed and already (partially) implemented for linx, where 64bit prec is standard.

Fixing this issues is absolutely vital for us, so we needed to compile a custom version of pythoncore.

I appended a .diff file detailling the patch.

Changes are needed in 2 places:
- pyport.h, defining the _PY_SET_53_BIT_PRECISION macros for MS visual c compiler
- floatobject.c, insert precision switching macros in _Py_double_round function.

In pystrtod.c the precision switching macros are already used.
pystrtod.c and floatobject.c are the only places in CPython where the dtoa.c functions are called.

The macros for visual-c are activated by defining HAVE_VC_FUNC_FOR_X87 preprocessor-symbol.

Hoping for inclusion of this patch.

Cheers
Samuel