Terminology: "reference" versus "pointer"
rurpy at yahoo.com
rurpy at yahoo.com
Sat Sep 12 20:45:16 CEST 2015
On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
> Computer science and IT is *dominated* by a single usage for "pointer" --
> it's an abstract memory address. The fundamental characteristics of
> pointers are:
Just upthread, you claimed something was "universally agreed"
that was not so at all; so please forgive me for not taking your
*dominated*/single assertion on simply your claim that it is so.
> - they are first-class values; you can assign a pointer to a variable;
Not true for Python "pointers"
> - you can dereference a pointer: get the value pointed to;
True for Python "pointers"
> - (in some languages) you can get a pointer to a specific variable (possibly
> an unnamed, dynamic variable allocated in the heap rather than a named,
> statically allocated variable).
True for Python "pointers".
> The last two imply that the language must be one where values have fixed
> addresses, not just as a matter of implementation, but as a matter of
> language semantics. If they are free to move, they cannot have a fixed
The *address* must be fixed, that is, when you dereference the address
you must always get the same thing back. But that implies nothing about
how or where the thing is stored, or whether it can move or not.
Indeed C and other languages with what even you call pointers get the same
thing back even though the thing actually *has* moved in physical memory,
because the address is denoted as a virtual memory address. I take the
generalized meaning of "address" to be simply a token that allows you
to get back the same thing each time you use it.
> There are no values in these languages which correspond to the standard
> definition of pointer:
They have not such concept because the developers and documentors choose
not to describe that language that way. That does not mean one could not
come up with a perfectly valid description that did include the concept
> - you cannot get a pointer to an object or a variable (a name);
> - since there are no pointers, you cannot dereference them;
> - or assign them to a variable.
> Since pointers can be considered an indirect reference to a value, what sort
> of indirect references does Python have? The simplest thing in Python that
> is somewhat analogous to a pointer is a *name*, since names allow you to
> indirectly refer to some value:
> x = 23
> print(x) # prints the value referred to by x, not "x" itself.
> ptr = "x" # equivalent to "the address of x"
> y = globals()[ptr] # equivalent to dereferencing
Here is another kind of indirect reference
a = 23
The "pointer" in the first item of the list "a" does not have a
name. But we can still dereference it. The dereferencing happens
automatically when "a" is executed.
> Note that names are not first-class values in Python: there is no Name type,
> and you cannot bind a name to a variable, you have to use a string.
> It's not a very close analogy, but it's the closest Python has.
I think it is a close analogy. Things refer to other things and can
be used to access those other things act like pointers. You are correct
that they are not first class items: one cannot do with them everything
one can do with other items, all one can actually do with them is create
them and dereference them. That of course is a good thing. But that
they are not first class objects does not mean that one can't or shouldn't
use the term "pointer" to describe them. That is, I don't see first-
classness as being a requirement for pointerness. The defining
characteristic of a pointer is that it, well, points to something.
It may not be appropriate way to describe Python for everybody but
it is perfectly reasonable (and even preferable) for people with
an understanding of "pointers" from some other language. And for
those people who don't then one could argue they are a clean slate
and using the word "pointer" won't hurt.
(JFTR, I am not against describing python in terms of "reference",
"binding" etc, I just object to the vehement frothing at the mouth
and insistence of one Single Truth that occurs here whenever anyone
attempts to present some alternative. As I said in another post one
size does not fit all.)
More information about the Python-list