On Sat, Dec 3, 2011 at 5:32 PM, MRAB <python@mrabarnett.plus.com> wrote:
On 04/12/2011 01:17, Guido van Rossum wrote:
On Sat, Dec 3, 2011 at 5:13 PM, Nick Coghlan <ncoghlan@gmail.com
<mailto:ncoghlan@gmail.com>> wrote:

   On Sun, Dec 4, 2011 at 3:07 AM, Antoine Pitrou <solipsis@pitrou.net
   <mailto:solipsis@pitrou.net>> wrote:
    >> This is because Python's integers are not limited to 32 bits or
   64 bits. If
    >> you read PEP 237, you'll see that this was one of the hardest
   differences
    >> between ints and longs to be resolved. You'd have to include an
   infinite
    >> number of leading 'F' characters to format a negative long this
   way...
    >
    > That's a fair point :)

   Random thought... could we use the integer precision field to fix
   *that*, by having it indicate the intended number of bytes in the
   integer?

   That is, currently:

    >>> "{:.4x}".format(31)
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   ValueError: Precision not allowed in integer format specifier

   What if instead that produced:

    >>> "{:.4X}".format(31)
   0000001F
    >>> "{:.4X}".format(-31)
   FFFFFFE1

Usually that field is measured in characters/digits, so this should
probably produce FFE1; you'd need {:.8X} to produce FFFFFFE1. This would
then logically extend to binary and octal, in each case measuring
characters/digits in the indicated base.

+1

Not only would that be more consistent, it would also have a use-case.

OTOH I'm not sure what should happen if the number (negative or positive!) doesn't fit in the precision.

How common is this use case? Personally I'm fine with writing x & (2**N - 1) where N is e.g. 32 or 64.

--
--Guido van Rossum (python.org/~guido)