Modifying Class Object

[Steve Holden]

Alf P. Steinbach wrote:
> * 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.
> 
You go too far here. What you are referring to in your bizarrely
constructed definition above 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.

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.

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.

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.

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/