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
