homepage

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