# When you run the program:
a,b=300,300
print(a is b)
#you get different results in 3.6 (True) and 3.7 (False)

Python makes no guarantee as to whether an identity test on integers would return True or False. You should not depend on the behavior in any particular version.

This is the sort of thing that makes me avoid "is" in favor of "==" for most applications.  Understanding when two objects point to the same memory requires a deeper understanding of the underlying code than I usually want to delve into.

Anyway, I find it interesting that for 3.7.3:
>>> a, b = 256, 256
>>> a is b
True

>>> a, b = 257, 257
>>> a is b
False


So 2**8 is a magic number, for whatever reason.  I'll be sticking with "=="...

"So 2**8 is a magic number, for whatever reason."

Actually, this is true. Accordingly to https://rushter.com/blog/python-integer-implementation/

"Optimization of commonly-used integers
Small integer objects in a range of -5 to 256 are always pre-allocated during initialization. Because Python integers are immutable, we can use them as singletons. Every time you need to create small integer instead of creating new object Python just points to already allocated one. Thereby it saves a lot of space and computation for commonly-used integers.

Interestingly enough, the PyLongObject structure takes at least 28 bytes for every allocated integer and therefore takes three times as much memory as a simple 64-bit C integer."

This are constants 

#define NSMALLPOSINTS           257
#define NSMALLNEGINTS           5

You can find the code in:

https://github.com/python/cpython/blob/master/Objects/longobject.c

Well, then I guess that explains it!  Still, like I said, I tend to shy away from features that require such a deep understanding of the implementation in order to avoid "gotchas".  "is" does have its uses, but for me they very very rarely come up.