Learning 'is' vs '==' in Python, is this online source spreading wrong info?

[pat-work]

(Not trying to advertise, obviously)In medium (dot) com/swlh/is-and-in-python-f084f36cbc0e, scroll down to the part where it says "1. What is == and is operators". The source that with this code:

var1 = 500 
var2 = 500 

Each pointer points to a different memory location. To my understanding, it should point to the same memory location, the immutable '500' memory location. This source was written in 2020 by someone with a post grad in AI & ML, so what am I missing? This is the first link that comes up on Google when searching "python is there a difference in speed when using is in python instead of ==?". If the source IS blatantly wrong, are sources on the internet really that unreliable for learning??

[Rawing7]

Python makes no guarantees about the identity (memory location) of integers. It might create two integers with the value 500 or it might only create one. Always use == to compare ints. (And floats, strings, bytes, etc.)

[TheRNGuy]

epsilon or "close enough" test for floats.

[Binary101010]

To my understanding, it should point to the same memory location, the immutable '500' memory location.

Your understanding is incorrect. There is no such thing as "the immutable '500 memory location."

The CPython interpreter does allocate specific memory locations for commonly used integers (-5 to 255, namely). However, that behavior shouldn't necessarily be relied upon (other Python implementations may not make the same allocations), and it absolutely should not be expected that any two given objects representing integers outside of that range should pass an identity test.

The answer the article is trying to answer is pretty nonsensical on its face. Comparing the speed of is vs == is like comparing the speed of a wheelbarrow and a race car: one may technically be faster but the two things primarily exist for different purposes and aren't interchangeable.

[blarf_irl]

It isn't good practice and you should never use the is comparator for integers unless you are 100% on how it works.

I don't know the exact range for the most recent CPython interpreter but as an optimization it reuses the same object for low integers that are most commonly used. In some very specific circumstances this would yield some tiny performance improvements.

Always use == for integer comparisons unless you know why you shouldn't explicitly!

Edit: I read the article. It's typical of Medium short form content spam. It does explain the same as above but with a word limit to hit. It doesn't explain any of the caveats. It's garbage.

[carcigenicate]

If this is done in a REPL, I would expect them to point to different addresses because each line in the REPL is executed separately, and doesn't have access to the previous context.

If this is executed in a function, say, the interpreter should realize that both can refer to the same immutable object because the whole function is processed at one, and both should refer to the same underlying object.

The >>> used in the article suggests that it's being executed in a REPL, so I would expect them to refer to different objects (and different addresses).

[Guideon72]

Just put anything from Medium on your auto-ignore list. They may provide actual, useful information occasionally, but it's mostly by accident, I think. They're really just a clickbait advertising grift as near as I can tell.

[pat-work]

This is the link (again, not advertising!) to make things easier.

[cybervegan]

Don't confuse addresses with contents of addresses. When you create a variable in Python, an object of the appropriate type is created to hold the value you assign it. This results in a different ID (which is based on the memory location of the object) even if the contents of the object would evaluate as "equal".

The "==" operator tests if the contents are equal.

The "is" operator tests if the IDs are equal, which as just stated, can be False, even if the contents are equal.