Modifying Class Object
in [Python]
|
From: Alf P. Steinbach on 10 Feb 2010 17:02 * 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. And since I'm referring to an external definition (Java) it's not mine, either. :-) > as a pointer does not allow you to access > the value that is "pointed to". So I fail to see why you feel its its > introduction is necessary. Python provides a number of ways to access the object pointed to. Attribute access, indexing, and operators access the objects pointed to. For example, x = s[0] accesses the object that s points (refers) to. While 'is', 'id' and assignment operate on the pointers (references) themselves. So there's one set of language features that operate on pointers, and one set of language features that operate on the pointed to objects. This is so also in Java and C#. For example. > Whether in CPython, Jython or IronPython the value returned by calling > id(x) (whether x is a literal, a simple name or a more complex > expression) is absolutely no use as an accessor: it does not give you > access to the referenced value. Yes, the id does not give you access to the referenced object. > If you disagree, please write (in any implementation you like: it need > not even be portable, though I can't imagine why ti wouldn't be) a > Python function which takes an id() value as its argument and returns > the value for which the id() value was provided. No, I don't disagree with that. It would be excessively inefficient to do, involving enumeration of all objects. > So in your world it's unnecessary for pointers to point to anything (or > references to refer to something)? For someone who cheerfully admits to > being wrong from time to time (an admirable characteristic) you are > certainly difficult to convince on this point. One wonders what further > hand-waving will follow. He he, "further" handwaiving: you're good at unsubstantiated allegations. I generally strive to provide concrete examples, and you know it. Anywyay, treating the first sentence as a genuine question: in the most likely interpretation it seems that you're conflating id's with pointers. An id() value uniquely represents a pointer (i.e., the identity of the object pointed to). It is not itself a pointer since it lack any pointer semantics. For a less likely more technical interpretation, as far as I know in Python there's just one case of a pointer that does not point to anything, namely as exemplified by def foo(): print( x ) x = "whatever" The Java equivalent would say "NullPointerException", in Python it says something like "unbound". Which means the same. Cheers & hth., - Alf
From: Alf P. Steinbach on 10 Feb 2010 17:09 * Ethan Furman: > Steven D'Aprano wrote: >> >> Believe me Alf, the fact that people are taking the time to try to >> argue with you instead of just kill-filing you is a compliment. > > It's a compliment I am not paying, although I am grateful to those who > are attempting to teach him. At the rate it's going, though, I don't > see myself buying any book he produces. > > Besides the arrogant attitude, he is wrong on so many things about > Python it is truly stunning. That's bullshit. I am probably wrong about many Python things, for this is so no matter the language and the practictioner, but not any that you know about. > He seems to have confidence born of > ignorance... a scary sight to see. > > In the spirit of being helpful and not just being a jerk myself: > > Alf, > > Using smileys after declaring somebody is mistaken/wrong/etc makes you > look bad. > > Not attempting to learn the language makes you look like an arrogant > idiot (case in point: passing-by-object). > > Accusing anyone and everyone that criticizes you of making ad hominem > (sp?) attacks makes you look like a whiner. > > After all is said and done - if you had a truly good grasp of Python, I > might buy your book even if you still had -- ummm -- a less than winning > presence on the mailing list; but right now your understanding is not > worth paying for. > > Hoping-this-helps-but-not-really-expecting-it-to-ly yours, It's yet another ad hominem attack, which means that you're painfully aware of supporting an untenable technical position, or supporting a clique of people. It also reflects rather badly on you. Cheers & hth., - Alf
From: Arnaud Delobelle on 10 Feb 2010 17:19 "Alf P. Steinbach" <alfps(a)start.no> writes: [...] > That's bullshit. [...] > not any that you know about. [...] > yet another ad hominem attack [...] > It also reflects rather badly on you. [...] > - Alf Alf, The above was extracted from the last post from you but I could have picked almost any of your recent endeavours. I've come to the conclusion that you're not a cute furry alien with a long nose. You're a big bad troll! -- Arnaud
From: Alf P. Steinbach on 10 Feb 2010 17:56 * Steven D'Aprano: > On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote: > >> "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. > > Python doesn't have "copyable reference values" in the Python level. It > has objects. Given s = [1] t = s # Copies reference. t[0] = 2 # Changes referenced object via copied reference. print( s ) # Checks the object via the original reference. your argument that the copied reference does not exist, is just silly. And you know it. > It seems to me that your argument is based on the premises: > > (1) that the "value" of a variable is not what 99.99% of people would > describe as the value, but is some hidden, implementation dependent > "pointer" instead; No. The Python language spec defines what value of an object means. And people use "value" with many different meanings, using Common Sense to arbitrate. It would be senseless to try to pin down a single meaning of the word "value". You're arguing against a position unrelated to mine. > (2) that "pointer" doesn't necessarily mean what 99% of people who > learned C or Pascal understand by pointer; No. But although this is "just" a terminological issue, it's worth discussing. I refuse to believe that 99% of C and Pascal programmers believe that "pointer" only refers to the pointer implementation in their language of choice. In my first article in this thread I specifically referred to the Java language specification, which says, first sentence in ยง4.3.1 in the 3.0 spec, that "The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." which is relevant to Python because Java has the same semantics, although Java "NullPointerException" is called "unbound" in Python (but this is again just terminology, not semantics). I.e., the general pointer term /can/ be used, and is used, for reference values. Only a willingness to misinterpret can cause confusion, at least when the terminology is defined, as I've done all the time. Secondly I referred (actually that was in response to you) to a Stanford University introduction to pointers, comparing four languages including Java. I didn't refer you to Wikipedia because that article seems to lack mention of reference based languages and does include a reference to an article that I wrote about pointers in C++ (now off-net), and given the noise level here it would therefore probably not help. > (3) that mangling both common English and programmers' expectations in > that fashion is somehow more accurate and more useful than using the 35 > year old term "call by object" (or "call by object reference"); No, I haven't stated any opposition to using that term; the archives show the opposite. So for the second time here you're arguing against a silly position that I do not hold. > (4) and, presumably because of some deeply-held belief that the only > parameter passing strategies that we're allowed to talk about are "call > by value" and "call by reference", no matter how much violence we do to > the concept of both value and pointer, Python and Java must be call-by- > value since they clearly aren't call-by-reference. Well that's the third time here that you're arguing against a silly position that I do not hold. > Of these, the only one that I consider value is that Python and Java are > not call-y-reference. Otherwise, I reject all these premises, Good rejection as far as 1, 3 and 4 are concerned. Regarding the term "pointer", your point 2, I strongly encourage you to seek out the sources I've referenced and quoted. For without a common language it's difficult to communicate, and if Python programmers should continue to not understand common terms then that would just further flame wars such as this thread has escalated to. Please seek out sources. Don't just take my word, instead, read e.g. what I've quoted, try out the example I've given, and so on: be critical (to your own assumptions also!). > and > consequently none of your arguments make the slightest sense to me. Well, you'd first have to examine at least one of my arguments. In this article you haven't, instead attacking a number of positions that I haven't advocated and do not hold, except for your silly denial of existence of references at the top. But that's just silly -- consider the concrete example given. > You > keep talking about Python operating on pointers. I've never used a single > pointer in 10+ years of Python coding, no matter how many times you tell > me I have. What the implementation of the Python virtual machine does is > not what I do high-level Python code, and the implementation is not the > language. Here again you're conflating things and engage in a kind of denial coupled with a correct argument. It's hard to argue against such confusion. Instead I've tried above to address your only relevant point, by a concrete example. Summing up, denying the existence of references, as you do at the top, is just silly; do consider the code example. Your points 1, 3 and 4 attack positions that I do not hold and have not advocated. Your point 2, about terminology, is important on its own. And I suggest you check out the references I've given. And read what I quoted from the language specification of a language with the same semantics as Python. Cheers & hth., - Alf
From: Steven D'Aprano on 10 Feb 2010 18:11
On Wed, 10 Feb 2010 23:02:27 +0100, Alf P. Steinbach wrote: > For a less likely more technical interpretation, as far as I know in > Python there's just one case of a pointer that does not point to > anything, namely as exemplified by > > def foo(): > print( x ) > x = "whatever" > > The Java equivalent would say "NullPointerException", in Python it says > something like "unbound". Which means the same. Not in plain language. NullPointerException means that x is assigned to a null pointer, and you have tried to follow that pointer. Unbound means that x has nothing assigned to it. Semantically, the difference is somewhat analogous to the situations: "the president is dead, and a new president hasn't yet been appointed" (the office of the president is currently assigned to a dead guy) versus "the king has dissolved parliament and with it the office of president" (there is no president at all) Now, of course we understand that in the implementation of CPython, local variables are stored efficiently in slots in an array, and you can't have empty slots: every address always has some bit pattern. It is very likely that the CPython implementation uses a nil pointer to indicate an empty slot just like Java does. The difference is that Java exposes that implementation decision as part of the language specification, while Python deliberately does not. It isn't an accident that the Python exception describes the *semantics* of the error (x is not bound to any value) rather than the implementation detail (the slot known as x has a nil pointer in it). Semantically, the Python language treats the slot as empty and leaves the details of how the implementation recognises empty slots as an implementation decision. I'm just as interested by the implementation decisions made in CPython as the next guy, but they don't effect the semantics of the high level Python language. Here is a thought experiment for you: One can imagine an implementation of Python that eschews all pointers for some scheme by which objects are cleverly copied and synchronized as needed. Such an implementation would still be Python, but it would be entirely pointer-free. -- Steven |