I think in an Intro to Programming course featuring Python or not, it'd make sense to talk a lot about this new use of the equality symbol ( = ) and how language designers have felt about it (suspicious in some cases).
In APL, a left pointing arrow was used. PL/1 used := as I recall. What other symbols for "assignment"? Class project, to collect? In math books, they sometimes write out Let x =, which has that imperative flavor, that commanding tone (who is x to fight back anyway, variables so pliable, whereas in CS we have to "allocate memory" meaning the department might give us a budget, at least in the old time share days, getting "an account" i.e. CPU time, was considered a real privilege, so any "x =" is ultimately gonna cost ya, in adding to a namespace (a finite resource)). In any case, there's that big gulf between asserting these two are equal, versus the one on the right giving new information to the one on the left, passing something on, in a specific direction. So what gets passed on? A beginner seeing x = y = z = 8 won't know if that's in Python or what (nor will an expert for that matter, until a context is provided). In Python, x = y = z = 8 says the information on the whereabouts of 8 is trickling through this pipe and collecting in pools z, y, and x respectively. After this transaction, z, y and x have no ongoing relationship with one another. This is true regardless of whether 8 is an integer, or some mutable object *disguised* as an integer (pretty clever disguise, not legal in Python). The model I've been using is: I'm walking the dog, then hand you a leash. Now we both have a leash to the same dog. A problem with this imagery is it keeps you and I in proximity, as "walking the dog" is a "crowding together", something that moves us along the sidewalk, tethered to a four-legged. 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). In the shoptalk of mathematicians, both the leash and the post-it analogy imply a "metric" i.e. give us a strong sense of the physical distances involved. The idea of an astronaut floating in space, connected by a long cord to the space station, shuttle, other craft, is a step closer to the imagery we're seeking. Where I ended up earlier is with this idea of a website address, a pointer through the Internet to something with an IP number, similar to a Python memory id number, as in id( x ). We think more clearly only about the topology then, realize right off the bat we have no way of knowing what physical distances might be involved, so best to not imagine them. When I go y = x in Python, it's like x emailing a web address to y. x doesn't lose any information in sending that URL and y may later rebind to something else, but so long as x and y share the same URL, they both look at the same website. They *do not* look at each other however. The assignment operator ( = ) triggers a fleeting ocurrance, an event, a hand-off (except the provider hands off a duplicate -- this is "copy" not "move" (what true beginners are likely familiar with, given at least minimal GUI-based file management experience)). Given we're mostly seasoned programmers in this group, write code for a living, for school, for industry, we might not remember how odd this new use of = might have seemed at first. To a chemistry major, = looks a lot like a double bond. To a mathematician, = might look like an assertion of some eternal relationship. 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. More like mitosis than anything, in that one variable became two. And so on. All that being said, after x = y, x and y *do* have a sameness we can check, in that both now fit the category of "pointing to object X". That's what the "is" operator is for in Python as in x is y (returns True). "==" is for something else again, and triggers the __eq__ rib. We know what == means in the case of integers, string objects, but it's up to the programmer to apply spin for programmer-defined objects, by writing code for that special name (or not -- nothing much is mandatory in Python, which we like). Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
