> Instead of sticking to network byte order, I propose to include byte
> order information in the pickle (for example as '<' or '>' like struct
> does), so that pickling/unpickling between the same-endianness
> architectures doesn't have to convert at all.  Floats are always pickled
> as IEEE754, but the same optimization (not having to convert anything)
> would apply when unpickling a float array on an IEEE754 architecture.
>
> Preserving widths and including endianness information would allow
> pickling to be as fast as it is now (with the exception of unicode chars
> and floats on non-IEEE754 platforms).  It would also allow unpickling to
> be as fast between architecture with equal endianness, and correct
> between others.

This sounds like the best approach yet -- it can be made backwards
compatible (so 2.6 can read 2.5 pickles at least on the same platform)
and can be just as fast when unpickling on the same platform, and only
slightly slower on a different platform.