Terminology: "reference" versus "pointer"

[Akira Li]

Random832 <random832 at fastmail.com> writes:

> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
>
> That's not true in CPython. In fact, the range object in python contains
> *four* reference boxes - one more for length.

Even if it true in CPython. Specific implementations are irrelevant for
the discussions. Python -- the language -- does not mandate any
reference boxes (and given how you interpret the term "box" -- boxes are
not used anywhere).

>> I've mentioned it in another message but to be clear, I consider "parcel
>> tags" [1] and "box and arrows" [2] (boxes are always empty, they only
>> point to objects) models to be the same and different from "labelled
>> box" [3] model (boxes contain objects).
>
> See, I consider the box and arrow to be the same as the labeled box
> model - only the object the boxes contain is an arrow. Except for
> special kinds of boxes implemented in some other language, such as the
> elements of an array from the array module

   [box + arrow pointing to] + object == parcel tag + object

I could draw a picture but it won't be pretty.

"labelled box" model that assumes that objects are inside boxes is
clearly wrong -- it fails if you have two names that refer to the same
object in Python (you can't put the same object into different
boxes).

If a box contains nothing then there is no need for the box. If you
think the box contains "something" then find me the corresponding term
in Python language reference. I don't understand what is "arrow" that
the box might contain exactly. For example I can find what "name",
"object" mean in Python.

> The problem with "parcel tags" is that it represents namespaces - or one
> particular namespace, I've never seen any version of it that even
> clearly talks about locals, let alone different modules - differently
> from other kinds of objects.

I don't understand what are you trying to say here. If you have a
specific example when the "parcel tags" [1] model predicts a _wrong_
behavior; please do provide it. If your point is that "parcel tag" does
not describe in full detail all aspect of the behavior of an arbitrary
Python code then I agree with you (though none of the discussed models
can or should do it).