The way I see it, there are different views on the language.
- "Language Advocate."
- The prospect of a "practical programmer."
- perspective of the "implementer".
From the point of view of a language advocate, python variables always "point to" an object. However, unlike Java and C ++, the behavior of == <=> = etc depends on the type of runtime of the objects that the variables point to. Also in python, memory is controlled by the language.
From the point of view of a practical programmer, we can consider the fact that integers, strings, tuples, etc. are immutable * objects, not direct meanings like irrelevant details. The exception is storing large arrays of numerical data, which we can use for types that can store values directly (for example, numpy arrays), and not types that will contain an array full of references to tiny objects.
From the point of view of developers, most languages have some kind of as-if rule, so if the indicated behaviors are correct, the implementation is correct, regardless of how things really work under the hood.
So yes, your explanation is correct from the point of view of a language attorney. Your book is correct from the point of view of a practical programmer. The actual implementation actually depends on the implementation. In integers, cpython are real objects, although small integer values are taken from the cache pool and not re-created. I'm not sure what other implementations are doing (e.g. pypy and jython).
* note the difference between mutable and immutable objects here. With a mutable object, we must be careful when considering it as a value, because some other code can mutate it. With an immutable object, we have no such problems.
plugwash Jul 12 '17 at 12:46 on 2017-07-12 12:46
source share