Terminology: "reference" versus "pointer"

[Akira Li]

Chris Angelico <rosuav at gmail.com> writes:

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

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