Re: teaching python variables
guy keren wrote: >On Sun, 4 Dec 2005, RaeNye wrote: > > > >>Alas, the *concept* of reference is common to the human mind and human >>language! >> >> > >so your initial claim of being able to explain the examples without using >references, is false. > >so we now agree that we need to teach two concepts: names and references. > > What I call "reference" is implicitly included in most people's (most non-programmers, at least) understanding of what the word "name" means. The same thing also appears in other concepts, such as lists. While a python list does not fully coincide with the daily use of the word, it almost does. My "physical note with list of items" example in another post might help explaining the (minor) difference. You do have to talk about names. You do have to talk about lists (and probably about dicts and tuples, which are other types involving references). Technically you don't HAVE to explain references as a seperate concept, but it might prove useful (e.g. when explaining the fine details about lists). The point is - people DO know about names and it might be easier to explain references (or list items) by using the example of names than the other way around. p.s. : A standalone object implementing the "reference" concept would coincide with a pointer (actually a weakref is almost exactly that) - I don't think we should confuse them with these. >now comes the next issue: > >you can change a list. >you can't change a number. >you can't change a string. >you can't change a tuple. > >in order to explain this, i will use the 'mutable' Vs. 'immutable' issue. > > So - some objects you can change, some not, some you can change but don't. (Note that a tuple contains references even though you can't change it). What's so special about that? Do you define "immutable" any other way than "object that can't be changed"? I'd only mention mutability when your'e about to explain about dicts. You can only use immutable objects as keys for a dictionary. This is a fact that needs to mentioned, even if you don't explain why. (the explanation involves considerations of efficiency, and understanding how dicts are implemented - might be included in the data-structures reading material, but not strictly necessary for this course). >do you have a way to aovid that? > >the rest of what you write is not realy important, except for one point >that i will emphasize: > > > >>Why don't you complain about the following line of code? >> >> >a = [1, 1] > > >>It shows the exact same "problem" - how can the number 1 appear twice in the >>same list? >> >> > >when a person thinks about the number '1', they do NOT think of it as an >object. thus, they are not surprised to see it used twice in a list. the >concept that even a single number is an object is not something natural - > > Depends on how you define object. Common interpretation of the word is "physical object" like "car", but people do say "abstract object" when referring to e.g. numbers. In the context of a computer language, a number is about as physical as a car, so by "python objects" we mean any kind of data. This might need to be explicitly said. However, it is completely natural to give names to numbers - "two","my age", etc. And it's no surprise you can put them in a list. Many people even have the same phone-number listed more than once in their diary. >you don't think of "1+2" as "1.add(2)" (i.e. as an operation of 'add 2' on >the object '1'). you just think of the operationg of adding `1 and 2 >together. you only consider it when you learn about languages such as >smalltalk (which started this "everything is an object" concept. in >smalltalk there are no operators. in order to perform addition, you write >something like: > >[1 add: 2] > >(i.e. send the message 'add:' to the object '1', supplying the object '2' >as a parameter). > > > ahh... touchy point. In fact: >>> (1).__add__(2) 3 >>> Now if you insist on using methods exclusively, you might ask: is 1+2 actually "(1).__add__(2)" or "(2).__radd__(1)"? You quickly get into the following quicksand: http://www.python.org/doc/2.4.2/ref/coercion-rules.html As someone who had the unpleasant experience of having to use and implement such methods, I can tell you that's one big nasty wart in python (luckily their'e aiming to phase that out towards python3). I believe that since both operands have symmetric status, the right thing to do would be to treat the operation as a seperate entity, somewhat like in C++ "friend T operator+(T first, T second)". Unlike Java, we do have simple functions in python. >since python is not pure about the syntax, we don't need to be pure about >explaining things. > > > >>Surely you wouldn't even consider the thought that these are different >>"instances" of the number 1 (although this might be true in other >>programming languages); >> >> > >actually - this is exactly what i wold have thought before being taught >prog
RE: teaching python variables
On Sun, 4 Dec 2005, RaeNye wrote: > Nir wrote: > >Why use "thing"? simply talk about "list1" > >Set the first item of list1 to the number 1 > > This is where you bluntly mislead the students. > "list1" is /nothing/ but the object it's currently binded to, and it's ultra > important that they understand this. oh... now i need to explain the word "bind"? :) i hate this word - it sounds too bombastic. it also does not come from normal life - in normal life, you dont bind names - you just call your bear "teddy". and binding is not exactly the same as "calling by name": if i call my bear teddy, and then i go and tear its head, and its legs and arms and stomach - is it still teddy? in python, if i name a list object 'teddy' and then i delete most of the list's items, it is still called 'a', regardless of any emotions i have towards this list. please understand that "intuitive" is an illusion - any analogy that you'll bring will have some exceptions, which you'll have to explain eventually. which is why i'd rather explain things explicity, then count on the intuition of the pupils. and since i cannot explain everything, eventually i have to tell them "try it out and see how it works". -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
Re: teaching python variables
good, good. i think we have a candidate for writing the slides for meeting 11 (even thought i already spoke with amit about doing it - he might agree to switch ;) ). what sais you? --guy On Sun, 4 Dec 2005, Nir Soffer wrote: > > On 4 Dec, 2005, at 2:09, RaeNye wrote: > > >> Why use this strange name "mlist_a"? Instead use: > >> multiple_lists = [list1, list2] > > > > I don't see a problem with Guy's name selection. I consider your > > suggestion > > worse, as the object called "multiple_lists" is, in fact, a single > > list that > > contains two other lists. You might call the outer list "nested_list" > > or > > "outer_list", but "multiple_lists" has nothing to do with the object > > itself. > > "lists" will be a better name. But why the names in this code are so > lousy? because its not a concrete example, its too abstract. Using real > life examples can make everything more clear. > > For example, bart simpson downloaded our first game, and lisa created a > list of scores for each family member: > > >>> lisa_scores = [90, 85, 80] > >>> bart_scores = [50, 65] > >>> homer_scores = [] # too stupid to play > >>> marge_scores = [] # too busy > > # Lets keep all the scores in one list > >>> simpsons_scores[lisa_scores, bart_scores, homer_scores, > marge_scores] > > Now we can ask questions about it: > > What were lisa scores? > >>> simpsons_scores[0] > [90, 85, 80] > >>> lisa_scores > [90, 85, 80] > > they look equal... > >>> simpsons_scores[0] == lisa_scores > True > > They are. > > Is it the samelist of a copy? > >>> simpsons_scores[0] is lisa_scores > True > > This answer the question, what happens when you do list = [foo, bar] - > you create reference to the objects. > > homer and marge have both empty list. They must be equal: > >>> homer_scores== marge_scores > True > > But they are not the same list: > >>> homer_scores is marge_scores > False > > lisa teach homer to play, and add some scores: > >>> homer_scores.append(10) > > the simpsons_scores list updated: > >>> simpsons_scores > [[90, 85, 80], [50, 65], [10], []] > > homer_scores and simpsons_scores[2] reference the same list object > (which Python manage for us somewhere in the memory) > > homer tries again, made some improvement: > >>> homer_scores.append(11) > >>> simpsons_scores > [[90, 85, 80], [50, 65], [10, 11], []] > > bart is not happy with lisa results: > >>> del lisa_scores > >>> lisa_scores > Traceback (most recent call last): > File "", line 1, in ? > NameError: name 'lisa_scores' is not defined > > That was evil! > > >>> simpsons_scores > [[90, 85, 80], [50, 65], [10, 11], []] > > F**k! they are still there!? hmm, lisa_scores was not the list, its > only a name, the list is still there. This is exactly what Python told > us just now: "NameError: name 'lisa_scores' is not defined". > > lisa fixes the situation > >>> lisa_scores = simpsons_scores[0] > >>> lisa_scores > [90, 85, 80] > > Now [[90, 85, 80], [50, 65], [10, 11], []] is a lousy way to keep this > kind of data, because we have to remember the order of the family > members. This leads naturally to dicts - because we need it NOW to > write simpler and more readable code. > > > I hope it helps, It was fun to write :-) > > > Best Regards, > > Nir Soffer > -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
RE: teaching python variables
On Sun, 4 Dec 2005, RaeNye wrote: > Alas, the *concept* of reference is common to the human mind and human > language! so your initial claim of being able to explain the examples without using references, is false. so we now agree that we need to teach two concepts: names and references. now comes the next issue: you can change a list. you can't change a number. you can't change a string. you can't change a tuple. in order to explain this, i will use the 'mutable' Vs. 'immutable' issue. do you have a way to aovid that? the rest of what you write is not realy important, except for one point that i will emphasize: > Why don't you complain about the following line of code? > >>> a = [1, 1] > It shows the exact same "problem" - how can the number 1 appear twice in the > same list? when a person thinks about the number '1', they do NOT think of it as an object. thus, they are not surprised to see it used twice in a list. the concept that even a single number is an object is not something natural - you don't think of "1+2" as "1.add(2)" (i.e. as an operation of 'add 2' on the object '1'). you just think of the operationg of adding `1 and 2 together. you only consider it when you learn about languages such as smalltalk (which started this "everything is an object" concept. in smalltalk there are no operators. in order to perform addition, you write something like: [1 add: 2] (i.e. send the message 'add:' to the object '1', supplying the object '2' as a parameter). since python is not pure about the syntax, we don't need to be pure about explaining things. > Surely you wouldn't even consider the thought that these are different > "instances" of the number 1 (although this might be true in other > programming languages); actually - this is exactly what i wold have thought before being taught programming - that you can use the number 1 here, and there, and i'd not even bother thinking that they are the same '1'. > Your concept of what a list /is/ should be ready to accept an object > appearing as multiple elements in it. in other words - references. that's what i wanted to show in the first place - thanks for helping ;) > I don't say the concept of reference is avoidable. I only refuse to present > it as a special thing. when you teach programming - everything must be explicit. what you think is intuitive - is intuitive in a different way to different people. avoiding talking about something does not make it clear. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
Re: teaching python variables
Amit Aronovitch wrote: >Typically, the instructor would say (or imply) something like: > > * Variables are named areas of memory storing data of some type. > * Pointers are variables storing memory addresses of other variables. > * Python works by reference. This means that variables are actually > implemented as pointers (i.e. store memory addresses), but the language > does implicit dereference whenever they appear in expressions (i.e. > operations other than assignment work on the area pointed to by the >pointer > rather than the pointer itself). > > > Just emphasizing the importance of the phrase "other than assignment" above: Fortran, for example, uses "by reference" arguments passing, but it's variable concept is much the same - the assignment operator works on the *value* rather than the pointer (i.e. doing a=b you get a *copy* of b). In other words - "python vars" vs "common vars" is not the same as "by reference" vs "by value".
Re: teaching python variables
guy keren wrote: >On Fri, 2 Dec 2005, Amit Aronovitch wrote: > > > >>Meta >> >>In this essay I'll try to clearly state some of my ideas about variables in >>python and how to teach the subject to students new to programming. >> >> > >lets cut the long talks. in order for me to understand what you're trying >to do, i would like you to explain the following scenarios using the >terms you're suggesting: > > > Now, after I spent the long time writing this "long talks", at least people can understand ME without endless Q&A's. Now they can make themselves clear by saying just where their opinion differs than mine. For people whose views are close to mine - this allows expressing alot more with "short talks" :-) >Scenario 1: > >>> list1 = [2, 3] > >>> list1[0] = 1 > >>> print list1 > [1, 3] > > > Ahh lists... The first thing I have to say here is that IMHO, any real problems here (if at all) are related to the *list* concept, which is completely seperate from the *variable* concept. When you say a=3 you get variable which is not a list, and when you say a=[1,2]+[3] you get two nameless lists (not tied to any variable). Now the *list* concept, I have to admit, is abit more abstract. Maybe 5-years-old child one, rather than 2.5 year-old one (I'll probably know better when my son grows up a bit ;-) ). I think a good daily object to compare to is a physical list written on a piece of paper with a pencil. When you say list1[0] = 1, this means you go to the piece of paper, erase the first item, and write 1 instead. For example: suppose you have too such notes, "the blue note" and "the red note" the blue note says: 0) My dad's car 1) 7 2) Teddy the bear the red note says: 0) The blue note 1) My dad's car 2) The blue note Now, if I go and paint my car white, both blue_note[0].color (the color of the first item in the blue note) and red_note[1].color will be white. If i change blue_note[1] with 5, both (red_note[0])[1] and (red_note[2])[1] will be 5. The abstraction needed here is really the generalizing the "reference" property of names to other things (you don't actually have to *say* reference, but it might help) - you just have to understand that the text strings on your note represent real objects the same way as names do. (This is not really the hard part of the concept. Maybe the harder thing is to understand that list[0] can be a label without there being any real text line saying "My dad's car": for example, the pupil might expect "list[0]" to print "'dads_car'" instead of "repr(dads_car)" ) >Scenario 2: > >>> a = 1; b = 2; c = 3 > >>> list1 = [a, b, c] > >>> list2 = [b, c] > >>> print list1 > [1, 2, 3] > >>> print list2 > [2, 3] > >Scenario 3: > >>> list1 = [1, 2] > >>> list2 = [3, 4] > >>> mlist_a = [list1, list2] > >>> print mlist_a > [[1, 2], [3, 4]] > >>> mlist_a[1] = list1 > >>> print mlist_a > [[1, 2], [1, 2]] > > > > These all seem obvious to me if you use the physical note example. If you think otherwise, please say exactly where you think the student would expect any other result, and we can come up with a solution.
RE: teaching python variables
Now that's a splendid example. The previous Guy-Amit discussion was on a somewhat higher level (not actually relating to the specific ongoing course), but surely when teaching the kids it's better to use this kind of examples. R. -Original Message- From: Nir Soffer [mailto:[EMAIL PROTECTED] Sent: Sunday, December 04, 2005 3:58 AM To: RaeNye Cc: Python User Group Subject: Re: teaching python variables On 4 Dec, 2005, at 2:09, RaeNye wrote: >> Why use this strange name "mlist_a"? Instead use: >> multiple_lists = [list1, list2] > > I don't see a problem with Guy's name selection. I consider your > suggestion worse, as the object called "multiple_lists" is, in fact, a > single list that contains two other lists. You might call the outer > list "nested_list" > or > "outer_list", but "multiple_lists" has nothing to do with the object > itself. "lists" will be a better name. But why the names in this code are so lousy? because its not a concrete example, its too abstract. Using real life examples can make everything more clear. For example, bart simpson downloaded our first game, and lisa created a list of scores for each family member: >>> lisa_scores = [90, 85, 80] >>> bart_scores = [50, 65] >>> homer_scores = [] # too stupid to play >>> marge_scores = [] # too busy # Lets keep all the scores in one list >>> simpsons_scores[lisa_scores, bart_scores, homer_scores, marge_scores] Now we can ask questions about it: What were lisa scores? >>> simpsons_scores[0] [90, 85, 80] >>> lisa_scores [90, 85, 80] they look equal... >>> simpsons_scores[0] == lisa_scores True They are. Is it the same list of a copy? >>> simpsons_scores[0] is lisa_scores True This answer the question, what happens when you do list = [foo, bar] - you create reference to the objects. homer and marge have both empty list. They must be equal: >>> homer_scores == marge_scores True But they are not the same list: >>> homer_scores is marge_scores False lisa teach homer to play, and add some scores: >>> homer_scores.append(10) the simpsons_scores list updated: >>> simpsons_scores [[90, 85, 80], [50, 65], [10], []] homer_scores and simpsons_scores[2] reference the same list object (which Python manage for us somewhere in the memory) homer tries again, made some improvement: >>> homer_scores.append(11) >>> simpsons_scores [[90, 85, 80], [50, 65], [10, 11], []] bart is not happy with lisa results: >>> del lisa_scores >>> lisa_scores Traceback (most recent call last): File "", line 1, in ? NameError: name 'lisa_scores' is not defined That was evil! >>> simpsons_scores [[90, 85, 80], [50, 65], [10, 11], []] F**k! they are still there!? hmm, lisa_scores was not the list, its only a name, the list is still there. This is exactly what Python told us just now: "NameError: name 'lisa_scores' is not defined". lisa fixes the situation >>> lisa_scores = simpsons_scores[0] >>> lisa_scores [90, 85, 80] Now [[90, 85, 80], [50, 65], [10, 11], []] is a lousy way to keep this kind of data, because we have to remember the order of the family members. This leads naturally to dicts - because we need it NOW to write simpler and more readable code. I hope it helps, It was fun to write :-) Best Regards, Nir Soffer
Re: teaching python variables
On 4 Dec, 2005, at 2:09, RaeNye wrote: Why use this strange name "mlist_a"? Instead use: multiple_lists = [list1, list2] I don't see a problem with Guy's name selection. I consider your suggestion worse, as the object called "multiple_lists" is, in fact, a single list that contains two other lists. You might call the outer list "nested_list" or "outer_list", but "multiple_lists" has nothing to do with the object itself. "lists" will be a better name. But why the names in this code are so lousy? because its not a concrete example, its too abstract. Using real life examples can make everything more clear. For example, bart simpson downloaded our first game, and lisa created a list of scores for each family member: >>> lisa_scores = [90, 85, 80] >>> bart_scores = [50, 65] >>> homer_scores = [] # too stupid to play >>> marge_scores = [] # too busy # Lets keep all the scores in one list >>> simpsons_scores[lisa_scores, bart_scores, homer_scores, marge_scores] Now we can ask questions about it: What were lisa scores? >>> simpsons_scores[0] [90, 85, 80] >>> lisa_scores [90, 85, 80] they look equal... >>> simpsons_scores[0] == lisa_scores True They are. Is it the same list of a copy? >>> simpsons_scores[0] is lisa_scores True This answer the question, what happens when you do list = [foo, bar] - you create reference to the objects. homer and marge have both empty list. They must be equal: >>> homer_scores == marge_scores True But they are not the same list: >>> homer_scores is marge_scores False lisa teach homer to play, and add some scores: >>> homer_scores.append(10) the simpsons_scores list updated: >>> simpsons_scores [[90, 85, 80], [50, 65], [10], []] homer_scores and simpsons_scores[2] reference the same list object (which Python manage for us somewhere in the memory) homer tries again, made some improvement: >>> homer_scores.append(11) >>> simpsons_scores [[90, 85, 80], [50, 65], [10, 11], []] bart is not happy with lisa results: >>> del lisa_scores >>> lisa_scores Traceback (most recent call last): File "", line 1, in ? NameError: name 'lisa_scores' is not defined That was evil! >>> simpsons_scores [[90, 85, 80], [50, 65], [10, 11], []] F**k! they are still there!? hmm, lisa_scores was not the list, its only a name, the list is still there. This is exactly what Python told us just now: "NameError: name 'lisa_scores' is not defined". lisa fixes the situation >>> lisa_scores = simpsons_scores[0] >>> lisa_scores [90, 85, 80] Now [[90, 85, 80], [50, 65], [10, 11], []] is a lousy way to keep this kind of data, because we have to remember the order of the family members. This leads naturally to dicts - because we need it NOW to write simpler and more readable code. I hope it helps, It was fun to write :-) Best Regards, Nir Soffer
RE: teaching python variables
>Why use "thing"? simply talk about "list1" >Set the first item of list1 to the number 1 This is where you bluntly mislead the students. "list1" is /nothing/ but the object it's currently binded to, and it's ultra important that they understand this. Otherwise, they would think the following code doesn't change the object name "list2", as it only deals with "list1". >>> list1 = [0] >>> list2 = list1 >>> list1[0] = 100 >> We name the number 1 "a", the number 2 "b" and the number 3 "c". >This is very confusing - you should not talk about "a" which is a string! >Create 3 names and bind the numbers 1, 2, and 3 to the names. Come on... I speak english here, not python! Imagine a bold fontface wherever I use quotation marks. >Why use this strange name "mlist_a"? Instead use: >multiple_lists = [list1, list2] I don't see a problem with Guy's name selection. I consider your suggestion worse, as the object called "multiple_lists" is, in fact, a single list that contains two other lists. You might call the outer list "nested_list" or "outer_list", but "multiple_lists" has nothing to do with the object itself. -Original Message- From: Nir Soffer [mailto:[EMAIL PROTECTED] Sent: Sunday, December 04, 2005 1:50 AM To: RaeNye Cc: 'guy keren'; python@linux.org.il; 'Amit Aronovitch' Subject: Re: teaching python variables Here is my version, not using the "variable", but using "reference", which seem natural.
Re: teaching python variables
Here is my version, not using the "variable", but using "reference", which seem natural. On 4 Dec, 2005, at 0:26, RaeNye wrote: Scenario 1: list1 = [2, 3] Let there be a list built up from two elements: the number 2 and the number 3. We call it "list1". Create a list with two numbers and bind it to the name "list1" It will be a good idea to print the list now - before we change it: >>> list1 [2, 3] list1[0] = 1 We change the thing called "list1" (which happens to be the object we created one sentence ago) by replacing its first element from whatever it was to the number 1. Why use "thing"? simply talk about "list1" Set the first item of list1 to the number 1 print list1 [1, 3] Now examine the thing called "list1" - it contains two elements: the first is the number 1 (since we changed it to be so) and the second is the number 3 (since it didn't change from the time the object was born). We can see that the first item was replaced. Scenario 2: a = 1; b = 2; c = 3 We name the number 1 "a", the number 2 "b" and the number 3 "c". This is very confusing - you should not talk about "a" which is a string! Create 3 names and bind the numbers 1, 2, and 3 to the names. list1 = [a, b, c] We create a list built up from three elements: the object named "a" (i.e., the number 1), the object named "b" (i.e., the number 2) and the object named "c" (i.e., the number 3). We call it "list1". Create a list containing those numbers. It can make it more clear to ask: is [a, b, c] equal to [1, 2, 3]? and let the students find the result, or show it: >>> [a, b, c] == [1, 2, 3] True It should be clear that a is NOT an object, its a name, and it is bound to the object "1" which is a number. And to make this more clear: >>> a = 1 >>> type(a) >>> a = 3.14 >>> type(a) >>> a = 'String' >>> type(a) a is a name, we can bind it to any object. And: >>> a = 1 >>> b = 1 >>> a == b True >>> a is b True Same object can be bound to may names. list2 = [b, c] We create a list built up from two elements: the object named "b" (i.e., the number 2) and the object named "c" (i.e., the number 3). We call it "list2". Create another list from the same numbers print list1 [1, 2, 3] The object named "list1" consists of the number 1, the number 2 and the number 3. That exactly how it was bulit. Printing the lists, not much to explain. print list2 [2, 3] The object named "list2" consists of the number 2 and the number 3. That exactly how it was bulit. Again. Scenario 3: list1 = [1, 2] list2 = [3, 4] We create two lists, named "list1" and "list2" respectively (with the obvious content: the number 1 ...) Same as before. mlist_a = [list1, list2] We create a list built of the object named "list1" and the object named "list2" (which are the same two lists created above). We call it "mlist_a". Why use this strange name "mlist_a"? Instead use: multiple_lists = [list1, list2] print mlist_a [[1, 2], [3, 4]] Obvious. mlist_a[1] = list1 We change the thing called "mlist_a" (which happens to be the object we created two sentences ago) by replacing its first element to the object named "list1". Note that now the object named "mlist_a" contains the same object as both the first and the seconds element: a list that consists of the number 1 and the number 2. This is not a good example, because you can show the same thing using much simpler code: >>> name = 'Foo' >>> list = [name, name] >>> list[0] 'Foo' >>> list[1] 'Foo' >>> list[0] == list[1] True >>> list[0] is list[1] True A list contain reference to other objects. The same object can appear multiple times in the same list. print mlist_a [[1, 2], [1, 2]] Obvious, considering the last note. But all this code is too dry - better show interesting usage examples for each Scenario. The student does not have to really understand how Python works in this stage, a partial and simple "picture" is needed, the picture may be more complete and correct in the end of the course. Anyway how you explain things is not the most important thing - its more important that the students will spend a lot of time with Python, trying to do simple things, make errors and learn from them. Best Regards, Nir Soffer
RE: teaching python variables
Alas, the *concept* of reference is common to the human mind and human
language!
This sentence is an fine example of it, as it contains references to itself
("this", "it contains") and to the concept of reference ("example of it").
Why don't you complain about the following line of code?
>>> a = [1, 1]
It shows the exact same "problem" - how can the number 1 appear twice in the
same list?
Surely you wouldn't even consider the thought that these are different
"instances" of the number 1 (although this might be true in other
programming languages);
Your concept of what a list /is/ should be ready to accept an object
appearing as multiple elements in it.
> and then what happens if i go and change list1[0] to be '3'? it changed
twice, didn't it? so the object named mlist_a actually references the object
named list1, right?
The whole point is that names are only temporary labels, immediately
replaced by the objects they (currently) stand for.
I don't say the concept of reference is avoidable. I only refuse to present
it as a special thing.
The very same intuitive connection that exists between a name and an object
called by this name, exists in other places as well, e.g., between a
container element and the object that the container contains there (in fact,
considering that global names are just __main__.__dict__.keys(), it *is* the
same connection).
R.
-Original Message-
From: guy keren [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 04, 2005 4:20 AM
To: RaeNye
Cc: python@linux.org.il; 'Amit Aronovitch'
Subject: RE: teaching python variables
On Sun, 4 Dec 2005, RaeNye wrote:
> Please verify that I use the same explanation for each syntactic form
> (list constructor, __setitem__, assignment operator).
> Also, please see that I refrain from mentioning variables and references.
ok, no references, you say. now let us go directly to the 3rd example:
> Scenario 3:
>
> >>> list1 = [1, 2]
> >>> list2 = [3, 4]
> We create two lists, named "list1"and "list2" respectively (with the
> obvious content: the number 1 ...)
>
> >>> mlist_a = [list1, list2]
> We create a list built of the object named "list1" and the object
> named "list2" (which are the same two lists created above). We call it
"mlist_a".
>
> >>> print mlist_a
> [[1, 2], [3, 4]]
> Obvious.
>
> >>> mlist_a[1] = list1
> We change the thing called "mlist_a" (which happens to be the object
> we created two sentences ago) by replacing its first element to the
> object named "list1".
> Note that now the object named "mlist_a" contains the same object as
> both the first and the seconds element: a list that consists of the
> number 1 and the number 2.
ok. an object containing the same element twice. you're using the concept of
reference, without using the word reference. to me this sounds like breaking
the rules. otherwise, how can an object contain the same object twice? does
it contain two copies of this object? or perhaps it contains 2 references to
the same object?
and then what happens if i go and change list1[0] to be '3'? it changed
twice, didn't it? so the object named mlist_a actually references the object
named list1, right?
can you explain this thing without mentioning the word "reference", as well
as without using the concept "reference"?
note that i didn't even mention things like iterators, slices (which create
a new list containing references to some of the members of an existing
list), etc.
i don't see how references can be avoided (as a concept, not just by not
using the name).
--
guy
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy
RE: teaching python variables
On Sun, 4 Dec 2005, RaeNye wrote: > Please verify that I use the same explanation for each syntactic form (list > constructor, __setitem__, assignment operator). > Also, please see that I refrain from mentioning variables and references. ok, no references, you say. now let us go directly to the 3rd example: > Scenario 3: > > >>> list1 = [1, 2] > >>> list2 = [3, 4] > We create two lists, named "list1"and "list2" respectively (with the > obvious content: the number 1 ...) > > >>> mlist_a = [list1, list2] > We create a list built of the object named "list1" and the object named > "list2" (which are the same two lists created above). We call it "mlist_a". > > >>> print mlist_a > [[1, 2], [3, 4]] > Obvious. > > >>> mlist_a[1] = list1 > We change the thing called "mlist_a" (which happens to be the object we > created two sentences ago) by replacing its first element to the object > named "list1". > Note that now the object named "mlist_a" contains the same object as both > the first and the seconds element: a list that consists of the number 1 and > the number 2. ok. an object containing the same element twice. you're using the concept of reference, without using the word reference. to me this sounds like breaking the rules. otherwise, how can an object contain the same object twice? does it contain two copies of this object? or perhaps it contains 2 references to the same object? and then what happens if i go and change list1[0] to be '3'? it changed twice, didn't it? so the object named mlist_a actually references the object named list1, right? can you explain this thing without mentioning the word "reference", as well as without using the concept "reference"? note that i didn't even mention things like iterators, slices (which create a new list containing references to some of the members of an existing list), etc. i don't see how references can be avoided (as a concept, not just by not using the name). -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
RE: teaching python variables
Can I try? Please verify that I use the same explanation for each syntactic form (list constructor, __setitem__, assignment operator). Also, please see that I refrain from mentioning variables and references. Hope that'd pour some light, R. Scenario 1: >>> list1 = [2, 3] Let there be a list built up from two elements: the number 2 and the number 3. We call it "list1". >>> list1[0] = 1 We change the thing called "list1" (which happens to be the object we created one sentence ago) by replacing its first element from whatever it was to the number 1. >>> print list1 [1, 3] Now examine the thing called "list1" - it contains two elements: the first is the number 1 (since we changed it to be so) and the second is the number 3 (since it didn't change from the time the object was born). Scenario 2: >>> a = 1; b = 2; c = 3 We name the number 1 "a", the number 2 "b" and the number 3 "c". >>> list1 = [a, b, c] We create a list built up from three elements: the object named "a" (i.e., the number 1), the object named "b" (i.e., the number 2) and the object named "c" (i.e., the number 3). We call it "list1". >>> list2 = [b, c] We create a list built up from two elements: the object named "b" (i.e., the number 2) and the object named "c" (i.e., the number 3). We call it "list2". >>> print list1 [1, 2, 3] The object named "list1" consists of the number 1, the number 2 and the number 3. That exactly how it was bulit. >>> print list2 [2, 3] The object named "list2" consists of the number 2 and the number 3. That exactly how it was bulit. Scenario 3: >>> list1 = [1, 2] >>> list2 = [3, 4] We create two lists, named "list1" and "list2" respectively (with the obvious content: the number 1 ...) >>> mlist_a = [list1, list2] We create a list built of the object named "list1" and the object named "list2" (which are the same two lists created above). We call it "mlist_a". >>> print mlist_a [[1, 2], [3, 4]] Obvious. >>> mlist_a[1] = list1 We change the thing called "mlist_a" (which happens to be the object we created two sentences ago) by replacing its first element to the object named "list1". Note that now the object named "mlist_a" contains the same object as both the first and the seconds element: a list that consists of the number 1 and the number 2. >>> print mlist_a [[1, 2], [1, 2]] Obvious, considering the last note. -Original Message- From: guy keren [mailto:[EMAIL PROTECTED] Sent: Sunday, December 04, 2005 1:44 AM To: Amit Aronovitch Cc: python@linux.org.il Subject: Re: teaching python variables On Fri, 2 Dec 2005, Amit Aronovitch wrote: > Meta > > In this essay I'll try to clearly state some of my ideas about > variables in python and how to teach the subject to students new to programming. lets cut the long talks. in order for me to understand what you're trying to do, i would like you to explain the following scenarios using the terms you're suggesting: Scenario 1: >>> list1 = [2, 3] >>> list1[0] = 1 >>> print list1 [1, 3] Scenario 2: >>> a = 1; b = 2; c = 3 >>> list1 = [a, b, c] >>> list2 = [b, c] >>> print list1 [1, 2, 3] >>> print list2 [2, 3] Scenario 3: >>> list1 = [1, 2] >>> list2 = [3, 4] >>> mlist_a = [list1, list2] >>> print mlist_a [[1, 2], [3, 4]] >>> mlist_a[1] = list1 >>> print mlist_a [[1, 2], [1, 2]] -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
Re: teaching python variables
On Fri, 2 Dec 2005, Amit Aronovitch wrote: > Meta > > In this essay I'll try to clearly state some of my ideas about variables in > python and how to teach the subject to students new to programming. lets cut the long talks. in order for me to understand what you're trying to do, i would like you to explain the following scenarios using the terms you're suggesting: Scenario 1: >>> list1 = [2, 3] >>> list1[0] = 1 >>> print list1 [1, 3] Scenario 2: >>> a = 1; b = 2; c = 3 >>> list1 = [a, b, c] >>> list2 = [b, c] >>> print list1 [1, 2, 3] >>> print list2 [2, 3] Scenario 3: >>> list1 = [1, 2] >>> list2 = [3, 4] >>> mlist_a = [list1, list2] >>> print mlist_a [[1, 2], [3, 4]] >>> mlist_a[1] = list1 >>> print mlist_a [[1, 2], [1, 2]] -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
teaching python variables
ages offer ways to enforce a fixed interperetation (type) of the
binary
data stored in the variable. The stored data, interpeted in the
designated way,
is called the variable's value. You can change the value by changing the
stored
binary data - this is called assignment (assigning a new value to the
variable).
This concept is "more human", because it assigns meaning to the binary
data and
treats it as typed values. However, the "variable" is identified with a
specific
position in memory, and you must understand that in order to understand the
behaviour of assignments.
Human Concepts
==
The discussion above might seem completely obvious and natural to
experienced
programmers. However, since we are discussing teaching people new to
programming
we have to try to unlearn it and revert to more intuitive "human" concepts.
As Fredrik Lundh puts it "Reset your brain"...
In the world of humans, objects (values) just *exist*. We are not normally
concerned with the way they are represented by binary digits or where these
digits are stored.
However, we can freely give them names. We are fully aware that names
are just
artificial labels, not inherently tied to the object itself.
We might call a bear "Teddy", but if we change his name to "Eddie" we
know it's
still the same bear. Moreover, there is nothing stopping us from deciding to
call our cat "Teddy" (objects have types, names do not). If we do name
the cat
Teddy, we certainly would not expect poor old "formerly Teddy" the bear
to be
"overridden" by the cat.
When we give instructions, they often contain names whose values are
assigned
to specific (and different) objects each time they are executed. For example
a recipe for preparing a salad might say "cut the cucumber". Now, each time
you apply that instruction, "the cucumber" refers to a different object.
We don't have to copy the cucumber to a specific storage location,
overriding
the previous cucumber stored there. Only our interpretation of the label
"the cucumber" changed. If you insist on calling "the cucumber" a
variable, it
would be very wierd to say that "the contents" of the variable changed
("contents" implies a physical storage place), only the variable's
assignment to
a physical object changes. Saying that the variable's value changed might be
inexact, but makes more sense (it's not the object itself that changed,
merely
the choice of which value is assigned to the variable).
Python objects and names behave much the same way as the real-world
concepts
described above. Objects (such as numbers, strings and class instances)
just
exist in their own space. They are strongly typed, but do not have an
inherent
"name". The programmer does not need to think about where they are
stored (when
not needed anymore, the garbage collector might decide to erase them,
but this
is just an implementation detail). Names are merely labels - they don't
have
inherent types, and are not associated with a fixed position in memory.
People commonly refer to python "names" as "variables" (and to the
associated
objects as "values"), but that's only because they take roughly the same
role
as other languages' variables. It does NOT mean they are associated to a
specific memory storage area or that they should have inherent types.
Teaching Python Variables
=
Explaining Python variables by using the "common variable concept" might
work
well for experienced programmers of other languages (though it might be a
little confusing - see the examples of common bugs in reference (1)).
But for
people learning Python as first language it could be a strategic mistake.
First of all you mislead the students into thinking that python variables
should behave like other languages' vars do, causing them to produce the
same
bugs mentioned in reference (1).
Second, the common concept of variables, while intuitive to experienced
programmers, is still non-trivial. Using it to explain the much simpler
concept
of python names makes it seem unnecessarily complex and confusing. It
could be
compared to trying to use the CPU's address and data registers to explain C
variables.
Typically, the instructor would say (or imply) something like:
* Variables are named areas of memory storing data of some type.
* Pointers are variables storing memory addresses of other variables.
* Python works by reference. This means that variables are actually
implemented as pointers (i.e. store memory addresses), but the language
does implicit dereference whenever they appear in expressions (i.e.
operations other than assignment work on the area pointed to by the
pointer
rather than the pointer itself).
Note that usually they would not say all of that in the first lesson
