Modifying Class Object

[Alf P. Steinbach]

* Steve Holden:
> Alf P. Steinbach wrote:
>> * 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.
>>
> *The* standard general language independent definition?

Yes.


> As defined where?

For example, as I used as reference in my first posting, the Java language spec. 
  But it has nothing specifically to do with Java. It is a basic concept in 
computer science, that (most) CS students learn in their *first year*.

E.g.

<quote src="http://cslibrary.stanford.edu/106/">
A pointer stores a reference to something. Unfortunately there is no fixed term 
for the thing that the pointer points to, and across different computer 
languages there is a wide variety of things that pointers point to. We use the 
term pointee for the thing that the pointer points to, and we stick to the basic 
properties of the pointer/pointee relationship which are true in all languages. 
The term "reference" means pretty much the same thing as "pointer" -- 
"reference" implies a more high-level discussion, while "pointer" implies the 
traditional compiled language implementation of pointers as addresses. For the 
basic pointer/pointee rules covered here, the terms are effectively equivalent.
</quote>

Note that that discussion at Stanford University has several Java examples + a 
FAQ about the application of the term "pointer" to Java (plus of course that 
that's specified by the language spec), so "implies ... pointers as addresses" 
is not smart to get too focused on. Some common sense is required.

As mentioned, it is for first-year students.

But anyway, this is just terminology; if you don't like the term, then invent or 
suggest one that you're able to grok or think others will more likely grok.


> The id() value doesn't "correspond to the pointer value", it
> corresponds to the object. Why you see the need for this indirection
> remains a mystery.

The language specifies pointer semantics, that's all.

You can copy and replace references.

So, they quack like pointers, waddle like pointers and look like pointers: = 
pointers.


>> 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.
> 
> No, they access the objects.

What's the difference between "access the objects" and "access the objects"?

I'm not genuinely interested in how you came up with this amazing rebuttal, it 
was a rhetorical question only.

But I note that the only difference seems to be that you don't want the objects 
to be referenced (pointed to) by anything, removing that bit of text, which 
would make it a bit problematic to apply /any/ operation...


> In the IronPython implementation, for
> example, it has already been shown quite clearly that the id value is
> simply an attribute of the object, whose values are incremented by one
> for each new object.

Please demonstrate how that is relevant to whatever you're arguing.


>> For example,
>>
>>   x = s[0]
>>
>> accesses the object that s points (refers) to.
> 
> It accesses (the first element of) the object bound to the name "s".

Yes.


>> While 'is', 'id' and assignment operate on the pointers (references)
>> themselves.
>>
> The 'is' operator is a simple test for equality of ids of the objects
> resulting from the evaluation of two expressions. The expressions can be
> literals, simple names, or any other valid Python expression.

Yes.


> They are *not* pointers, or references.

Simple demonstration that they're references (have reference semantics):

   s = ["A"]
   t = s             # Copies the reference.
   t[0] = "B"        # Changes the referenced object via the reference copy.
   print( s )        # Inspects object (now changed) via original reference.

It's pretty hard to argue seriously against this without committing a number of 
fallacies.

Denial is of course easy, and you've done that, but it's at best just childish.


> id() simply returns a unique value identifying a particular object. In
> CPython, where objects do not migrate in memory once created, the memory
> address of the object is used. In IronPython each object is assigned an
> id when it is created, and that value is stored as an attribute.

Yes.


>> 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.
>>
> Well at least we have found one aspect of Python we agree on.

Oh, good. :-)


>>> 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.
>>
> Good.
> 
>> 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 am simply pointing out that to make your point you are relying on
> abstractions which increasingly diverge from the reality of the Python
> language.

On the contrary, the closest abstraction to reference semantics is reference 
semantics.

No special cases needed.

No extraneous conceptual ballast.



> I don't think it's unreasonable to describe that as
> "hand-waving". You apparently do.

Yes and no.

Regarding what you write now, that is regarding what people (who don't have set 
positions) find easier to grasp: discussing that is necessarily handwaiving, but 
to the same degree no matter which side you argue. Unless one applies 
statistics. So by your own argument you're handwaiving.

On the other hand, regarding what you wrote earlier you implied a history of 
handwaiving from me.

You would be unable to give examples of that.

But above you present an argument about IronPython which suggest some 
unspecified contradiction with something unspecified (to get to the implied 
contradiction a reader would have to form a picture that would be 
misrepresenting me), and *that* is an example of handwaiving, diversion and 
misrepresentation  --  which I didn't have to look far to find...


>> I generally strive to provide concrete examples, and you know it.
>>
> Again with the mind-reading: you appear to have convinced yourself that
> you are an authority on what I know.

What on Earth are you babbling about now? I say what I do. You therefore think 
I'm reading your mind? Hello. Get a grip.


>> 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.
>>
> No, it doesn't uniquely represent a pointer,

Denial is just stupid, sorry.


> it uniquely represents an *object*.

Yes, and that implies that it also uniquely represents a pointer to the object. 
If nothing else you could take the address of the object and have a direct 
correspondence (one-to-one mapping) with the id value, contradicting your 
statement. But that's just one concrete example, it doesn't capture the general 
idea of an abstract pointer: it only shows that your statement is a 
self-contradiction, i.e., fallacious.


>> 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.
>>
> Be careful when comparing static and dynamic languages. Java, being a
> static language, has no equivalent to Python's NameError and
> AttributeError, which both represent situations in which no object has
> been bound to a name. In those cases it isn't that the name exists and
> is bound to a "null pointer", it's simply that the name doesn't exist.
> So there is no "copyable reference value".

Yes, you have point there (the first so far, I must add, since this is at the 
end of the article!). And it is a good but subtle point that I was a bit 
hesitant to mention. But since you've let that cat out of ze bag, Java and 
Python differ in what dangerous name/pointer features they offer: IIRC Java 
allows a name to become "unbound" by assigning nullpointer, i.e. an extra path 
to that dangerous nullpointer/unbound state, while Python allows a name to 
become non-existent via del, i.e. an extra path to that dangerous non-existence.

Still, the unbound/nullpointer state is the same, with the same effect.

And that's quite suggestive.


Cheers & hth.,

- Alf