Modifying Class Object

[Alf P. Steinbach]

* Duncan Booth:
> "Alf P. Steinbach" <alfps at start.no> wrote:
> 
>> A copyable reference is a pointer. That is, a "pointer", in e.g. the
>> Java sense, 
>>   and in the general language independent sense, means a copyable
>>   reference  -- as illustrated e.g. in the Stanford computer science
>>   101 course page I 
>> referred you to earlier, with C versus Java pointers illustrated in
>> the concrete. 
> 
> The fact that C style pointers are used internally is an detail of the 
> CPython implementation.

Your statement seems pretty irrelevant to anything.

It's almost hilarious, quoting a single paragraph about how irrelevant the C 
pointer is, and responding with something like that.

Do you understand that you're restating (in the form of exemplifying) what 
you're quoting?


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

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.


> The terminology of 'objects', 'names', 'references' describes an abstract 
> machine. The Python runtime can implement it in any way it chooses so long 
> as those semantics are preserved. One implementation involves 'pointers',

It seems that you're thinking of C pointers.

That's pretty dumb since

    (1) it doesn't make sense, and

    (2) it has been mentioned in almost every article in this thread, including
        my first, and including the single paragraph that *you quoted above*,
        which was only about that, that

we're not talking about C pointers  here.

Python names denote pointers by definition (of pointer).


> but that word implies other baggage which is not a required part of the 
> model.

The word itself doesn't imply other baggage, no.

It might help to *read* what you're quoting, try to follow references, so on.


Cheers & hth.,

- Alf