Re: Apology Re: Is 'everything' a refrence or isn't it?
Alex Martelli wrote: > Ben Sizer <[EMAIL PROTECTED]> wrote: >... > > assignment semantics that differ from languages such as C++ and Java, > > not the calling mechanism. In C++, assignment means copying a value. In > > Python, assignment means reassigning a reference. > > And in Java, it means just the same as in Python (with some unfortunate > exceptions, in Java, for elementary types such as int -- but for all > normal types, the meaning of assignment and parameter passing is just > the same in Java as in Python). > > Considering that Java may have become the language most used for first > courses in programming, it's unfortunate to propagate disinformation > about its assignment semantics differing from Python's -- it will > confuse people who know Java, and there are many of those. Yes, my mistake - I forgot that Java reseats object references rather than copying object values. (I'm a C++ person at heart.) Personally I think this is a reason why Java is a poor language to teach beginners, as it's stuck between low level semantics from C and high level semantics like those of Python. It doesn't provide a very consistent view, meaning you're bound to get confused no matter what second language you start to learn. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Mike Meyer wrote: > This is where we disagree. I think their understanding of references > is dead on. What's broken is their understanding of what variables are > and what assignments mean. Once you fix that, the rest falls into > place. > > (Steven D'Aprano wrote:) > > The fact that call by object is unfamiliar is precisely its advantage. > > Instead of people jumping to conclusions about what it means, like they do > > with "reference", they will stop and think and if need be look for further > > information about Python's object model. At the very least, they won't say > > "Everything in Python is a reference, so this should work, but it > > doesn't". > > What you're advocating is intentionally misleading people to deal with > a symptom. I'd rather give them enough truth to deal with the disease. I agree completely. I have personally "converted" around a half-dozen or so coworkers to Python over the course of the last three or four years. The conversion takes place in stages. Usually, I have written a small script for them which they later want to enhance, so they come to me for a tutorial session. My initial 5-10 minute tutorial starts off with an explanation of name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print b; b=42; print a, b". Note that this also demonstrates the dynamic nature of Python typing -- 'b' is not restricted to being bound to a list merely because the first time it was bound was to a list. Once they have that down, I describe "immutable" vs. "mutable". I start off by explaining that of course integers are immutable because you cannot change 1 into 5. I then explain (with examples) that, additionally, in the language, strings are immutable (which does NOT mean you cannot usefully manipulate them, just that, for example, in "x = 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a completely new string. (The attempted example x[1] = "d" also gets them used to the exception reporting mechanism.) I actually spend more time (of this 10 minutes!) on "immutable" vs. "mutable" (including ancillary lessons) than I spend on anything else. After showing that strings are immutable, I then explain that tuples are a sort of immutable list. This usually elicits the question of why such a thing is needed, which is a great segue into a minute or so spent on dictionaries and their keys. (Dictionaries can occupy additional time if the student recognizes that they are a good fit for a pressing need.) Only about the last 30 seconds or so is spent on function calling. I explain that all parameters are passed by reference, but that OBVIOUSLY, if the called function wants to alter the caller's object, the referenced object must be mutable, because, JUST AS WITH C POINTERS, the pointer to the object is passed by making a copy of it on the stack, so there is no way that the callee can directly alter the caller's own pointer to the object. After this lesson, I send them back to look at their script with information about the online docs and a standing offer to help them over any rough spots. NOT ONE PERSON has ever been confused about the parameter passing. I have only given these tutorials to accomplished programmers, so my opinion about teaching newbies is not as well-formed, but for a C/C++/assembler programmer, the REAL question about parameters is "What is pushed onto the stack?" They are capable of a high level of abstraction, so all they really want to know "Is a COPY of the object passed on the stack, or is a POINTER to the object passed on the stack?" With such an accomplished student, if the teacher described Python's parameter passing as anything but "call by reference", it would lead to confusion, and, ultimately, disrespect for the teacher. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Mike Meyer wrote: > This is where we disagree. I think their understanding of references > is dead on. What's broken is their understanding of what variables are > and what assignments mean. Once you fix that, the rest falls into > place. > > (Steven D'Aprano wrote:) > > The fact that call by object is unfamiliar is precisely its advantage. > > Instead of people jumping to conclusions about what it means, like they do > > with "reference", they will stop and think and if need be look for further > > information about Python's object model. At the very least, they won't say > > "Everything in Python is a reference, so this should work, but it > > doesn't". > > What you're advocating is intentionally misleading people to deal with > a symptom. I'd rather give them enough truth to deal with the disease. I agree completely. I have personally "converted" around a half-dozen or so coworkers to Python over the course of the last three or four years. The conversion takes place in stages. Usually, I have written a small script for them which they later want to enhance, so they come to me for a tutorial session. My initial 5-10 minute tutorial starts off with an explanation of name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print b; b=42; print a, b". Note that this also demonstrates the dynamic nature of Python typing -- 'b' is not restricted to being bound to a list merely because the first time it was bound was to a list. Once they have that down, I describe "immutable" vs. "mutable". I start off by explaining that of course integers are immutable because you cannot change 1 into 5. I then explain (with examples) that, additionally, in the language, strings are immutable (which does NOT mean you cannot usefully manipulate them, just that, for example, in "x = 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a completely new string. (The attempted example x[1] = "d" also gets them used to the exception reporting mechanism.) I actually spend more time (of this 10 minutes!) on "immutable" vs. "mutable" (including ancillary lessons) than I spend on anything else. After showing that strings are immutable, I then explain that tuples are a sort of immutable list. This usually elicits the question of why such a thing is needed, which is a great segue into a minute or so spent on dictionaries and their keys. (Dictionaries can occupy additional time if the student recognizes that they are a good fit for a pressing need.) Only about the last 30 seconds or so is spent on function calling. I explain that all parameters are passed by reference, but that OBVIOUSLY, if the called function wants to alter the caller's object, the referenced object must be mutable, because, JUST AS WITH C POINTERS, the pointer to the object is passed by making a copy of it on the stack, so there is no way that the callee can directly alter the caller's own pointer to the object. After this lesson, I send them back to look at their script with information about the online docs and a standing offer to help them over any rough spots. NOT ONE PERSON has ever been confused about the parameter passing. I have only given these tutorials to accomplished programmers, so my opinion about teaching newbies is not as well-formed, but for a C/C++/assembler programmer, the REAL question about parameters is "What is pushed onto the stack?" They are capable of a high level of abstraction, so all they really want to know "Is a COPY of the object passed on the stack, or is a POINTER to the object passed on the stack?" With such an accomplished student, if the teacher described Python's parameter passing as anything but "call by reference", it would lead to confusion, and, ultimately, disrespect for the teacher. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Mike Meyer wrote: > This is where we disagree. I think their understanding of references > is dead on. What's broken is their understanding of what variables are > and what assignments mean. Once you fix that, the rest falls into > place. > > (Steven D'Aprano wrote:) > > The fact that call by object is unfamiliar is precisely its advantage. > > Instead of people jumping to conclusions about what it means, like they do > > with "reference", they will stop and think and if need be look for further > > information about Python's object model. At the very least, they won't say > > "Everything in Python is a reference, so this should work, but it > > doesn't". > > What you're advocating is intentionally misleading people to deal with > a symptom. I'd rather give them enough truth to deal with the disease. I agree completely. I have personally "converted" around a half-dozen or so coworkers to Python over the course of the last three or four years. The conversion takes place in stages. Usually, I have written a small script for them which they later want to enhance, so they come to me for a tutorial session. My initial 5-10 minute tutorial starts off with an explanation of name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print b; b=42; print a, b". Note that this also demonstrates the dynamic nature of Python typing -- 'b' is not restricted to being bound to a list merely because the first time it was bound was to a list. Once they have that down, I describe "immutable" vs. "mutable". I start off by explaining that of course integers are immutable because you cannot change 1 into 5. I then explain (with examples) that, additionally, in the language, strings are immutable (which does NOT mean you cannot usefully manipulate them, just that, for example, in "x = 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a completely new string. (The attempted example x[1] = "d" also gets them used to the exception reporting mechanism.) I actually spend more time (of this 10 minutes!) on "immutable" vs. "mutable" (including ancillary lessons) than I spend on anything else. After showing that strings are immutable, I then explain that tuples are a sort of immutable list. This usually elicits the question of why such a thing is needed, which is a great segue into a minute or so spent on dictionaries and their keys. (Dictionaries can occupy additional time if the student recognizes that they are a good fit for a pressing need.) Only about the last 30 seconds or so is spent on function calling. I explain that all parameters are passed by reference, but that OBVIOUSLY, if the called function wants to alter the caller's object, the referenced object must be mutable, because, JUST AS WITH C POINTERS, the pointer to the object is passed by making a copy of it on the stack, so there is no way that the callee can directly alter the caller's own pointer to the object. After this lesson, I send them back to look at their script with information about the online docs and a standing offer to help them over any rough spots. NOT ONE PERSON has ever been confused about the parameter passing. I have only given these tutorials to accomplished programmers, so my opinion about teaching newbies is not as well-formed, but for a C/C++/assembler programmer, the REAL question about parameters is "What is pushed onto the stack?" They are capable of a high level of abstraction, so all they really want to know "Is a COPY of the object passed on the stack, or is a POINTER to the object passed on the stack?" With such an accomplished student, if the teacher described Python's parameter passing as anything but "call by reference", it would lead to confusion, and, ultimately, disrespect for the teacher. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Mike Meyer wrote: > This is where we disagree. I think their understanding of references > is dead on. What's broken is their understanding of what variables are > and what assignments mean. Once you fix that, the rest falls into > place. > > (Steven D'Aprano wrote:) > > The fact that call by object is unfamiliar is precisely its advantage. > > Instead of people jumping to conclusions about what it means, like they do > > with "reference", they will stop and think and if need be look for further > > information about Python's object model. At the very least, they won't say > > "Everything in Python is a reference, so this should work, but it > > doesn't". > > What you're advocating is intentionally misleading people to deal with > a symptom. I'd rather give them enough truth to deal with the disease. I agree completely. I have personally "converted" around a half-dozen or so coworkers to Python over the course of the last three or four years. The conversion takes place in stages. Usually, I have written a small script for them which they later want to enhance, so they come to me for a tutorial session. My initial 5-10 minute tutorial starts off with an explanation of name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print b; b=42; print a, b". Note that this also demonstrates the dynamic nature of Python typing -- 'b' is not restricted to being bound to a list merely because the first time it was bound was to a list. Once they have that down, I describe "immutable" vs. "mutable". I start off by explaining that of course integers are immutable because you cannot change 1 into 5. I then explain (with examples) that, additionally, in the language, strings are immutable (which does NOT mean you cannot usefully manipulate them, just that, for example, in "x = 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a completely new string. (The attempted example x[1] = "d" also gets them used to the exception reporting mechanism.) I actually spend more time (of this 10 minutes!) on "immutable" vs. "mutable" (including ancillary lessons) than I spend on anything else. After showing that strings are immutable, I then explain that tuples are a sort of immutable list. This usually elicits the question of why such a thing is needed, which is a great segue into a minute or so spent on dictionaries and their keys. (Dictionaries can occupy additional time if the student recognizes that they are a good fit for a pressing need.) Only about the last 30 seconds or so is spent on function calling. I explain that all parameters are passed by reference, but that OBVIOUSLY, if the called function wants to alter the caller's object, the referenced object must be mutable, because, JUST AS WITH C POINTERS, the pointer to the object is passed by making a copy of it on the stack, so there is no way that the callee can directly alter the caller's own pointer to the object. After this lesson, I send them back to look at their script with information about the online docs and a standing offer to help them over any rough spots. NOT ONE PERSON has ever been confused about the parameter passing. I have only given these tutorials to accomplished programmers, so my opinion about teaching newbies is not as well-formed, but for a C/C++/assembler programmer, the REAL question about parameters is "What is pushed onto the stack?" They are capable of a high level of abstraction, so all they really want to know "Is a COPY of the object passed on the stack, or is a POINTER to the object passed on the stack?" With such an accomplished student, if the teacher described Python's parameter passing as anything but "call by reference", it would lead to confusion, and, ultimately, disrespect for the teacher. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Ben Sizer <[EMAIL PROTECTED]> wrote: ... > assignment semantics that differ from languages such as C++ and Java, > not the calling mechanism. In C++, assignment means copying a value. In > Python, assignment means reassigning a reference. And in Java, it means just the same as in Python (with some unfortunate exceptions, in Java, for elementary types such as int -- but for all normal types, the meaning of assignment and parameter passing is just the same in Java as in Python). Considering that Java may have become the language most used for first courses in programming, it's unfortunate to propagate disinformation about its assignment semantics differing from Python's -- it will confuse people who know Java, and there are many of those. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Thu, 05 Jan 2006 11:17:44 -0500, Mike Meyer wrote: >> While telling them that "You can't do call by reference because Python >> is call by object" may be correct, > Good to see you finally concede it. I'm not conceeding anything, because I never said otherwise. In particular, I still claim that Pythons behavior when passing objects as parameters is identical to call-by-reference for all the objects that you can generate in Python. >> So they're liable to run into the same problem in a >> different context - like the one the OP had. > That doesn't follow. You're right. That observation is based on watching people repeatedly beat their head against the difference between variable assignment in other languages and name binding in object-based languages. Until you get that difference into their heads, they're going to have problems. What you use to describe the parameter passing mechanism is immaterial to the real problem. > The problem isn't that talk about references is *wrong*, but that it is > misleading. Where "reference" is being used just as a generic term, it is > barely acceptable, but any time it is used in a context where it could be > misconstrued is dangerous precisely because people WILL misunderstand it, > because they *think* they know what references (assignment, call by > reference, whatever) means in this context. This is where we disagree. I think their understanding of references is dead on. What's broken is their understanding of what variables are and what assignments mean. Once you fix that, the rest falls into place. > The fact that call by object is unfamiliar is precisely its advantage. > Instead of people jumping to conclusions about what it means, like they do > with "reference", they will stop and think and if need be look for further > information about Python's object model. At the very least, they won't say > "Everything in Python is a reference, so this should work, but it > doesn't". What you're advocating is intentionally misleading people to deal with a symptom. I'd rather give them enough truth to deal with the disease. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
On Thu, 05 Jan 2006 11:17:44 -0500, Mike Meyer wrote: > While telling them that "You can't do call by reference because Python > is call by object" may be correct, Good to see you finally concede it. > it leaves out the critical information. As does "call by reference" or "call by value". No three word phrase can possibly explain Python's behaviour, or any other language for that matter. You have to know what "call by whatever" *implies* for it to be meaningful. > So they're liable to run into the same problem in a > different context - like the one the OP had. That doesn't follow. The problem isn't that talk about references is *wrong*, but that it is misleading. Where "reference" is being used just as a generic term, it is barely acceptable, but any time it is used in a context where it could be misconstrued is dangerous precisely because people WILL misunderstand it, because they *think* they know what references (assignment, call by reference, whatever) means in this context. The fact that call by object is unfamiliar is precisely its advantage. Instead of people jumping to conclusions about what it means, like they do with "reference", they will stop and think and if need be look for further information about Python's object model. At the very least, they won't say "Everything in Python is a reference, so this should work, but it doesn't". -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
"Ben Sizer" <[EMAIL PROTECTED]> writes: > But, if you separate the calling mechanism from the assignment > mechanism, then Python does behave like every other call by reference > language. The problem is that people expect to then be able to change > the value of the referred object with the assignment operator. It's the > assignment semantics that differ from languages such as C++ and Java, > not the calling mechanism. In C++, assignment means copying a value. In > Python, assignment means reassigning a reference. > > The unfortunate problem is that people think of 'pass by reference' in > association with 'assignment is a mutating operation', when really the > 2 concepts are orthogonal and Python replaces the second with > 'assignment is a reference reseating operation'. The only reason I > stress this is because with this in mind, Python is consistent, as > opposed to seeming to have 2 different modes of operation. Exactly. The critical information is that python's assignment statement is different from what people are used to from C/C++/etc. While telling them that "You can't do call by reference because Python is call by object" may be correct, it leaves out the critical information. So they're liable to run into the same problem in a different context - like the one the OP had. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano wrote: > > On reading back over my post, I realise that it might > sound like I was mad at KraftDiner. My apologies -- I'm > not, I feel (s)he is the victim of incorrect > information here, not the culprit. > > After all, as a Python newbie, how is KraftDiner > supposed to know that when people say "Python is call > by reference", what they actually mean is "Um, except > that it doesn't behave like any call by reference > language you're likely to have used before, and > sometimes it behaves more like call by value"? But, if you separate the calling mechanism from the assignment mechanism, then Python does behave like every other call by reference language. The problem is that people expect to then be able to change the value of the referred object with the assignment operator. It's the assignment semantics that differ from languages such as C++ and Java, not the calling mechanism. In C++, assignment means copying a value. In Python, assignment means reassigning a reference. The unfortunate problem is that people think of 'pass by reference' in association with 'assignment is a mutating operation', when really the 2 concepts are orthogonal and Python replaces the second with 'assignment is a reference reseating operation'. The only reason I stress this is because with this in mind, Python is consistent, as opposed to seeming to have 2 different modes of operation. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Apology Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano wrote: > On Wed, 04 Jan 2006 10:54:17 -0800, KraftDiner wrote: >>I though the contents of lst would be modified.. (After reading that >>'everything' is a refrence.) > > See, this confusion is precisely why I get the urge to slap people who > describe Python as "call by reference". It isn't. On reading back over my post, I realise that it might sound like I was mad at KraftDiner. My apologies -- I'm not, I feel (s)he is the victim of incorrect information here, not the culprit. After all, as a Python newbie, how is KraftDiner supposed to know that when people say "Python is call by reference", what they actually mean is "Um, except that it doesn't behave like any call by reference language you're likely to have used before, and sometimes it behaves more like call by value"? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
