Modifying Class Object
Alf P. Steinbach
alfps at start.no
Tue Feb 9 21:02:12 CET 2010
* 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
> 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
> 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
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.,
More information about the Python-list