Modifying Class Object
in [Python]
|
From: alex23 on 11 Feb 2010 01:10 "Alf P. Steinbach" <al...(a)start.no> wrote: > 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. Ad hominem. > So, you > are misrepresenting -- again -- and in a quite revealing way, sorry. Ad hominem. > Yes, in this group, but only for personal attacks. Such as yours. Ad hominem. > 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. Ad hominem. > That is an untrue and extremely misleading description of what you've been doing. Ad hominem. > Even if it means getting down to your level (and yes, I did). Ad hominem. So the real lesson you're trying to impart is to do as you say and not as you do?
From: Alf P. Steinbach on 11 Feb 2010 01:37 * Steven D'Aprano: > 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, No, that is untrue, I do neither know nor pretend to know what other people are thinking. But I do know that you know some elementary things, such as understanding what the code above does. I do not by that mean that you don't also understand far more advanced things :-), just that I'm fairly ~100% sure that you do understand the code above. > accusing them of lying for having an opinion that differs from > yours, That is untrue. [snip] > 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. Consider just the assert( t is not s ) t = s Does this change anything at all in the computer's memory? If it doesn't, then it has no effect whatsoever. But since it does have an effect, a memory change has been effected. You describe that memory change as that t has been "bound" to the same object as s. By which you mean that henceforth, until the next assignment to t, t *refers* to the same object as s. That explanation in terms of "refers" is necessary. No beginner knows what it means that a name is "bound" to something means, until it's been explained. The explanation is necessarily in terms of "refers to". When something A refers to something B, then by definition A is a *reference* to B. Anyway, you have changed which object t refers to, by changing memory contents so that t now refers to the same object as s. Effectively, by making t refer to the same object as s, by all measures of reference equality (which is just, do they refer to same object?) you have *copied* the s reference to t. For if you haven't, then t necessarily refers to something else. So the memory change, whatever it was, involved an effective copying of a reference, in memory. And that copying of a reference, in memory, implies a copyable reference. Going the other way, copying of references very directly implies binding. No need for the long logic chain above. So copying of references is in my view much more powerful as a model of what goes on, yielding immediate conclusions, avoiding special case rules, and being very suitable for visualization. Not the least, it's more powerful because in order to explain "bind" you need "refer" and "reference", so the "bind" view involves more, violating Occam's. But given the explanation in terms of "refer" and "reference" you do not need "bind", so it's less, it's simpler -- and it's easier to visualize. --- Anyway, there is more practical way to look at it. Say that you're going to implement a linked list. The functionality required for that is exactly that of general pointers. But a linked list can be implemented in Python, using names (attributes) as pointers. And since that works, without having to do anything extra in order to "implement" pointers in terms of names, but just using those names directly, those names necessarily have the functionality of general pointers. > 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. Well, apart from... As you say. > 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. Yes, that's right. It does not mean that such a description is invalid. It only means that common sense needs to be applied, and that the urge to misinterpret needs to be suppressed. I don't think those are problems for novices. But still a better term than "pointer" would be nice, and I guess "reference" is it, as suggested by the course material I linked to. Cheers & hth., - Alf
From: Alf P. Steinbach on 11 Feb 2010 01:46 * alex23: > "Alf P. Steinbach" <al...(a)start.no> wrote: >> 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. > > Ad hominem. > >> So, you >> are misrepresenting -- again -- and in a quite revealing way, sorry. > > Ad hominem. > >> Yes, in this group, but only for personal attacks. Such as yours. > > Ad hominem. > >> 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. > > Ad hominem. > >> That is an untrue and extremely misleading description of what you've been doing. > > Ad hominem. > >> Even if it means getting down to your level (and yes, I did). > > Ad hominem. > > So the real lesson you're trying to impart is to do as you say and not > as you do? Well, I don't think any of you guys would hold out as long as I did. I think it's Not Nice to get personal. But there's a limit, one can't just ignore punches every day, and you're right, the above from me was ad hominem all the way (well, except that it doesn't concern any technical discussion, and that I'm not injecting noise but responding to such and trying to reduce it in the future, but still). Cheers, - Alf
From: I V on 11 Feb 2010 02:38 On Thu, 11 Feb 2010 07:37:35 +0100, Alf P. Steinbach wrote: > * Steven D'Aprano: >> 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. > > Consider just the > > assert( t is not s ) > > t = s > > Does this change anything at all in the computer's memory? > > If it doesn't, then it has no effect whatsoever. > > But since it does have an effect, a memory change has been effected. I don't think your disagreeing with Steven here - by talking about "the computers memory," it's clear that you are talking about the details of an implementation of python, not the semantics of python itself. Unless, of course, you are under the misapprehension that "the computer's memory" is relevant to the python language, rather than the particular implementation. Python itself has nothing to do with "computers" or "memory"; these are mere implementation details.
From: Alf P. Steinbach on 11 Feb 2010 03:09
* I V: > On Thu, 11 Feb 2010 07:37:35 +0100, Alf P. Steinbach wrote: >> * Steven D'Aprano: >>> 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. >> Consider just the >> >> assert( t is not s ) >> >> t = s >> >> Does this change anything at all in the computer's memory? >> >> If it doesn't, then it has no effect whatsoever. >> >> But since it does have an effect, a memory change has been effected. > > I don't think your disagreeing with Steven here - by talking about "the > computers memory," it's clear that you are talking about the details of > an implementation of python, not the semantics of python itself. Unless, > of course, you are under the misapprehension that "the computer's memory" > is relevant to the python language, rather than the particular > implementation. Python itself has nothing to do with "computers" or > "memory"; these are mere implementation details. You know, the programming language that doesn't need computers: Python. :-) Cheers, - Alf (not sure how to read your posting, but it's funny anyhow) |