You may have let yourself in for something here.  :-)

Can you tell me what:

>>> import sys
>>> print sys.float_repr_style

gives for your Opensolaris/suncc/Python3.x combination?  If it prints 
'legacy', then I'd dearly like some help with making it read 'short' 
instead.  That would then make treatment of nans on that combination 
consistent with other platforms.

All I really need to know is how to set the x87 (I'm assuming you're on 
32-bit x86 here) FPU control word using suncc.  Oh, and a willing victim 
to test changes.  Look for HAVE_PY_SET_53BIT_PRECISION in 
Include/pyport.h for details.


Having said that, I don't really see this difference with nans as an 
actual bug.  Is it possible that float("nan") is simply giving a nan 
with its sign bit set here, and that float("-nan") is giving a nan with 
no sign bit set?  That would actually be quite unsurprising, since 
according to Intel's manuals, the 'default' NaN value returned by 
invalid operations has its sign bit set.  It would also be (I think) 
quite legal:  sign bits of NaNs don't make a lot of sense anyway, and I 
don't think Python should specify anything about the sign bit (or indeed 
the payload) of the NaN coming from float('nan').

In other words, I think it's not unreasonable to regard the sign of
copysign(x, y) as undefined whenever y is a nan.  (I'm fairly sure that 
MPFR takes this attitude, for example.)