Modifying Class Object

[Alf P. Steinbach]

* Duncan Booth:
> "Alf P. Steinbach" <alfps at start.no> wrote:
> 
>>> In CPython objects once created remain in the same memory location
>>> (and their id is their address). Compare that to IronPython where the
>>> objects themselves can move around in memory so they have no fixed
>>> address. Try comparing the IronPython implementation to C pointers
>>> and you'll cause a lot of confusion. e.g. someone might think the
>>> id() value is in some way related to an address.
>> Did you /read/ what you quoted?
>>
>>
>>> Ruby implements integers without using any pointers at all: there's
>>> nothing in the Python specification which prevents a Python
>>> implementation doing the same for small integers, in fact I believe
>>> it has been tried but wasn't found to improve performance.
>> All theree of your points about Python are wrong; I don't know about
>> the Ruby point. 
> 
> Would you care to expand upon your claim that my three points about Python 
> are wrong?

Sure. I already did in the article you're replying to, immediately following 
what you quote above. You snipped that which you're asking for, so I requote:


<quote>
First, the current Python language specification formally prevents the 
optimization you mention, because there's no support for binding to do anything 
but direct binding leaving object identities unchanged.

But in practice that's no big deal though: I can't imagine any code relying on 
identities of completely immutable objects.

Second, even the variant that was tried improved performance.

But it would reportedly have wreaked havoc with imperfect C code.

Third, the optimization doesn't do away with pointers. If it did then it would 
transform the language completely. The user's view is still one where names 
denote pointers.
</quote>


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.


> Are you saying that CPyhton objects move around, or that 
> IronPython objects are fixed to a single memory location or that their id 
> is related to their address?

No, I can't see how you can deduce any such connection from I wrote.

Whether objects "move around" depends on what exactly you mean by "move around", 
and given that, it may then depend on the Python implementation.

However, from the Python point of view every object has a fixed unique id, 
available via id().


> Clue here:
> 
> IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3082
> Type "help", "copyright", "credits" or "license" for more information.
>>>> x = 42
>>>> id(x)
> 43
>>>> y = 43
>>>> id(y)
> 44
>>>> z = "whatever"
>>>> id(z)
> 45
> 

I'm guessing wildly that you're trying to illustrate id's that don't correspond 
to memory addresses?

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.


Cheers & hth.,

- Alf