Immutable and Mutable Types

[Terry Reedy]

"Duncan Booth" <duncan.booth at invalid.invalid> wrote in message 
news:Xns9A65624FD1932duncanbooth at 127.0.0.1...
| Stargaming <stargaming at gmail.com> 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