Terminology: "reference" versus "pointer"

[Chris Angelico]

On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4.1i at 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.

>> 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...

ChrisA