<div class="gmail_quote">On Sat, Dec 3, 2011 at 5:32 PM, MRAB <span dir="ltr"><<a href="mailto:python@mrabarnett.plus.com">python@mrabarnett.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 04/12/2011 01:17, Guido van Rossum wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Sat, Dec 3, 2011 at 5:13 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>>> wrote:<br>
<br>
    On Sun, Dec 4, 2011 at 3:07 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a><br></div><div><div class="h5">
    <mailto:<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>>> wrote:<br>
     >> This is because Python's integers are not limited to 32 bits or<br>
    64 bits. If<br>
     >> you read PEP 237, you'll see that this was one of the hardest<br>
    differences<br>
     >> between ints and longs to be resolved. You'd have to include an<br>
    infinite<br>
     >> number of leading 'F' characters to format a negative long this<br>
    way...<br>
     ><br>
     > That's a fair point :)<br>
<br>
    Random thought... could we use the integer precision field to fix<br>
    *that*, by having it indicate the intended number of bytes in the<br>
    integer?<br>
<br>
    That is, currently:<br>
<br>
     >>> "{:.4x}".format(31)<br>
    Traceback (most recent call last):<br>
      File "<stdin>", line 1, in <module><br>
    ValueError: Precision not allowed in integer format specifier<br>
<br>
    What if instead that produced:<br>
<br>
     >>> "{:.4X}".format(31)<br>
    0000001F<br>
     >>> "{:.4X}".format(-31)<br>
    FFFFFFE1<br>
<br>
Usually that field is measured in characters/digits, so this should<br>
probably produce FFE1; you'd need {:.8X} to produce FFFFFFE1. This would<br>
then logically extend to binary and octal, in each case measuring<br>
characters/digits in the indicated base.<br>
<br>
</div></div></blockquote>
+1<br>
<br>
Not only would that be more consistent, it would also have a use-case.</blockquote></div><br>OTOH I'm not sure what should happen if the number (negative or positive!) doesn't fit in the precision.<br><br>How common is this use case? Personally I'm fine with writing x & (2**N - 1) where N is e.g. 32 or 64.<br clear="all">

<br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>