I cam across another issue that was triggered by the same problem. I am explaining it here though I am not sure if it is going to affect the solution one way or the other.

The issue is explained in the post http://stackoverflow.com/questions/3933851/nan-giving-an-error-depending-on-python-startup

Namely, running the command

float('nan')

on a Python (tested with version 2.6.4) embedded in a Delphi 2009 application gives a EInvalidOp Delphi exception.

The solution as given in the link is to change the FPY control word (and revert it back when done).

The issue is important because it may break unexpected Python code. In my case, it broke the command

import json

because of the line

NaN, PosInf, NegInf = float('nan'), float('inf'), float('-inf')

in json.decoder. I have no idea what else may break in the standard library.

The reason I bring this up here is because the problem with the mismatch in FPU control world expectations between Delphi and Python is not localised. Given that the behaviour of float('nan') is assumed to be guaranteed by library developers (see PEP 754), this may come up anywhere.