Path: csiph.com!news.mixmin.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
To: python-list@python.org
From: Akira Li <4kir4.1i@gmail.com>
Subject: Re: Terminology: "reference" versus "pointer"
Date: Mon, 14 Sep 2015 02:17:53 +0300
References: <c3363$547e74fe$5419aafe$24179@news.ziggo.nl> <55F36B4C.9020007@gmail.com> <1442016698.95299.381478313.2487CA0E@webmail.messagingengine.com> <mt04ao$ite$1@ger.gmane.org> <m2zj0ss2md.fsf@fastmail.com> <85mvws6z45.fsf_-_@benfinney.id.au> <m2k2rws0yr.fsf@fastmail.com> <85io7g6xy4.fsf@benfinney.id.au> <m2egi4rzz5.fsf@fastmail.com> <85egi46wng.fsf@benfinney.id.au> <m2zj0sqjl8.fsf@fastmail.com> <mailman.419.1442039210.8327.python-list@python.org> <d55daf4b-b7c2-41fb-8010-76d6d65eb6b8@googlegroups.com> <mailman.425.1442068881.8327.python-list@python.org> <1a1a1f6a-27ce-4c1b-807a-43eabaa04abb@googlegroups.com> <mailman.435.1442080562.8327.python-list@python.org> <04ca9d7c-d02b-4329-bd94-4d18d86b3edf@googlegroups.com> <87egi375wb.fsf@gmail.com> <m21te3qqeg.fsf@fastmail.com> <87wpvu5h7f.fsf@gmail.com> <m2egi2p2dr.fsf@fastmail.com>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
Cancel-Lock: sha1:RyVD4SzqpdUVjY9fouK+aCpU/yg=
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.505.1442186367.8327.python-list@python.org>
Lines: 89
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96532

Random832 <random832@fastmail.com> writes:

> Akira Li <4kir4.1i@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