* Duncan Booth:
"Alf P. Steinbach" <al...@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
--
http://mail.python.org/mailman/listinfo/python-list
