Modifying Class Object

[Ethan Furman]

Steve Howell wrote:
> On Feb 14, 7:11 am, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
> 
>>On Sat, 13 Feb 2010 23:45:47 -0800, Steve Howell wrote:
>>
>>>The term "pointer" is very abstract.  Please give me a concrete
>>>definition of a pointer.
>>
>>A programming language data type whose value directly specifies (or
>>"points to") another value which is stored elsewhere in the computer
>>memory.
>>
>>I quote from Wikipedia:
>>
>>http://en.wikipedia.org/wiki/Pointer_(computing)
>>
>>    [quote]
>>    A pointer is a simple, less abstracted implementation of the
>>    more abstracted reference data type
>>    [end quote]
>>
>>And later:
>>
>>    [quote]
>>    While "pointer" has been used to refer to references in
>>    general, it more properly applies to data structures whose
>>    interface explicitly allows the pointer to be manipulated
>>    (arithmetically via pointer arithmetic) as a memory
>>    address...
>>    [end quote]
>>
>>And again:
>>
>>    [quote]
>>    A memory pointer (or just pointer) is a primitive, the value
>>    of which is intended to be used as a memory address; it is said
>>    that a pointer points to a memory address. It is also said that
>>    a pointer points to a datum [in memory] when the pointer's value
>>    is the datum's memory address.
>>
>>    More generally, a pointer is a kind of reference, and it is said
>>    that a pointer references a datum stored somewhere in memory; to
>>    obtain that datum is to dereference the pointer. The feature that
>>    separates pointers from other kinds of reference is that a
>>    pointer's value is meant to be interpreted as a memory address,
>>    which is a rather 'low-level' concept.
>>    [end quote]
>>
>>
>>>A curly brace is one of these: { }
>>
>>>Pretty concrete, I hope.
>>
>>But { and } are glyphs in some typeface. Chances are that what you see,
>>and what I see, are quite different, and whatever pixels we see, the
>>compiler sees something radically different: two abstract characters
>>implemented in some concrete fashion, but that concrete fashion is a mere
>>implementation detail. They could be implemented as bytes x7b and x7d, or
>>as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows
>>what in some other system. So the *concrete* representation of the curly
>>brace varies according to the system.
>>
>>From that, it's not a difficult leap to say that Pascal's BEGIN and END
>>key words are mere alternate spellings of the abstract "open curly brace"
>>and "close curly brace" with different concrete representations, and from
>>that it's a small step to say that the INDENT and DEDENT tokens seen by
>>the Python compiler (but absent from Python source code!) are too.
>>
> 
> 
> Thanks.  It's a useful analogy; I think I understand your point
> better.  I've been bouncing around between Python and Javascript a lot
> lately, so your analogy resonates with me.  There are many times when
> I find myself simply respelling things like begin/end, and those
> respellings to me almost make me think of Python and Javascript as
> different dialects of an underlying language.  Of course, there are
> other places where the languages differ more substantively, too.
> 
> Going back to pointers vs. references, I think the key distinction
> being made is that pointers allow specific memory manipulation,
> although I think even there you're really just dealing with
> abstractions.  The address 0x78F394D2 is a little bit closer to the
> machine than, say, the 42nd element of a Python list, but they are
> both just abstractions on top of underlying machines, whether the
> machines are virtual, electronic circuits, vacuum tubes, whatever.
> You can add 6 to 42 and get the 48th object, but its Python's
> convention not to call the 48th object a memory address or expose a
> reference to it as a pointer.  If I want to pass along the reference
> to the 48th element of a list as the slot to be updated (i.e. with the
> intention to actually mutate the list itself), then I need a tuple
> like (lst, 48).
> 

I think that's the key right there -- if 48 was really a pointer, you 
wouldn't need to pass lst in as 48 would in fact be the memory address 
of the object you wanted to manipulate.

~Ethan~