?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Python doc - morfizm


Jan. 4th, 2011 04:52 pm Python doc

My first bug found in Python doc:

1. "Note that numeric literals do not include a sign; a phrase like -1 is actually an expression composed of the unary operator ‘-‘ and the literal 1." (Python v2.7.1 language reference, Literals, 2.4.3. Numeric literals)

2. "Plain integer literals that are above the largest representable plain integer (e.g., 2147483647 when using 32-bit arithmetic) are accepted as if they were long integers instead." (Python v2.7.1 language reference, Literals, 2.4.4. Integer and long integer literals)

Based on these two things, I'd expect "-2147483648" be interpreted as long, because 2147483648 is long and unary - of long will result in long. The latter is supported by:

>>> -(2147483647+1)
-2147483648L


However, "-2147483648" is not long, it's int:

>>> -2147483648
-2147483648


Which is good, but which means the doc is incorrect. This is a minor thing, but I am disappointed, because if my reasoning is correct, it means the doc is not trustworthy.

10 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

(no subject) - (Anonymous)
From:morfizm
Date:January 5th, 2011 07:13 pm (UTC)
(Link)
You need bigger numbers? ;)
From:miris_rants
Date:January 5th, 2011 04:58 am (UTC)
(Link)
numbers beautiful numbers :)
From:morfizm
Date:January 5th, 2011 07:13 pm (UTC)
(Link)
Yeah :)
From:raindog_2
Date:January 5th, 2011 05:56 am (UTC)
(Link)
Интересно. Похоже что действительно неувязочка. Если хочешь, я спрошу у питоновских начальников.
From:morfizm
Date:January 5th, 2011 07:17 pm (UTC)
(Link)
С одной стороны, хочу, а, с другой, не хочу беспокоить людей по мелочам - может, дай, я дочитаю до конца, и если там будет что-то ещё, попрошу тебя обратиться сразу по нескольким вещам?

Меня смутил сам факт подобной неувязочки. Это простая не опечатка, т.е. явно что-то произошло - либо вначале думали так, потом решили иначе... не хочется предполагать, что спек написан банально небрежно (а этот вывод напрашивается).

По моему личному мнению, -2147483648 не должно быть long, т.к. влезает в int32, и может являться полезной константой. Поэтому сама концепция о том, что "минус число" - это не literal, а унарный минус плюс число - порочна. Я об этом сам думал значительно раньше, когда писал свой интерпретатор какого-то языка, поэтому мне эта неувязочка резко бросилась в глаза.
From:azzo27
Date:January 5th, 2011 06:35 am (UTC)
(Link)
Put attention that -1 and - 1 are not the same. The first is a negative constant, the second is unary operation. Also - -1 (combination of both) makes sense.
From:morfizm
Date:January 5th, 2011 07:04 am (UTC)
(Link)
Python language spec pretty clearly spells out that -1 is not a negative constant (at least, not a negative constant literal, when specified in source code). It's positive constant with unary - (see quote).

Edited at 2011-01-05 07:05 am (UTC)
From:babamarta
Date:January 5th, 2011 08:46 am (UTC)
(Link)
не про пост: в новый год со старым логином? К новому я так и не привыкла :)
From:morfizm
Date:January 5th, 2011 08:53 am (UTC)
(Link)
Я к нему, наверное, тоже не привык :) Судя по всему :)
From:dennyrolling
Date:January 5th, 2011 08:51 pm (UTC)
(Link)
first time I used power shell I found an arithmetic bug.

Script illustrating the problem:
[uint64] $i = 1023;
[uint64] $step = 0x40000000000000;
[uint64] $hashFrom = $i * $step; # 0xFFC0000000000000
[uint64] $hashTo = $hashFrom - 1 + $step; # 0xFFC0000000000000 - 1 + 0x40000000000000 = 0xFFFFFFFFFFFFFFFF (18446744073709551615)

Which fails with:
Cannot convert value "1.84467440737096E+19" to type "System.UInt64". Error: "Arithmetic operation resulted in an overflow."
+ [uint64] $hashTo <<<< = $hashFrom - 1 + $step;


Workaround:
[uint64] $hashTo = $hashFrom - [uint64]1 + $step