-1

in shell environment,

x = 250
y = 250
x + 100 is y + 100

x + 100 is y + 100 result is False. Why is the result value "False" while id(x), id(y) is same?

Also

x = 250
y = 250
x is y
x += 10
y += 10
x is y

last statement result is False. It is same problem.

I thought both questions would be True.

sepp2k
  • 363,768
  • 54
  • 674
  • 675
PPP
  • 1
  • 1
  • 1
    Small numbers are cached by Python so it only needs to keep a single copy. 350 is not considered small so it doesn't get cached. – Mark Ransom Jan 15 '23 at 18:16
  • 1
    Why would you expect them to be True? Have you checked the `id` of the variables after addition!? – luk2302 Jan 15 '23 at 18:16
  • 1
    You asked the wrong question. It should be: why does `is` return True for integers up to 255. The answer: internal optimization in CPython. – Klaus D. Jan 15 '23 at 18:17

3 Answers3

1

At a high-level, is checks whether the values refer to the same reference, while == calls a method of the objects to compare them

As a general rule, only use is when comparing against singletons

  • None
  • True
  • False

and == everywhere else

@Mark Ransom's comment gets to why this can have unexpected effects (such as numbers sometimes comparing the same, not not every time) .. small numbers have a special priority and are cached, though to my knowledge this is implementation-specific (and so it may vary between different interpreters and versions of Python) and should not be relied upon

>>> a = 100
>>> b = 100
>>> c = 1000
>>> d = 1000
>>> a is b
True
>>> c is d
False
ti7
  • 16,375
  • 6
  • 40
  • 68
  • Thanks for the edit. It's surprising how often my name gets randomly misspelled. – Mark Ransom Jan 15 '23 at 20:21
  • I'm guessing auto-correct is a large part of the reason. It drives me crazy sometimes. – Mark Ransom Jan 15 '23 at 20:35
  • P.S. there are other contexts where `is` can be useful too. Usually if `is` is true, `==` will be as well, except for some interesting and rare cases like `math.nan`. I believe dictionaries use this to avoid potentially expensive comparisons on their keys as an optimization. – Mark Ransom Jan 15 '23 at 20:47
  • ah, adjacent keys here! and indeed! – ti7 Jan 15 '23 at 22:13
0

is checks object identity. It is only True if you are comparing the same object on both sides. Just because two integers have the same value doesn't mean they have to be the same object. In fact, they usually aren't.

CPython optimizes a small set of integers (-5 through +256) to always be singletons. That is, whenever an integer is created, python checks whether the integer is in a small range of cached integers and uses those when possible. This is pretty quick - for small integers, which are the most commonly used integers, you don't need to create new objects. But its not scalable. Outside that range, python will generally create a new integer even if the integer already exists. The cost of lookup is too much.

The python compiler may also reuse immutables such as integers and strings that it knows about in a given compilation unit. This lookup is done once at compile and is relatively fast considering everything that goes on in that compile step.

But you can't rely on any of this. This is just how python happens to be implemented and the moment and it may change in the future. There are several singletons you can count on: None, True and False will always work.

tdelaney
  • 73,364
  • 6
  • 83
  • 116
0

"The is operator does not match the values of the variables, but the instances themselves."

Source : Understanding the "is" operator

To sum up, the values are equal but the instances isn't the same.

I recommend this lecture from Python official documentation : https://docs.python.org/3/tutorial/classes.html

chanoir2303
  • 9
  • 4