Terminology: "reference" versus "pointer"

[Akira Li]

Random832 <random832 at fastmail.com> writes:

> Akira Li <4kir4.1i at gmail.com> writes:
>> I'm not sure what "parcel tags" model is but if you mean these
>> pictures[1] than it works in this case as well as any other (take *a*,
>> *b* nametags, put them on the corresponding balloons that represents
>> list objects).
>>
>> The only names left are *a* and *b* that refer to the corresponding
>> lists. There is no ambiguity there to put *a*, *b* nametags.
>
> But how do you make an a[0][0]/a[1][0] nametag to put on the "1" object?

a[0][0]/a[1][0] are not names. Though if we want to talk about the
corresponding objects then a[0][0]/a[1][0] could be used instead of
names (as a way to identify them). 

>> Lists as any other containers contain references to other objects and
>> therefore "box and arrows" model provides _more details_ here[2,3]
>
> Right, but why not use the *same* model to represent *namespaces*?

If it works for your case; use it. The links [2,3] show that It does
work in this case (if it is correct to call what they show "box and
arrows" model).

> It seems like the "tags" model only exists to make the incorrect claim
> that python doesn't have variables (the boxes are variables).

If you mean this quote from [1]:

  Although we commonly refer to "variables" even in Python (because it's
  common terminology), we really mean "names" or "identifiers". In
  Python, "variables" are nametags for values, not labelled boxes.

then *name* is the term that is defined in the Python language
reference. The word "variable" we can use in day-to-day programming
_unless_ we are discussing issues that are specific to _naming and
binding_.  In that case, we should use the _exact_
terminology. Otherwise there is nothing wrong with using "variables"
casually in Python.

Notice: that [2,3] model is different from "labelled boxes" model. There
are arrows from *a*/*b* _to_ list objects i.e., *a*/*b* are not boxes
that _contain_ list objects within --
_otherwise you have to put the *same* list into two *different* boxes_ --
let's not investigate quantum paradoxes here. The only difference from
"parcel tags" model is that list items do not have explicit names.

>>> If the "parcel tags" model can't show it, then the "parcel tag" model
>>> clearly is not a correct and complete depiction of how Python actually
>>> works.
>>> (If I were drawing a picture rather than ASCII I'd add something to make
>>> it clear that the pairs shown are list objects Like, it's a circle with
>>> the word "list" and two pointer-boxes inside it.)
>>
>> "correct and complete" is impossible in the general case for any
>> model.
>
> Everything you wrote here has the same issue: The "objects" you are
> talking about do not physically exist, but are simply the result of
> calling a method on the object. Therefore they do not *belong* on the
> diagram, and the diagram not showing them does not mean the diagram is
> not complete.

"do not physically exist" does not make sense. Objects are *never*
destroyed explicitly in Python (you can only make them
*unreachable*). You can disable garbage collection completely and it is
still will be Python. Immutable objects can be considered immortal e.g.:

 (1+1) -- question: does the object that represents int(2) exist before
                    the expression is evaluated?

The correct answer: it does not matter: int(2) can be created on the
fly, a cached int(2) can be reused by a specific implementation --
Python doesn't care.

I don't see why the model that can't describe range(1) in Python 3
pretends to be complete.

[1]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names
[2]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=6
[3]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0Aa%5B0%5D%5B0%5D+%3D+%22Oops!%22&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=7