Mark Dickinson <dicki...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue1023290> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com