Terminology: "reference" versus "pointer"
4kir4.1i at gmail.com
Mon Sep 14 19:45:22 CEST 2015
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"  and "box and arrows"  (boxes are always empty, they only
>> point to objects) models to be the same and different from "labelled
>> box"  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
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"  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).
More information about the Python-list