[issue1023290] proposed struct module format code addition
report at bugs.python.org
Sat Aug 15 13:18:37 CEST 2009
Mark Dickinson <dickinsm at gmail.com> added the comment:
Thanks for this patch, Alexandre!
I'm +1 on applying a version of this patch.
I'm not convinced that the variable-length part (i.e., fixed_length=None) of
int.as_bytes is all that useful; the choices that need to be made about how to
represent integers seem too arbitrary to standardize in this function. In effect, the
non-fixed-length version provides yet another serialization mechanism for integers,
and there's no shortage of existing mechanisms. As I see it, the purpose of the
as_bytes and frombytes methods is lower-level: providing a basic operation that will
be used by various serialization methods. So I'd suggest making fixed_length a
required argument; code requiring non-fixed-length conversions can use int.bit_length
to help calculate the length they want.
I'm also not convinced by the defaults for the other two arguments: personally, I'd
expect to need unsigned more often than signed, and little-endian more often than big-
Perhaps the byteorder should default to the native byteorder when not explicitly
given? That would bring the conversions more closely in line with the struct module.
Another possibility: instead of 'little_endian', have a parameter 'byteorder' taking
the value 'big' or 'little'; this would enable use of byteorder=sys.byteorder to
explicitly specify native byteorder, and avoids bias towards one particular byte
Can we use 'length' instead of 'fixed_length'?
There's a typo in the test_long part of the patch: aserrtRaises -> assertRaises;
apart from that, all tests pass on OS X 10.5/Intel with this patch applied.
I'm in the process of looking at the code more thoroughly.
See related Python-ideas thread at:
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list