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.

I agree this is a bug. Here is a related problem:

>>> 1 is divmod(1,1)[0]
False

>>> int('1') is 1
False
>>> 1 is int('0b1', 2)
False
>>> 1 is 0b10000 >> 4
False

there are probably more ...

I really don't understand *why* it's a bug.

Is anywhere in the Language Reference that says that 1 should be the
same object that another 1?

Or do you mean that they *should* be the same object for speed and/or
memory reasons? In this case... is this a bug? Or a request for
improvement or something?

The original bug is not whether or not python reuses int objects, but
rather that an existing optimization disappears under certain
circumstances. Something is breaking our optimization.

The later cases where the optimization is simply gone in 3.0a3 are more
difficult. We don't *have* to keep them.. but we probably want them.
The small int reuse happens for a reason.

I agree that this is not a bug in the strict sense. I could have
selected Type: resource usage (for memory increase). But the change of
behavior is also visible. I suspect the change is not intentional both
because of the pattern and because of recent discussion on PyDev that
small int caching should be kept.

If the precise change is intentional, this should be documented (here)
to answer further questions on c.l.p.

Attached patch fixes the cases discovered so far. It is possible that
in some of these cases creation of the long object that is later
discarded can be avoided by detecting small int return early, but such
optimizations should probably be left for later.

Any advise on how to write a unit test? Should the unit test detect
python compiled with NSMALLNEGINTS + NSMALLPOSINTS == 0 and disable
identity checks?

Unless someone has a legitimate use case for disabling small_int that
doesn't involve debugging (which I really doubt), I'd just assume it's
always in use.

Attached (issue2417a.diff) patch adds unit tests and fixes a few corner
cases when a non-preallocated 0 was returned to python.

Alexander, tried the issue2417a.diff patch against 65210, and does not
apply cleanly, could you please submit an updated one?

Thanks!

It looks like e-mail submission did not work. Uploading updated patch as issue2417b.diff .

Commited in r65220.

Thank you everybody!!