Modifying Class Object

[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? As defined
where? 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.

> 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. 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.
> 
> 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".
> 
> 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. They are
*not* pointers, or references.

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.

> 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.
> 
>> 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. I don't think it's unreasonable to describe that as
"hand-waving". You apparently do.

> 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.

> 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, it uniquely represents an
*object*.

> 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".

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC                 http://www.holdenweb.com/
UPCOMING EVENTS:        http://holdenweb.eventbrite.com/