[Python-Dev] Unary minus bug (original) (raw)

Tim Peters tim.peters at gmail.com
Sun Jul 9 23:54:53 CEST 2006

[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 allonebits = '0xffffffff' self.assertEqual(eval(allonebits), 4294967295L) self.assertEqual(eval("-" + allonebits), -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))

More information about the Python-Dev mailing list