From: Albert van der Horst on
In article <mailman.2343.1265860271.28905.python-list(a)python.org>,
Steve Holden <steve(a)holdenweb.com> wrote:
>Alf P. Steinbach wrote:
>> * Steve Holden:
>>> Alf P. Steinbach wrote:
>> [snip]
>>>>
>>>> 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.
>>>>
>> [snip]
>>>>
>>>> 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
>>
>> No, it's not bizarre, it's the standard general language independent
>> definition.
>>
>*The* standard general language independent definition? As defined
>where? The id() value doesn't "correspond to the pointer value", it
>corresponds to the object. Why you see the need for this indirection
>remains a mystery.

No it doesn't. If an object is garbage collected, the id() might be
recycled. At that time the id() corresponds to quite a different
object. OTOH if you kill an object in Python it is gone forever.
Of course there is a standard computer science idea of what a pointer is.
If you admit the pointer terminology, you can understand
that a pointer value is all what id() can tell us.

You seem to subsconsciously substitute "assembler language address"
for it. When someone says: "pointers are bad" what really meant is
"manipulating assembler language addresses in a high level language
is bad". (Everybody agrees, but sometimes you must use e.g. c
as sort of assembler.)
That is not the kind of pointers we're talking about here.

(I once studied algol 68, and never got confused about these
subjects anymore, recommended.)

>
>regards
> Steve
>--
>

Groetjes Albert


--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

From: NevilleDNZ on
Hi Groetjes Albert,

I spotted your comment - re: pointers
http://groups.google.com/group/comp.lang.python/msg/5c1e25919b6a74bf

On Feb 22, 11:44 pm, Albert van der Horst <alb...(a)spenarnc.xs4all.nl>
wrote:
(I once studied algol 68, and never got confused about these
> subjects anymore, recommended.)

Having used Algol68, then switching to C to discover "*" for manual
dereferencing I immediately wanted to be back using A68 again, but
alas... Then when I switched to C++ I immediately understood the
"Zen" of C++'s "&"... but still wanted to switch back to A68. Was
there ever a version with "Objects"... I saw a version with "Areas"
but have no idea what an "Area" is.

@Albert: Given the domain name "xs4all" in your email address I am
sure YOU have spotted: http://www.xs4all.nl/~jmvdveer/algol.html by
Marcel

Also: I invite you to join one of the below groups (my .sig below) and
deposit some of your Algol68 impressions....

There is also a chrestomathy site http://rosettacode.org/wiki/ALGOL_68
where you can pick out an code sample unimplemented in Algol68 and
torture test your Algol68 memories. (Be warned: Most of the easy
samples are done)

Keep in touch
NevilleDNZ
--
For Algol68-user mailinglist with archives & subscription:
* https://lists.sourceforge.net/lists/listinfo/algol68-user
To download Linux's Algol68 Compiler, Interpreter & Runtime:
* http://sourceforge.net/projects/algol68
Join the linkedin.com's Algol68 group, follow:
* http://www.linkedin.com/groups?gid=2333923