[Python-ideas] Negative hexes

[MRAB]

On 04/12/2011 01:51, Guido van Rossum wrote:
> On Sat, Dec 3, 2011 at 5:32 PM, MRAB <python at mrabarnett.plus.com
> <mailto:python at 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 at gmail.com
>         <mailto:ncoghlan at gmail.com>
>         <mailto:ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>>> wrote:
>
>             On Sun, Dec 4, 2011 at 3:07 AM, Antoine Pitrou
>         <solipsis at pitrou.net <mailto:solipsis at pitrou.net>
>         <mailto:solipsis at pitrou.net <mailto:solipsis at 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.
>
Well, the width is treated as the minimum width, so perhaps the
precision should be the minimum precision in this case.

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