Modifying Class Object
in [Python]
|
From: Steve Holden on 10 Feb 2010 23:21 Stephen Hansen wrote: > On Wed, Feb 10, 2010 at 7:49 PM, Steve Holden <steve(a)holdenweb.com > <mailto:steve(a)holdenweb.com>> wrote: > > *The* standard general language independent definition? As > defined where? > > > Wait, what happened here? > > This thread started a couple days ago; you pointed out its futility, and > even knowing better, I jumped in the deep end. When I realized the > futility, you rightly I-told-you-so'd me. > > You didn't have to pick up my slack ;) > > On Mon, Feb 8, 2010 at 6:42 PM, Steve Holden <steve(a)holdenweb.com > <mailto:steve(a)holdenweb.com>> wrote: > > Of course this won't make the slightest difference. "'When I use a > word,' said Humpty ..." Yes, but someone on the Internet is wrong, dammit, I can't go to bed yet. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: Alf P. Steinbach on 10 Feb 2010 23:49 * Steve Holden: > 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? Yes. > As defined where? For example, as I used as reference in my first posting, the Java language spec. But it has nothing specifically to do with Java. It is a basic concept in computer science, that (most) CS students learn in their *first year*. E.g. <quote src="http://cslibrary.stanford.edu/106/"> A pointer stores a reference to something. Unfortunately there is no fixed term for the thing that the pointer points to, and across different computer languages there is a wide variety of things that pointers point to. We use the term pointee for the thing that the pointer points to, and we stick to the basic properties of the pointer/pointee relationship which are true in all languages. The term "reference" means pretty much the same thing as "pointer" -- "reference" implies a more high-level discussion, while "pointer" implies the traditional compiled language implementation of pointers as addresses. For the basic pointer/pointee rules covered here, the terms are effectively equivalent. </quote> Note that that discussion at Stanford University has several Java examples + a FAQ about the application of the term "pointer" to Java (plus of course that that's specified by the language spec), so "implies ... pointers as addresses" is not smart to get too focused on. Some common sense is required. As mentioned, it is for first-year students. But anyway, this is just terminology; if you don't like the term, then invent or suggest one that you're able to grok or think others will more likely grok. > 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. The language specifies pointer semantics, that's all. You can copy and replace references. So, they quack like pointers, waddle like pointers and look like pointers: = pointers. >> 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. > > No, they access the objects. What's the difference between "access the objects" and "access the objects"? I'm not genuinely interested in how you came up with this amazing rebuttal, it was a rhetorical question only. But I note that the only difference seems to be that you don't want the objects to be referenced (pointed to) by anything, removing that bit of text, which would make it a bit problematic to apply /any/ operation... > In the IronPython implementation, for > example, it has already been shown quite clearly that the id value is > simply an attribute of the object, whose values are incremented by one > for each new object. Please demonstrate how that is relevant to whatever you're arguing. >> For example, >> >> x = s[0] >> >> accesses the object that s points (refers) to. > > It accesses (the first element of) the object bound to the name "s". Yes. >> While 'is', 'id' and assignment operate on the pointers (references) >> themselves. >> > The 'is' operator is a simple test for equality of ids of the objects > resulting from the evaluation of two expressions. The expressions can be > literals, simple names, or any other valid Python expression. Yes. > They are *not* pointers, or references. Simple demonstration that they're references (have reference semantics): s = ["A"] t = s # Copies the reference. t[0] = "B" # Changes the referenced object via the reference copy. print( s ) # Inspects object (now changed) via original reference. It's pretty hard to argue seriously against this without committing a number of fallacies. Denial is of course easy, and you've done that, but it's at best just childish. > id() simply returns a unique value identifying a particular object. In > CPython, where objects do not migrate in memory once created, the memory > address of the object is used. In IronPython each object is assigned an > id when it is created, and that value is stored as an attribute. Yes. >> 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. >> > Well at least we have found one aspect of Python we agree on. Oh, good. :-) >>> 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. >> > Good. > >> 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 am simply pointing out that to make your point you are relying on > abstractions which increasingly diverge from the reality of the Python > language. On the contrary, the closest abstraction to reference semantics is reference semantics. No special cases needed. No extraneous conceptual ballast. > I don't think it's unreasonable to describe that as > "hand-waving". You apparently do. Yes and no. Regarding what you write now, that is regarding what people (who don't have set positions) find easier to grasp: discussing that is necessarily handwaiving, but to the same degree no matter which side you argue. Unless one applies statistics. So by your own argument you're handwaiving. On the other hand, regarding what you wrote earlier you implied a history of handwaiving from me. You would be unable to give examples of that. But above you present an argument about IronPython which suggest some unspecified contradiction with something unspecified (to get to the implied contradiction a reader would have to form a picture that would be misrepresenting me), and *that* is an example of handwaiving, diversion and misrepresentation -- which I didn't have to look far to find... >> I generally strive to provide concrete examples, and you know it. >> > Again with the mind-reading: you appear to have convinced yourself that > you are an authority on what I know. What on Earth are you babbling about now? I say what I do. You therefore think I'm reading your mind? Hello. Get a grip. >> 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. >> > No, it doesn't uniquely represent a pointer, Denial is just stupid, sorry. > it uniquely represents an *object*. Yes, and that implies that it also uniquely represents a pointer to the object. If nothing else you could take the address of the object and have a direct correspondence (one-to-one mapping) with the id value, contradicting your statement. But that's just one concrete example, it doesn't capture the general idea of an abstract pointer: it only shows that your statement is a self-contradiction, i.e., fallacious. >> 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. >> > Be careful when comparing static and dynamic languages. Java, being a > static language, has no equivalent to Python's NameError and > AttributeError, which both represent situations in which no object has > been bound to a name. In those cases it isn't that the name exists and > is bound to a "null pointer", it's simply that the name doesn't exist. > So there is no "copyable reference value". Yes, you have point there (the first so far, I must add, since this is at the end of the article!). And it is a good but subtle point that I was a bit hesitant to mention. But since you've let that cat out of ze bag, Java and Python differ in what dangerous name/pointer features they offer: IIRC Java allows a name to become "unbound" by assigning nullpointer, i.e. an extra path to that dangerous nullpointer/unbound state, while Python allows a name to become non-existent via del, i.e. an extra path to that dangerous non-existence. Still, the unbound/nullpointer state is the same, with the same effect. And that's quite suggestive. Cheers & hth., - Alf
From: Dino Viehland on 10 Feb 2010 23:58 Steve wrote: > id() simply returns a unique value identifying a particular object. In > CPython, where objects do not migrate in memory once created, the > memory > address of the object is used. In IronPython each object is assigned an > id when it is created, and that value is stored as an attribute. Just a point of clarification: In IronPython ids are lazily assigned upon a call to the id(). They're actually fairly expensive to create because the ids need to be maintained by a dictionary which uses weak references. > >> 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. Just for fun this works in IronPython 2.6: >>> import clr >>> clr.AddReference('Microsoft.Dynamic') >>> from Microsoft.Scripting.Runtime import IdDispenser >>> x = object() >>> id(x) 43 >>> IdDispenser.GetObject(43) <object object at 0x000000000000002B> >>> IdDispenser.GetObject(43) is x True Please, please, no one ever use this code! I do generally agree with the sentiment that id is object identity and in way related to pointers though.
From: Alf P. Steinbach on 11 Feb 2010 00:01 * Steve Holden: > Alf P. Steinbach wrote: >> * Steve Holden: >>> So now the whole thing boils down to "Alf against the world"? The >>> reminds me of the story about the woman who went to see her son qualify >>> from his basic army training. When asked what she thought of the parade >>> she said it was very nice, but that "everyone but our Alf was out of >>> step". >> Considering your frequent ad hominem attacks (and this is yet one more), >> you seem to think that social coercion works well for establishing >> engineering solutions or scientific truth. >> >> That's a misconception. >> > So now I understand neither engineering nor science? I find that > assertion offensive, though unsurprising. > >> Social matters and matters of engineering or science are different things. >> > I am hardly ignorant of that, as you should know from my many past > writings on both aspects of Python usage. You are attempting to teach > your grandmother to suck eggs. >>> I am unsure at this stage what it would take to convince you that you >>> are not only wrong about several important aspects of Python but also >>> wrong-headed. >> You might start by starting a thread about one such thing; I'll correct >> you if you're wrong about something I know, or if you demonstrate that >> I'm wrong about something, then I'll be happy to learn something, as >> always. >> >> It would be a nice change from your extreme focus on my person, if you >> could manage to discuss something technical. >> > See below. >>> Whenever anyone points out any aspect of your behavior >>> which is unacceptable or ignorant you trot out this accusation that >>> people are making "ad hominem attacks" as though commenting on aspects >>> of your personality is an attempt to undermine your arguments. >> That's an ad hominem attack, albeit a pretty silly one. >> > [facepalm] > >> Your behavior, with ad hominem, coercion, insinuations, >> misrepresentations and so forth the basic ingredients, is completely >> unacceptable to me, by the way. >> >> It's like a bully in the schoolyard. >> > I am attempting to persuade, not to coerce. >>> It isn't. The two are orthogonal. Your arguments are wrong *and* you are >>> behaving like a pratt. A change in either one of these aspects would >>> improve matters, but each seems as unlikely as the other. >>> >>>> It also reflects rather badly on you. >>> Sigh. We're all out of step again, obviously. >> If you had any argument that held regarding the technical, then I think >> you (and I mean the singular you) would have tried it by now. >> >> But instead, you engage in this bullying behavior. >> > My (technical) views on your insistence that Python's semantics require > the use of pointers to explain them is ongoing elsewhere, and remains > open for you to refute. > > In this particular part of the thread I am attempting, unsuccessfully, > to convince you that a change in *your* behavior would lead to less > hostility directed towards the way you present your ideas. > > You apparently feel it is quite acceptable to tell people to "learn to > read", I have not used that expression. However I have suggest and emphasized that it might help to *read* whatever one quotes, when the quoted material (such as one paragraph) has not been read. Telling someone to "learn to read" is a Steve Holden'sk way to imply that the person is an ignoramus who hasn't bothered to learn to read. Telling a person to read something that's obviously not been read is quite another matter. So, you are misrepresenting -- again -- and in a quite revealing way, sorry. > and calling their assertions "bullshit", Yes, in this group, but only for personal attacks. Such as yours. I think I've shown extreme restraint in the face of bullying from you and some followers, and calling the insinuations bullshit is quite mild. > but when we try to point > out aspects of your behavior that are either undesirable or unacceptable > we are indulging in "ad hominem attacks". That is an untrue and extremely misleading description of what you've been doing. > In your terms, your accusing me of bullying behavior is an ad hominem > attack on me, so I won't bother to respond further. You're complaining about the person you're hitting saying clearly what you did. If some truthful words about bullying can get you straight I'm for it. Even if it means getting down to your level (and yes, I did). Cheers, - Alf
From: Steven D'Aprano on 11 Feb 2010 00:46
On Wed, 10 Feb 2010 23:56:36 +0100, Alf P. Steinbach wrote: > * 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. You keep making a habit of pretending that you know what other people are thinking, accusing them of lying for having an opinion that differs from yours, and of deliberately making silly arguments that the poster (in this case, me) knows is untrue. It is an obnoxious, trolling habit. Please stop it. I don't "know" it is a silly argument, because I don't accept your givens. Specifically: s = [1] t = s # Binds the name t to the object bound to the name s. t[0] = 2 # Changes the object bound to the name t print(s) # Checks the object via the original name. Notice that your version describes what happens according to some implementation, below the level of the Python virtual machine. My version describes what happens at the level of high-level Python code, which is the defined semantics of the language. It makes no assumptions about the implementation, completely unlike yours which is entirely implementation- specific. My description is equally valid whether Python is being executed by the CPython virtual machine on an Intel-compatible processor, or hand-simulated with pencil and paper, or something completely different. Yours is not. I describe the high-level language, you describe one implementation. Neither view is *wrong*, per se, but one describes the semantics of the language while the other describes the implementation. The first paragraph of the Python docs about the execution model says: "NAMES REFER TO OBJECTS [emphasis added]. Names are introduced by name binding operations. Each occurrence of a name in the program text refers to the binding of that name established in the innermost function block containing the use." http://docs.python.org/reference/executionmodel.html Apart from the use of the generic English term "refers to" (and similar), you will find *nothing* about pointers in this. That's because pointers are not a part of the high-level behaviour of Python. See also: http://docs.python.org/reference/simple_stmts.html#assignment-statements where you will also not find the word "pointer" used to describe any high- level Python feature, or used in relation to assignment. -- Steven |