[issue1023290] proposed struct module format code addition
Mark Dickinson
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.
<bikeshedding>
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-
endian.
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
order.
Can we use 'length' instead of 'fixed_length'?
</bikeshedding>
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:
http://mail.python.org/pipermail/python-ideas/2009-August/005489.html
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________
More information about the Python-bugs-list
mailing list