I'm wrong or Will we fix the ducks limp?

[Marko Rauhamaa]

Steven D'Aprano <steve at 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