pointer

[Steve Holden]

"Dennis Lee Bieber" <wlfraed at ix.netcom.com> wrote ...
> On Tuesday 09 April 2002 14:45, a penguin (Henning Peters) squawked:
>
> > is there anything similar to the pointer concept from c/c++ in python?
> >
Indeed, but it's mostly transparent, and therefore hardly visible.

> > i would like to store values in two different locations. both values
> > should always be equal. the one could be a pointer on the other. is
> > this possible to do this in python?
> >
>         You first have to understand the differences between variables in
> traditional languages and variables in Python. I'm going to go back to
> "Intro to Computing 101", circa mid-70s for this.
>
>         Have you ever encounted the "mailboxes" example for
variables/memory?
> IE, the old sorting grid of boxes (you need a fixed width font here):
>
>         +--+--+--+--+--+
>         |  |  |  |  |  |
>         +--+--+--+--+--+
>         |  |  |  |  |  |
>         +--+--+--+--+--+
>
>         In the traditional language, each of those boxes has an address
> (symbolically, say, A, B, C, D, E, ...).
>
Let me say right from the start that I've always thought this analogy was
very weak for languages like Python and Icon, where assignment/rebinding
effectively implements homonyms.

It's much more effective for assembly languages, for example.

>         A statement in those languages of:      A = B
> in effect says: take what ever is in box B, make a copy of it (leaving
> the original in box B) and put the copy in box A.
>

>         In Python, the boxes do not have fixed addresses. Instead they
have
> Post-It notes stuck to the front (one note with A on it, one with B,
> etc.). The statement:   A = B
> in Python is the equivalent of taking the Post-It note with "A" on it,
> and sticking it onto the front of whatever box currently has the Post-It
> note with "B". If the box that used to have the "A" label now has no
> Post-It's attached, the contents can be garbage-collected and disposed
> of.
>
It seems to make much more sense (to me) to think of a name in a Python
program being associated with a value, and the associations being made by
binding/rebinding. I've explained this in the past in terms of namespaces
vs. object spaces.

>         Later, if you do something like:        B = 3047302
> Python creates a piece of paper with "3047302", then looks for an empty
> box (one with no Post-It attached). It places the paper inside that box,
> and moves the Post-It "B" from where ever it currently is to the newly
> filled box.
>
When a name is rebound in a Python namespace, the location of the name (and
therefore the technique used to reference the associated value) does not
change. What changes is the object reference associated with the name (in
other words, the content associated with the name). For this reason I think
this analogy is a little stretched, and does not reflect the underlying
mechanisms in a way which is helpful to the Python newbie.

>         So in effect, normal Python variables are always "pointers" --
> assignment consists of changing where the variable points, not of
> changing the contents pointed to by a variable.
>
This, if course, I have no problem with at all. That is exactly the case.
And a list and a tuple are ordered collections of pointers, and dictionaries
are collections of pointers that can be retrieved by arbitrarily
subscripting [a reference to] the object containing them.
>
>         At this point I fall dry -- some data types may perform "in place"
> modifications, leaving the "label" alone and changing the contents of
> the box, but I don't believe there is a direct procedure for doing a
> "dereferencing" operation.
>
Well, Python dereferences names automatically. When you deal with objects
such as instances and lists, it helps to remember that each list element has
properties very similar to those discussed above. Thus, changing the value
of a list element does not require any memory shuffling, since a list is
(until you start adding or removing elements from it) simply an ordered
collection of references, whose names are generated by indexing the list
object.

References to a name in an expression are automatically dereferenced. When a
name is used as the left-hand side of an assignment, however, no
dereferencing is performed.

Tuples, being immutable, do not allow any changes to their contents. Lists
and dictionaries, being mutable, do. A name which is bound to an immutable
object can, of course, easily be rebound to some other object. It can also
be completely unbound with "del".

consider the statements

    a = 3.1
    a += 7.5

The first statement binds the name "a" to a floating point value. The second
statement generates a new floating point value by adding the value
referenced by the variable's current binding, adding it to the (unnamed)
floating-point constant 7.5, and rebinding the name "a" to the resulting
floating-point value (which should be a close approximation to 10.6.

There is very little difference between this and the statements

    b = [3.1]
    b[0] += 7.5

except that what's being changed is a list element rather than an explicit
name. In this case the name "b" is bound to a list, and b[1] is bound to a
floationg-point value. Similarly

    c = {0: 3.1}
    c[0] += 7.5

will change an element of the dictionary to which the name "c" is bound,
rebinding the element to a new value. In these last two cases no name
rebinding is involved -- the name is bound to an object in the first
statement, and an element of the referenced object is rebound by the second.

Attempts to use a tuple instead of a list will raise an exception due to the
immutability of tuples.

Augmented assignments are just a little more complicated, since the
implementors of mutable types are free to *either* modify an existing value
in-place or overwrite a reference to the old value with a reference to the
new value.

In the case where the same object has been bound to multiple variables,
changes to the bindings stored inside the object are naturally seen
whichever name is used to reference the object.

What Henning seems to want is parallel binding of multiple names, so that
rebinding "a" will automatically rebind "b" as well. There are indirect ways
to achieve this end, but nothing that will work directly.

regards
 Steve