Modifying Class Object

[Alf P. Steinbach]

* Steve Holden:
> Alf P. Steinbach wrote:
[snip]
>>
>> Since in the quoting above no reference to definition of "pointer"
>> remains: "pointer" refers to a copyable reference value as seen from the
>> Python level, in the same way as "pointer" is used by e.g. the Java
>> language spec.
>>
[snip]
>>
>> If so, then that's correct: a Python (or Java, or whatever language)
>> pointer is not necessarily directly a memory address, and furthermore id
>> is not guaranteed to reproduce the bits of a pointer value  --  which
>> might not even make sense.
>>
>> All that id does is to produce a value that uniquely identifies the
>> object pointed to, i.e. it corresponds to the pointer value, and
>> although in CPython that's simply the bits of a C pointer typed as
>> integer, in IronPython it's not.
>>
> You go too far here. What you are referring to in your bizarrely
> constructed definition above

No, it's not bizarre, it's the standard general language independent definition.

And since I'm referring to an external definition (Java) it's not mine, either. :-)


> as a pointer does not allow you to access
> the value that is "pointed to". So I fail to see why you feel its its
> introduction is necessary.

Python provides a number of ways to access the object pointed to.

Attribute access, indexing, and operators access the objects pointed to.

For example,

   x = s[0]

accesses the object that s points (refers) to.

While 'is', 'id' and assignment operate on the pointers (references) themselves.

So there's one set of language features that operate on pointers, and one set of 
language features that operate on the pointed to objects. This is so also in 
Java and C#. For example.


> Whether in CPython, Jython or IronPython the value returned by calling
> id(x) (whether x is a literal, a simple name or a more complex
> expression) is absolutely no use as an accessor: it does not give you
> access to the referenced value.

Yes, the id does not give you access to the referenced object.


> If you disagree, please write (in any implementation you like: it need
> not even be portable, though I can't imagine why ti wouldn't be) a
> Python function which takes an id() value as its argument and returns
> the value for which the id() value was provided.

No, I don't disagree with that.

It would be excessively inefficient to do, involving enumeration of all objects.


> So in your world it's unnecessary for pointers to point to anything (or
> references to refer to something)? For someone who cheerfully admits to
> being wrong from time to time (an admirable characteristic) you are
> certainly difficult to convince on this point. One wonders what further
> hand-waving will follow.

He he, "further" handwaiving: you're good at unsubstantiated allegations.

I generally strive to provide concrete examples, and you know it.

Anywyay, treating the first sentence as a genuine question: in the most likely 
interpretation it seems that you're conflating id's with pointers. An id() value 
uniquely represents a pointer (i.e., the identity of the object pointed to). It 
is not itself a pointer since it lack any pointer semantics.

For a less likely more technical interpretation, as far as I know in Python 
there's just one case of a pointer that does not point to anything, namely as 
exemplified by

    def foo():
        print( x )
        x = "whatever"

The Java equivalent would say "NullPointerException", in Python it says 
something like "unbound". Which means the same.


Cheers & hth.,

- Alf