On Sat, Aug 15, 2009 at 12:25 PM, Mark Dickinson<dickinsm@gmail.com> wrote:
On Sat, Aug 15, 2009 at 4:45 PM, Alexandre Vassalotti<alexandre@peadrop.com> wrote:
I believe the byteorder option shouldn't default to use the native byte-order however. As you mentioned, it would be a bad choice to encourage the default behaviour to be platform-dependent. And since the primary purpose of the API is long serialization, it would be short-sighted to choose the option that cannot be used for serialization as the default.
Whether it should default to 'little' or 'big' is pretty much an arbitrary choice. In my patch, I choose to default big-endian since it is the standard network byte-order. But maybe the option should default to little-endian instead since it more widely used. In addition, the patch is slightly more efficient with little-endian.
Given all this, it sounds like byteorder should be a required argument. 'In the face of ambiguity... ' and all that. As Nick pointed out, we can always add a default later when a larger set of use-cases has emerged.
You say that the 'primary purpose of the API is long serialization'. I'd argue that that's not quite true.
And you are totally right. Honestly, the only reason I was thinking about long serialization is because I have my hand full with pickle guts presently. :-) -- Alexandre