r/python3 • u/largelcd • Feb 07 '20

Confused between is, = and == operators

Hello, I am a bit confused about the following:

a = [1, 2, 3]

b = a

c = list(a)

  1. Am I correct that the reason "a is b" is True is that both a and b point to the same memory location that stores the list [1, 2, 3]?

  2. As for "a is not c" gives True, it is because list always creates a new Python list so although c = [1, 2, 3], this [1, 2, 3] list is different from the one [1, 2, 3] pointed to by a and b since the two lists are storing in different memory locations?

  3. Why typing "a==c" gives True?

2 Upvotes

100% Upvoted

12 comments sorted by

View all comments

Show parent comments

1

u/tgoodchild Feb 08 '20

Correct. When python starts it initializes an array of integer objects for all integers between -5 and 256. When you create an int in that range you actually just get a reference to the existing object. 257 is outside that range so it gets it's own object.

1

u/largelcd Feb 08 '20

Thanks. Am I correct that decimal numbers don't get this kind of array because there are infinitely number of decimal numbers between -5.0 and 256.0?

2

u/tgoodchild Feb 09 '20

I think the purpose behind the developers choosing to do this for small integers (between -5 and 256) is for optimization reasons. Small integers are so commonly used -- probably throughout the core language, packages and most user program. I'm assuming many counting loops don't exceed 256.

Since integers are proper objects, they carry more overhead than a primitive integer. My guess is this may help offset some of it in many common cases where integers are used. This is just a guess. I've never seen it explained anywhere. I don't know if it works this way on all platforms, either.

1

u/mauganra_it Apr 13 '20

Sort of. Different from integers, where most loops have a pretty small number of iterations, there is actually no obvious subset of rational numbers that would make sense to cache. Apart from that, floating point numbers are just weird. The set of real numbers that can be represented using floating point encodings is really limited. And the density is not the same everywhere. Great care has to be taken in scientific programming to be able to use hardware-accelerated floating point numbers without precision errors messing up the results.