Modifying Class Object
in [Python]
|
From: Albert van der Horst on 22 Feb 2010 08:44 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 23 Feb 2010 13:24
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 |