Steven D'Aprano <st...@pearwood.info>: > On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote: >> Are variables like little boxes? Yes they are. > > That's *exactly* what variables in Python are not like.
Of course they are. Or, rather, the little-box mental model is no worse than any other. You could also think of variables as pegs, references as leashes, and objects as cute puppies. One puppy could be held with multiple leashes hung on separate pegs. Some puppies hold leashes in their mouths. Every leash is tied to a puppy or a special wooden post called None. >> But they are all the same size, while objects may be large (even very >> large) or small. That is why variables hold, not objects, but >> references to objects. > > No they don't. You are confusing the implementation with the > programming model. The easiest way to understand the references of Java, Python, Lisp and others is through an underlying implementation. I really haven't seen a better abstract model presented. (An alternate model could be the semantics of lambda calculus, which doesn't have a data model at all! Instead, the semantics are given through the execution model: a form is repeatedly transformed to new forms until no transformation is allowed by the rules. That kind of model would not suit Python, though, because Python's little boxes can be assigned to.) > Following the assignment: > > x = 99 > > if you print(x), do you see something like "reference 0x12345"? No. Irrelevant. The statement "print(x)" does not print a variable but the result of the evaluation of the given expression. > There is no analog to dereferencing in Python, nothing like print(x^). True, variables are not first-class objects in Python. (However, Guido could add first-class status to variables to Python with the snap of his fingers in a 100%-backwards-compatible manner.) > You bind values (that is, objects) directly to names, and names > (variables) hold their value, not a reference to their value. That mental model seems more confusing than the little-box one. > The fact that for some implementations that is implemented using > references of some sort or another (e.g. pointers in CPython) is an > implementation detail which is irrelevant to the language and its > execution model. The references cannot be removed from Python's data model. In fact, they haven't been: The value of an immutable container object that contains a REFERENCE to a mutable object can change when the latter’s value is changed; [...] Some objects contain REFERENCES to other objects; these are called containers. Examples of containers are tuples, lists and dictionaries. The REFERENCES are part of a container’s value. In most cases, when we talk about the value of a container, we imply the values, not the identities of the contained objects; however, when we talk about the mutability of a container, only the identities of the immediately contained objects are implied. So, if an immutable container (like a tuple) contains a REFERENCE to a mutable object, its value changes if that mutable object is changed. Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a REFERENCE to any existing object with the same type and value, while for mutable objects this is not allowed. E.g., after a = 1; b = 1, a and b may or may not REFER to the same object with the value one, depending on the implementation, but after c = []; d = [], c and d are guaranteed to REFER to two different, unique, newly created empty lists. (Note that c = d = [] assigns the same object to both c and d.) [etc etc] <URL: https://docs.python.org/3/reference/datamodel.html> (capitalization is mine) Marko -- https://mail.python.org/mailman/listinfo/python-list
