Thanks, Mark.

A few comments:

- The patch seems incomplete.  There are other places in the source tree 
that care about endianness.  I haven't done a thorough search, but the 
native endianness support in the struct module comes to mind.  There are 
also some more obscure places---for example, there's at least one piece of 
code (in Python/compile.c) that tries to distinguish between the doubles 
0.0 and -0.0 by looking only at the first and last bytes of the double, 
and that doesn't work for this particular mixed-endian format.
I guess the patch could go in as it is, but adding only partial support 
for mixed-endian doubles seems dangerous.

- I know very little about ARM, so please correct me if I'm talking 
rubbish here.  But if I understand correctly, this mixed-endian format is 
only an issue for the old ABI, and isn't relevant for the newer "Embedded" 
ABIs.  So the need for this is likely to diminish over the next few years.  
Is that correct?

- Adding support for mixed-endian doubles probably has to be considered a 
new feature, so could not go in until 2.7, which is probably still a good 
few months away (I'm guessing a year or more, but there's no roadmap at 
the moment).

How prevalent is the old ABI?  How widespread do you think it's likely to 
be in, say, 3 or 5 years' time?  Is there going to be a real need to be 
able to run Python 2.7 and Python 3.1 on mixed-endian platforms?

I'm -1 on adding mixed-endian support, especially if all that's gained is 
an ability to deal with infinities, nans and signed zeros.  It would mean 
adding a significant amount of code that's going to be awkward to maintain 
and test, and that seems likely to become redundant within a few years.

I'd upgrade that -1 to a -0 in the presence: of (1) an OABI ARM buildbot, 
(2) a developer who's available to do testing on ARM, and (3) a more 
complete patch.