Terminology: "reference" versus "pointer"
4kir4.1i at gmail.com
Mon Sep 14 01:17:53 CEST 2015
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 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/a nametag to put on the "1" object?
a/a are not names. Though if we want to talk about the
corresponding objects then a/a 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
> 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 :
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
>>> (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
> 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.
More information about the Python-list