Modifying Class Object

[Alf P. Steinbach]

* Steven D'Aprano:
> On Wed, 10 Feb 2010 23:02:27 +0100, Alf P. Steinbach wrote:
> 
>> 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.
> 
> Not in plain language. NullPointerException means that x is assigned to a 
> null pointer, and you have tried to follow that pointer. Unbound means 
> that x has nothing assigned to it.

No, it's the same.

    String x;
    somethingIDontRememberProbablyIo.println( x ) // Java equivalent

It's just different terminology, "NullPointerException" versus "unbound".

It's the same semantics.

Nothing substantial is changed by changing the Java message or changing the 
Python message.

The word is just a word.



> Semantically, the difference is 
> somewhat analogous to the situations:
> 
> "the president is dead, and a new president hasn't yet been appointed"
> (the office of the president is currently assigned to a dead guy)
> 
> versus
> 
> "the king has dissolved parliament and with it the office of president"
> (there is no president at all)
> 
> Now, of course we understand that in the implementation of CPython, local 
> variables are stored efficiently in slots in an array, and you can't have 
> empty slots: every address always has some bit pattern. It is very likely 
> that the CPython implementation uses a nil pointer to indicate an empty 
> slot just like Java does. The difference is that Java exposes that 
> implementation decision as part of the language specification, while 
> Python deliberately does not.

How a Python implementation implements local variables is irrelevant, except 
that since references to local variables can be copied and *live on*, be used, 
after a call, it has to work as if it uses implementation level pointers.

The notion of pointers (references) at the language level is not the same as the 
notion of pointers at the implementation level.

This is the same as the notion of integers at the Python 3.x level (unbounded 
values) is not the same as the notion of integers at the C or C# or Java level 
(depending on the Python implementation, bounded values with wrap-around or 
undefined behavior).

I.e. you're conflating two levels here.

You can perhaps more easily see that by considering an implementation of Python 
in Python, using some computed counter as object id's. It doesn't change the 
user view of copyable references. But it hides all that C pointer stuff two or 
three abstraction levels down so that it becomes meaningless to talk about it.


> It isn't an accident that the Python exception describes the *semantics* 
> of the error (x is not bound to any value) rather than the implementation 
> detail (the slot known as x has a nil pointer in it). Semantically, the 
> Python language treats the slot as empty and leaves the details of how 
> the implementation recognises empty slots as an implementation decision.
> 
> I'm just as interested by the implementation decisions made in CPython as 
> the next guy, but they don't effect the semantics of the high level 
> Python language.

Right.


> Here is a thought experiment for you:
> 
> One can imagine an implementation of Python that eschews all pointers for 
> some scheme by which objects are cleverly copied and synchronized as 
> needed. Such an implementation would still be Python, but it would be 
> entirely pointer-free.

Uhm, bad example (it wouldn't work exactly as described), but concerning what I 
think you're trying to /communicate/, that X at the Python level is not the same 
as X at the implementation level, like, 'int' at the Python 3.x level is not 
'int' in C, and like, "pointer" at the Python level is not "pointer" in C: yes.



Cheers & hth.,

- Alf