"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Stargaming <[EMAIL PROTECTED]> wrote: | | > On Mon, 17 Mar 2008 16:03:19 +0000, Duncan Booth wrote: | > | >> For the answer I actually want each asterisk substitutes for exactly one | >> character. | > | > Played around a bit and found that one: | > | > Python 3.0a3+ (py3k:61352, Mar 12 2008, 12:58:20) | > [GCC 4.2.3 20080114 (prerelease) (Debian 4.2.2-7)] on linux2 | > Type "help", "copyright", "credits" or "license" for more information. | >>>> a = 1 | >>>> b = 1//1 | >>>> if a is b: print('yes!') | > ... | >>>> b | > 1 | >>>> type(b) | ><type 'int'> | | I've had a look to see why this happens: long division (and in Python 3 all | integers are longs) allocates a new long to hold the result of the division | so it will never use one of the preallocated 'small int' values. | | That makes sense so far as it goes, but I'm slightly suprised if it isn't | worth an extra check somewhere for numerator fitting in a machine int and | shortcutting the long division.
I submitted the following to the issue tracker http://bugs.python.org/issue2417 Python 3.0a3 (r30a3:61161, Mar 1 2008, 22:51:17) [MSC v.1500 32 bit (Intel)] on win32 >>> a,b=1,1//1 >>> a is b False IDLE 3.0a3 >>> a,b=1,1//1 >>> a is b True ditto for 2.5.2 interpreter On c.l.p, Duncan Booth wrote I've had a look to see why this happens: long division (and in Python 3 all integers are longs) allocates a new long to hold the result of the division so it will never use one of the preallocated 'small int' values. That maybe explains the change from 2.5 but not the difference from IDLE. More important, the small int checks are present with the other operations: >>> 1*1 is 1 True >>> 1+1 is 2 True >>> 1-1 is 0 True >>> 1**1 is 1 True so the omission with // is plausibly a bug. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list