%a format

[Tim Peters]

[Martin v. Löwis]
> ...
> For the specific feature, I think a non-libc implementation would be
> possible, since Python uses IEEE representation for floating point
> numbers on most platforms (although atleast the VMS port doesn't
> necessarily). Whether it is reasonable to implement this by mere
> bit copying is a question that Tim Peters should answer :-)

Python has no knowledge of the FP format used by the platform C it's
compiled under.  VMS and some Crays may not use IEEE double format for
Python long, but we've got no code that knows (or cares) to build on. 
Endianness differs across platforms too, of course.

I don't have a use for %a myself, so I don't care about it.  Pickles
are Python's serialization format, and pickle protocols 1 and 2 use a
portable binary format for floats that happens to be identical to 754
double format for finite non-0 floats (and so is also restricted to
the precision and dynamic range of a 754 double).  The other
serialization format is repr(float), which produces a decimal string
representation, and on every IEEE platform with IEEE-conforming libc
I/O, eval(repr(afloat)) == afloat exactly for all finite afloat.  So
there are already those two ways to transport a finite 754 float
across boxes exactly.  The marshal and struct modules supply two more
(although marshal relies on repr(); and struct in its standard modes
copy-and-paste duplicates cPickle's code).  I don't need five ways to
spell it <wink>.