I think it would be cleaner to interpret these two bytes as unsigned, and then mask with 0x7fff and with 0x8000 to get the exponent and the sign information. It doesn't really make sense to interpret as two's complement first. However, I appreciate that that's how the original code worked (using a struct format of ">h"), so if it's not changed it's no worse than before.

Is this special case necessary? I think the right thing to do here is to say: if expon == 0: expon = 1, and then continue to the ldexp call; I think this will do the right thing both on current Python, and on some future hypothetical version of Python where float does actually have the range required to represent the subnormal range of the x87 extended precision format.

Sorry, but I don't understand the reason of changing 0 to 1 in exponent.

An exponent of 0x7fff indicates an infinity or NaN. I'd expect to see an exception at this point, but I guess we don't want to change existing behaviour. It might be worth a comment, though.

As mentioned in the issue discussion, I'd suggest just letting the OverflowError propagate. If we encounter a value like this. But in that case, we should probably also raise for an infinity or NaN above.

So if we want to be internally consistent, I guess the choices are:

• (1) raise on overflow, nan and infinity, or
• (2) return sys.float_info.max on overflow, nan and infinity

I find it hard to see any justification for option (2) (especially, turning a nan into sys.float_info.max seems completely nonsensical) other than that that's what the current code does. Backwards compatibility seems unlikely to be a concern here.