Mailman 3 May 2008 - Edu-sig

Re: [Edu-sig] Python for Beginners
by John Posner 26 May '08

26 May '08

> > Right, as long as by "zero names" you're ruling out any > pointers to pointers through a data structure, ... Are you referring to this situation: IDLE 1.2.1 >>> import sys >>> a = 'this is a really unique value' >>> sys.getrefcount(a) 2 >>> dict01 = { 'first' : a, 'second' : 2 } >>> sys.getrefcount(a) 3 >>> dict02 = { 'uno' : a, 'dos' : 222 } >>> sys.getrefcount(a) 4 > ... which are > anonymous from another angle (the structure itself has a > name, but the objects may be like Rod(color="Red"), with > color choosing the length behind the scenes. d = > {"red":Rod()} is then a string literal mapped to an object, > *like* a top-level name, but not. d is the top-level name in > this namespace. Rod( ) in a sense has no name, is a call to > a constructor that returned on object captured within a > dictionary. So it won't be garbage collected, as it knows > there's this pointer for some reason (for what reason the > object will have no clue). "Rod() in a sense has no name" ?? Doesn't the Rod object get the name "red" in *almost exactly* the same way in these two cases? Case #1: >>> red = Rod() Case #2: >>> d = { "red" : Rod() } In Case #1, the name "red" is created in the local (or maybe global) namespace. In Case #2, the name "red" is created in the namespace of a dictionary object. In the sticky-note metaphor: a dictionary object is just a collection of sticky-notes -John Posner

2 1

Re: [Edu-sig] Python for Beginners
by John Posner 25 May '08

25 May '08

Comments on Kirby's comments ... > Except we also have "x == y" and "x is y" in Python, with "x > == y" mapping to a __rib__ in x (optionally absent in the > more general case), i.e. > x == y calls x.__eq__(y) > http://docs.python.org/ref/customization.html > > This is worth mentioning as that leaves the door open to "==" > meaning something quite alien, in the hands of a perverse > programmer, whereas "=" (assignment) and "is" (memory id > comparison) are much more hard-wired. I wouldn't mention the fact that the "==" operator can be "corrupted" by an incorrect/mischievous definition of the __eq__ method, any more than I'd mention that "*" can get similar treatment with a definition of __mul__. This is *way* beyond Python for Beginners, IMHO. > Deallocation of memory objects is more rightly the job of the > garbage collector. "del y" impacts the referenced PyObject > in that the latter's name counter goes down. Yup, "del y" operates on the name (remove the sticky note from the object, then throw away the sticky note). The important thing for beginners to know is that if an object has zero names (sticky notes), there's no way to refer to it. It's as good as gone. The fact that some background process might delete the no-name object from memory is not something beginners would, or should, care about. > When we go x = y, x and y dock for a sec, and a payload goes > from y to x, like an URL, or a remote, a controller. > > The copy is likewise disposable, and y will not ask for it > back, or shouldn't have to, because y keeps its own copy, > it's own relationship with that snake-like thing with > __ribs__ (the number 8 for example). Hmmm ... "x and y dock for a sec" could lead a beginner to believe that "y" refers to "x", rather than "y" refers to the same object that "x" refers to. I have nothing against Internet-oriented metaphors, as long as they help the beginner to learn the way in which the language *actually* works. How about this: On the Web, you can buy a product directly from the manufacturer, using the manufacturer's product code. Or you can buy it from Amazon, which has its own product code. There's only one product, but it can have two (or more) identifiers that enable you to access it. > But x and y have no lasting relationship. For a split > second, they're coupled, in that x needs a copy of y's URL, > the pointer to the object. Then they go their separate ways > *immediately*. I'd rather say that the names "x" and "y" have no relationship at all. Each of them happens to have a relationship with the same object. -John Posner

2 1

Re: [Edu-sig] Python for Beginners
by John Posner 24 May '08

24 May '08

> > I think in an Intro to Programming course featuring Python or > not, it'd make sense to talk a lot ... I suggest talking a little, not a lot. Your note about "Let" is good. How about just a short explanation that in algebra (the context in which most students are likely to have encountered the concept of a variable), we make *declarations of truth*: x = 12 + y the value of x IS EQUAL TO the value of the expression "12 + y" ... whereas in computer programming, we *give instructions* to the computer: x = 12 + y LET the value of x BE EQUAL TO the value of the expression "12 + y" > ... about this new use of the > equality symbol ( = ) and how language designers have felt > about it (suspicious in some cases). I suspect that students in an Intro to Programming course couldn't care less about what the language designers thought. Language comparison in an intro course is more likely to be confusing than enlightening. How many high schools teach French and Spanish in the same course? > Post-its also have this problem of needing to be physically > connected to things (that's the hallmark of post-its, they > stick to stuff). You can't convince me that John Zelle's sticky note metaphor is anything other than *fabulous*: they're different from objects, but are attached to objects; they can be easily removed from one object and attached to another; they can be destroyed without affecting the objects to which they were attached. My only complaint is that John doesn't use the metaphor *more* in his textbook! :-) > When I go y = x in Python, it's like x emailing a web address > to y. Um, it's *way* more like attaching a sticky note to a physical object. > (what true beginners are likely familiar with, given > at least minimal GUI-based file management experience) That's a "true beginner"? > Either way x = y might come across as "static through time" > in some way, whereas in many computer languages (I'm not > saying all), we're talking about a quick happening, a few > nanoseconds or clock cycles, then it's all over. Nope, the sticky note remains attached to the object for a considerable period -- until it's removed from that object and placed on another one. [ ... or until the naming scope disappears. John Zelle, do you include this situation in your sticky-note metaphor? Could sticky notes *of a particular color* or "with a particular shape* indicate the names in a particular scope? ] -John Posner

2 1

Re: [Edu-sig] Python for Beginners
by kirby urner 23 May '08

23 May '08

At one time in my life I played with the prospect of becoming an airport manager, to the point of buying some expensive books (OK one book) on the subject and reading up in Florida (Bradenton, Golf Lakes Estates), between other jobs. I do like the postit metaphor, but have trouble visualizing going around a busy airport putting post-its on ticket counters, security apparatus, flight attendants, and not getting in trouble. On the other hand, with a textbook open, an airport depicted, I'm very used to pointers in the sense of arrows, usually labeled, call them tags or handles. Anatomy books, same thing, pointers to ribosomes, close-ups of DNA or whatever. So just to use our own OO jargon, I'd say sticky post-its are a subclass of the tag or handle concept. Descending the same tree along other branches, we get to my dog leash metaphor (the first ring of which came from a coffee cup (another idea of "a variable") in some "Youtoon" awhile back). Back to the airport, what we want students to realize is that multiple namespaces might be about the same complex institution or knowledge domain, but hey, we *don't* want to import all this complexity willy-nilly, but with an eye towards getting very specific work done. Namespaces are *designed* (more or less intelligently) for a specific *purpose*. They're the antithesis or random inventories of stuff, in most cases. And keep in mind what namespaces map: not just static data. You can fire up a jet engine, switch on the radar, start and stop elevators. A namespace is like some Lawn Mower Man fantasy, except in a more manageable and sustainable form. Yes it's about control, we're not apologetic about that. Engineering is engineering in that respect. So in one namespace it's all about baggage handling, in another all about queuing in ticket lanes, in another all about food services along the concourse, surveillance cameras (who's pigging out) -- haven't even mentioned the airplanes yet, or the runways. So many namespaces! This gets across to the beginner that we're free to tag as we please, going into a situation, and there's nothing illogical or inherently confusing about multiple namespaces using the same objects concurrently. That's how we work in the real world as human beings: as players operating in parallel within a shared environment. OO (an invention, a style of thinking) has always been about letting us think naturally, in ways already familiar to us, independently of any computer or science. We need to think about threads within processes on a given computer, sure, but also about concurrency within our respective knowledge domains, and this idea of many namespaces sharing access to a busy airport, each supporting a point of view, or job description, is going to help with many a future programming challenge. Kirby On Thu, May 22, 2008 at 9:15 AM, Winston Wolff <winstonwolff(a)cal.berkeley.edu> wrote: > Using the post-it note metaphor, it might be better to say: > > x = y is the same as creating a new bookmark called "x" which represents "y" > > -ww > > On May 21, 2008, at 9:13 PM, kirby urner wrote: > >> x = y involves "emailing" an URL from y to x, setting up a second >> alias. Recipient x now has a copy of the same URL as y, but no website >> got copied. > > Winston Wolff > Stratolab - Kids exploring computers, comics, and robots > (646) 827-2242 - http://stratolab.com > >

2 2

Python for Beginners
by kirby urner 22 May '08

22 May '08

For true beginners, I think we should leverage their experience with The Web, assume that as a given, and seek analogies on that basis. We needn't begin with any model of "computer memory" in the sense of some individual standalone machine with a flash drive and RAM. So how about we teach that names are like aliases for URLs, objects like websites? There's a kind of DNS service in Python where the alias maps to the actual IP number of the host, which'd be like going id(x). When you use dot notation, other syntax, against a name, e.g. dog.eat(dog), you're like "sending a message" (Smalltalk image) to a website (object) at some id number (like an ip number), thereby invoking a method, changing its state maybe. x = y involves "emailing" an URL from y to x, setting up a second alias. Recipient x now has a copy of the same URL as y, but no website got copied. This conforms to how people generally share websites, by passing hyperlinks by email. x, a name, is like "a portal" to the object it names. type(x) will give you some insight into what services are offered. dir(x) or help(x) also come in handy. This fits our model of the web in that web pages don't really know what other pages link to them (a little difference is PyObjects keep track of "how many"). We're also used to websites being "more than just data" these days, i.e. they offer services, which is characteristic of objects more generally. This'll be good prep for xml-rpc etc. We also know that web pages themselves may contain links to other web pages and so on, which reminds us of how collections work (links to links). Some objects, like some websites, are static, like 8 (a simple set of services, read-only, still an object though). Leveraging experience with animals is another way to go (it's not either/or). Because every object has a __rib__ cage (inheriting from object), we might say "everything is a snake" in Python (meaning an object with __ribs__). Some snakes quack like ducks though. Kirby

1 0

Re: [Edu-sig] Pass by Reference
by John Zelle 21 May '08

21 May '08

Hi David, I gave a detailed description of my definitions in a post a while back. In that, I referred to the traditional view of a variable as a named location. As per your request: In call-by-value the formal parameter is a local variable whose content is initialized with a copy of the value of the actual parameter. Assignment to the formal parameter has no effect on the actual argument. In pass by reference, the formal parameter is a name bound (by reference) to the variable used as the argument of the call. In this case, assignment to the formal parameter actually changes what is stored in the caller variable. On Wed, 2008-05-21 at 08:41 -0700, David MacQuigg wrote: > Hi John, > > I think what we all agree on is the details of what is happening in > Python. As long as we use unambiguous words to describe that process, > there is no problem. The problem is in the definition of > "call-by-value". I have offered a simple definition, what I called > the "traditional" definition, but perhaps that is claiming too much > priority for one tradition. I'll call it the "common" definition, > what most programmers will tell you, and what you find at > http://en.wikipedia.org/wiki/Call_by_value I'm using the exact same definition of call-by-value as you find in this wikipedia entry. The difference between your view and mine does not turn on the definition of call by value, but rather on what constitutes the "value" of the expression. I'm saying it's clean, simple, and correct to say the result of an expression in Python is a reference to some object. And that reference is what is stored into a variable (which is then still just a named location). You're saying the value of the expression _is_ the object. In your view then, variables contain objects. I often speak along those lines with Python, but in terms of defining the semantics of languages, I think it's cleaner to say that Python variables contain references. That way the term "variable" means the same thing for virtually every language (Prolog notwithstanding). And all of the historical terms still work just fine. In addition, if you look at the Python interpreter, I'm sure there are references (addresses) to these heap-allocated objects running around all over the place, for example in the runtime stack-frames. What do you call the locations that contain those references, if not "variables." That's certainly what they've been called in the traditional programming languages literature for decades now. As for the wikipedia entry on call-by-reference, I find it too ambiguous to say much about, but I can certainly make the case that it agrees with me. What is an "implicit reference to the argument?" In the "canonical" call by reference languages such as FORTRAN and Pascal, the argument to the call has to be a variable (C++ lifts this restriction). The formal parameter then becomes an alias for the same memory location as the argument variable. In essence the formal parameter is a variable that still lives in the caller's stack frame. This is achieved by passing the variable's address "behind the scenes," and the language then specially and automatically dereferences the address to manipulate the non-local variable. That, to me, is call by reference. The reference is being sent _implicitly_ and the language does something special to make it all work. In other words, I reserve the term pass-by-reference as a name for this specific language mechanism, not as a generic term for passing references around in programs. You can pass references around in (virtually) any language, regardless of what parameter passing mechanism the designers provide. As I've pointed out before, I can pass references (pointers) around in Pascal without ever using the pass-by-reference mechanism that's built into the language. And I will have the "visible side-effects" that result from aliasing. But that is not pass-by-reference semantics. In the case of Python, the references are _explicit_. The interpreter doesn't do anything special or different behind the scenes at function call time to grab the address of the argument. All Python variables contain references, and expressions evaluate to references. The parameter passing mechanism just copies the value of the reference from the caller's variable into the formal parameter. The formal parameter is still a local variable in every sense. You know this to be true, because reassigning it has no effect in the caller. I notice that the Wikipedia article tries to have it both ways by saying Java is a "call-by-value language" but "frequently displays call by reference semantics." But there are not two different mechanisms in Java. The _mechanism_ is call-by-value. The call always happens in exactly the same way regardless of the argument type. It just so happens that when the argument is a reference to something mutable, then changes to that mutable thing are visible to the caller, just as in Python, Pascal (non VAR params), C, and any other call-by-value language that allows variables to contain references to heap-allocated objects. By the way, the _lack_ of call-by-reference or a way to simulate it in Java is, to my mind, a design flaw, as it leaves no straightforward mechanism for a function to return multiple values. This is not an issue in Python, which has multiple return values (well, packs and unpacks tuples automatically). I don't know if this helps clarify my position or not. But you asked... --John ps. Here's my acid test. A call-by-reference mechanism allows me to define a swap function: >>> a = 3 >>> b = 5 >>> swap(a,b) >>> a 5 >>> b 3 Show me a Python function that does that and I'll gladly say it has pass-by-reference semantics (or copy-restore :-). > -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle(a)wartburg.edu (319) 352-8360

1 0

Re: [Edu-sig] Pass by Reference
by David MacQuigg 21 May '08

21 May '08

Hi John, I think what we all agree on is the details of what is happening in Python. As long as we use unambiguous words to describe that process, there is no problem. The problem is in the definition of "call-by-value". I have offered a simple definition, what I called the "traditional" definition, but perhaps that is claiming too much priority for one tradition. I'll call it the "common" definition, what most programmers will tell you, and what you find at http://en.wikipedia.org/wiki/Call_by_value I know this discussion is getting very old, but I would like to get just one thing resolved. Can you give us clear and concise definitions of call-by-value and call-by-reference? At 03:59 PM 5/20/2008 -0500, John Zelle wrote: >Hi David, > >It's enough for me at this point that we all agree on what we're talking >about. The rest is a matter of "taste," I think. The one real sticking >point I still have with your approach is simply that what you "expect" >pass-by-value to do in Python (namely make a copy of the object that a >variable refers to) is not to my knowledge implemented in any language. C does call-by-value, at least with primitive objects (according to Kernighan and Ritchie). >Lots of languages have been built around "pass-by-value," and none is >doing what you consider your acid-test for pass-by value. On the flip >side, any language that claims pass-by-reference as part of the language >allows me to do what I consider the acid test for pass-by-reference >(namely I can change the referent of the calling argument), which I >cannot do in Python. I assume by "change" you mean "re-bind", and by "referent" you mean "object". It is possible to modify the object of the calling argument. > So I prefer to use the terms the way they have been >used historically and remain consistent with language design >traditions. I'm finding it hard to understand your terms, perhaps because I'm not familiar with the traditions you refer to. It would really help if we could use the same words for simple things we all understand. Here are my suggestions. variable:(name, pointer) --> object:(type, value, address) re-bind a variable modify an object copy a pointer -- Dave >On Tue, 2008-05-20 at 10:29 -0700, David MacQuigg wrote: >> Hi John, >> >> I did some more searching on this question, and I see it has been discussed many times before. I read a few of the threads, and they seem to go on forever with no resolution, just a lack of communication. It comes down to the definition of "value". One camp says a value is only the actual data in an object, the other says the value can be the reference. I've been using it to mean only the data. >> >> variable:(name, pointer) --> object:(type, value, address) >> >> Looks like this controversy is not just in the Python community. I found a good discussion in Bruce Eckel's Thinking in Java, 2nd ed, Appendix A: Passing and Returning Objects. On p. 1018, he has a discussion of pass-by-value with a nice summary of the views of "two distinct camps". He concludes with "I will attempt to sidestep the issue. In the end, it isn't that important. What is important is that you understand that passing a reference allows the caller's object to be changed unexpectedly." >> >> I think that is what we need to focus on. What will students remember in later years? Which explanation will be most beneficial in helping them avoid problems? >> >> I hope that you will recognize the validity of other views, and not just say they are wrong. I think that is the only way this discussion can move forward. >> >> I wrote a detailed response to your last post, but decided to delete most of it. I'll just leave a few parts where I need to correct a serious misunderstanding of what I am saying. >> >> At 06:36 PM 5/19/2008 -0500, John Zelle wrote: >> >> >You insist on writing/thinking/reasoning as if Python variables >> >"contain" the objects they refer to, but that simply is not the case for >> >the traditional use of the term "variable." >> >> That is not at all what I meant. In my model the variable has only a name and a pointer. The variable refers to an object, but it does not "contain" the object, in the sense that a variable in C is like a box containing a value. >> >> variable:(name, pointer) --> object:(type, value, address) >> >> > Literally, your model, >> >with the traditional definition would require that every assignment >> >statement in Python create a new variable. Consider this sequence: >> > >> >a = 3 # creates the variable "a" >> >a = 4 # "a" is now bound to another location >> >a = 5 # "a" is now bound to yet another location >> > >> >Since the address of the value changes with each assignment, the pair >> >(name, location) is changing each time, and hence we have here three >> >different variables with the same name. That's certainly not the way I >> >think about what's happening in Python! >> >> In my model, the pointer associated with the variable named "a" is moved from one object to the next, leaving the old object for the garbage collector. >> >> >So, my question is why don't we just stick with the traditional notion >> >of a variable being a (name, location) pair. >> >> I've been calling it a (name, pointer) meaning the same thing. >> >> > Realize that Python >> >dereferences the values for us when we use variables in expressions and >> >stop trying to invent new names for a parameter passing mechanism that >> >is identical in function to traditional call by value. >> >> We seem to be coming from different traditions. In my tradition, call-by-value means copying the actual data to the function, and call-by-reference means copying a reference (pointer). These definitions include all possibilities, and lead to simple inferences about safety and efficiency, which is the only benefit I can see for discussing the topic with students who are nowhere near being language theory specialists. The message to my students will be simple - It's like call by reference in C - efficient, but watch out for functions that might modify the objects you send as arguments. >> >> The alternative - like call by value but ... seems a lot more difficult to explain. >> ... but it is efficient, because the "values" being passed are really just pointers. >> ... but it is not safe, because the function can modify the caller's arguments. >> >> When I first learned Python, four years ago, I found the discussion in Martelli's book on call-by-value to be confusing, so much so that it impeded my understanding of the simple mechanism that it really is. This confusion was not resolved until last week when I started researching this question, in response to a student's question in class. I believe that telling students of C that Python is "call by value" will generate the same confusion that I suffered. No amount of explanation, or re-assurance "this is what some experts say" will help. >> >> The examples and diagrams in your section 6.5.2 are excellent. Just for fun, I re-wrote that section keeping everything the same, but changing only the few paragraphs where you talk about call-by-value. In my humble opinion, that section is shorter and much more clear from a "call-by-reference" point of view. It avoids having to say that the "values" of variables are actually the pointers, not the data. It avoids introducing more complex definitions (e.g. "call-by-reference" means that assigning a value to a formal parameter changes the value in the calling program. That's a result, not a definition, and the result depends on unrelated details of the language, like re-binding semantics.) It avoids the awkward "Isn't that interesting?" paragraph where you have to explain that in some cases you really can change the caller's object after it has been passed by value. >> >> I'm not saying your definitions are wrong, I just don't see the benefits of adopting these more difficult and more specialized definitions. Being consistent with some language theorists is not a benefit if it confuses students. >> >> -- Dave

1 0

Re: [Edu-sig] Pass by Reference
by Warren Sande 21 May '08

21 May '08

I would argue that from a "functional" point of view (black box, the way it behaves), Python does behave like call-by-reference, for mutable types. In another language, if I use call-by-reference, and the function modifies the variable, the caller's variable changes. That's the same behavior I get in Python with mutable types (just as in John Posner's example). I understand that it is not truly call-by-reference. But from the outside, that's what it looks like, for mutable types. For immutable types it looks like call-by-value, since changing it in the function does not change the caller's "copy" I definitely agree that Python is the best choice for a first language. But there is this one inconsistency (or maybe call it a duality) of mutable vs immutable types, that I think can be a bit confusing. Putting aside the "pass-by-X" question, a beginner asks: "If I do A = (something) then B = A then I change A, does B also change?" And the answer, again, is "It depends." For mutable types, yes, for immutable types, no. And that's a sticky thing to get into for a beginner who is just learning what variables (names) are about. >>> a = 5 >>> b = a >>> a 5 >>> b 5 >>> a = 7 >>> a 7 >>> b 5 >>> a = [8] >>> b = a >>> a [8] >>> b [8] >>> a.append(9) >>> a [8, 9] >>> b [8, 9] I know that in the first case, you are not really "changing" a, you are attaching the name 'a' to a new object (7, instead of 5). But that's not what it looks like from the outside. It looks like you are changing a, and b is not changing. In the second case, you are changing a, and b is changing. I'm not saying the memory model is inconsistent, just that it can appear that way to a beginner. And I think that's true whether they have had exposure to another language or not. Respectfully, Warren Sande ----- Original Message ---- From: John Zelle <john.zelle(a)wartburg.edu> To: Warren Sande <warren.sande(a)rogers.com> Cc: edu-sig(a)python.org Sent: Tuesday, May 20, 2008 1:49:56 PM Subject: Re: [Edu-sig] Pass by Reference Hi All, OK, really, this is my last post (on this topic). On Tue, 2008-05-20 at 08:59 -0700, Warren Sande wrote: > Agreed. > > Python "behaves like" call-by-value for immutable types and "behaves > like" call-by-reference for mutable types. Newbies care about how a > thing behaves, not what's going on behind the scenes. This is not really an accurate characterization. As I explained in my previous post, Python never behaves like call-by-reference. Python always and everywhere (not just in parameter passing) behaves like a language where variables store references to objects (and happens to use call-by-value for parameters). I agree that newbies need not even be engaged in the terminology discussion. > Because understanding the behavior lets them write working programs. > This seemingly inconsistent behavior is one thing that makes teaching > with Python a bit more difficult. Here I can't agree at all. The beauty of Python for newbies is that it offers you one consistent memory model for assignment, parameter passing, and everything else. This makes it unlike many other languages that have multiple, often confusingly different mechanisms. I find it much better as a first language. > Beginners want the answer to the question: "If I pass something to > a function, can the function change it or not?" And the answer is, > "It depends." That's not a great answer for a beginner. But again, this has nothing to do with functions AT ALL. The answer to the question of "can I change it?" Is always and everywhere in Python: "You can if it's a changeable (mutable) object." This has very little to do with parameter passing. I'm more and more convinced this is only a confusion for those of us who cut their teeth with languages that employ other memory models. Of course, there's no need to confuse (true) beginners with those other models. They'll only be confused if we present a confusing picture. If you're teaching (or writing for) students who might have already encountered some other languages, then there's some explaining and comparison to do. But the thing that needs to be explained is that all "values" are heap-allocated objects, and variables _always_ contain a reference to one of these. Again, don't confuse this important and cool difference with notions about how parameters are passed. --John > > > ----- Original Message ---- > From: John Posner <jjposner(a)snet.net> > To: edu-sig(a)python.org > Sent: Tuesday, May 20, 2008 10:50:38 AM > Subject: Re: [Edu-sig] Pass by Reference > > > ... and stop trying to invent new names for a parameter passing > mechanism > > that is identical in function to traditional call by value. > > > > Yeah, but ... it will be difficult to stick to a call-by-value > characterization when confronted with this example, which is straight > from > "Call by Reference 101": > > def AddArtist(mylist): > mylist.append('TheOtherTerry') > > >>> troupe > ['Graham', 'John', 'Eric', 'Michael', 'Terry'] > > >>> AddArtist(troupe) > > >>> troupe > ['Graham', 'John', 'Eric', 'Michael', 'Terry', 'TheOtherTerry'] > > > Most students (especially newbies) won't care about what happens under > the > hood -- not at first. If it looks like a duck, walks like a duck, and > quacks > like a duck ... > > -John > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle(a)wartburg.edu (319) 352-8360

4 3

Re: [Edu-sig] Pass by Reference
by John Posner 21 May '08

21 May '08

> > OK, really, this is my last post (on this topic). > Shall we let Lewis Carroll have the last word? ... 'You are sad,' the Knight said in an anxious tone: 'let me sing you a song to comfort you.' 'Is it very long?' Alice asked, for she had heard a good deal of poetry that day. 'It's long,' said the Knight, 'but very, VERY beautiful. Everybody that hears me sing it--either it brings the TEARS into their eyes, or else--' 'Or else what?' said Alice, for the Knight had made a sudden pause. 'Or else it doesn't, you know. The name of the song is called "HADDOCKS' EYES."' 'Oh, that's the name of the song, is it?' Alice said, trying to feel interested. 'No, you don't understand,' the Knight said, looking a little vexed. 'That's what the name is CALLED. The name really IS "THE AGED AGED MAN."' 'Then I ought to have said "That's what the SONG is called"?' Alice corrected herself. 'No, you oughtn't: that's quite another thing! The SONG is called "WAYS AND MEANS": but that's only what it's CALLED, you know!' 'Well, what IS the song, then?' said Alice, who was by this time completely bewildered. 'I was coming to that,' the Knight said. 'The song really IS "A-SITTING ON A GATE": and the tune's my own invention.' -John Posner

1 0

Re: [Edu-sig] Sticky-note Analogy
by John Posner 20 May '08

20 May '08

> Partly why it's misleading to speak of names as variables is > that shoptalk tends to prevent us from seeing 8 as the *name* > of an immutable object, one for which the name is hardwired > (but feel free to bind, or assign, other not-spoken-for names > to the same object). I don't see the advantage of thinking of "8" as a name. It's just some syntax that creates an unnamed object. In that sense, all of these are similar: 8 8 + 3 Rod(length = 9, color = 'blue') In all these cases, the resulting object gets a name only if it's the RHS of an assignment. If not, the object disappears (from the user's viewpoint, anyway) as soon as the containing statement/expression is executed. Also, what do you say to the student who points out that "8 is a name" violates the rule that Python names must begin with a letter or underscore? -John

8 19