RetroSearch Browse

Sun Jul 9 23:54:53 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-July/067178.html

[Neil Schemenauer]
> The bug was reported by Armin in SF #1333982:
>
>     the literal -2147483648 (i.e. the value of -sys.maxint-1) gives
>     a long in 2.5, but an int in <= 2.4.

That actually depends on how far back you go.  It was also a long "at
the start".  IIRC, Fred or I added hackery to make it an int, because
back then there was a sharp distinction between int and long and a
surprising number of people complained about this case.  Strictly
speaking,  -2147483648 is not an integer literal (see the grammar --
Python has only positive integer literals).

> I have a fix but I wonder if it's the right thing to do.

Practicality beats purity here, IMO -- +1.

> I suppose returning a long has the chance of breaking someone code.  Here's
> the test we currently have for a related case:
>
>     [...]
>     # 32-bit machine
>     all_one_bits = '0xffffffff'
>     self.assertEqual(eval(all_one_bits), 4294967295L)
>     self.assertEqual(eval("-" + all_one_bits), -4294967295L)
>
> I guess I would add self.assertTrue(isinstance(eval("-2147483648"), int))
> to that set of tests.

Or, more obscure but maybe better (since this also tests the similar
endcase on sizeof(long) == 8 boxes):

    minint = -sys.maxint-1
    self.assert_(isinstance(minint, int))
    self.assert_(isinstance(eval(str(minint)), int))

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-July/067178.html below:

[Python-Dev] Unary minus bug