Path: csiph.com!news.mixmin.net!newsreader4.netcologne.de!news.netcologne.de!bcyclone05.am1.xlned.com!bcyclone05.am1.xlned.com!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 03:30:37 +0300
References: <c3363$547e74fe$5419aafe$24179@news.ziggo.nl> <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> <87pp1l6h9a.fsf@gmail.com> <CAPTjJmpRfBxxJQe1qbc5Z5dBHuP7a=pb1GRSCYnCeGaXyHnUUg@mail.gmail.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:a1cnT6n+zHY/06UvSiBLpnQjykc=
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.508.1442190730.8327.python-list@python.org>
Lines: 71
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:96537

Chris Angelico <rosuav@gmail.com> writes:

> On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4.1i@gmail.com> wrote:
>> 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.
>
> Since you're talking about precise terminology, I think it would be
> better to say "name binding", rather than "naming and binding". When
> you talk of naming something (or someone!), you generally mean that
> it's possible to go from the thing to the (canonical) name. With
> people, for instance, you can walk up to someone and say "Hi! What's
> your name?", but with Python objects, you fundamentally can't.

"Naming and binding" is the title from the Python language reference
https://docs.python.org/3/reference/executionmodel.html#naming-and-binding

Otherwise, I agree with you ("name" is better here).

>>> 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.
>
> "Physically" isn't really the right word for it, given that objects in
> Python code aren't physical and therefore don't *ever* "physically
> exist". My bad there.
>
> But the objects completely do not exist. Yes, with integers you can't
> tell... but what about here?
>
> dependencies = collections.defaultdict(list)
> for fn in files:
>     for dep in gather_deps(fn):
>         dependencies[dep].append(fn)
>
> Until the moment when dependencies[dep] is requested for some new
> value of dep, the list *does not exist*. It is constructed anew.
> Obviously the end result of this is a dict of lists, and since those
> lists aren't accessible from anywhere else, it makes fine sense to
> talk about those lists as being "contained within" the (default)dict;
> but they clearly didn't exist until they were poked at. They're
> Heisenburg's Lists, I guess...

lists are _mutable_ in Python.