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