why cannot assign to function call

Derek Martin code at pizzashack.org
Fri Jan 2 11:39:15 CET 2009


On Tue, Dec 30, 2008 at 02:21:29PM +0000, John O'Hagan wrote:
> Fortunately, unlike the murky world of philosophy, Python (AIUI)
> simplifies this question by simply declaring that yes, in the case
> of mutable objects, we may say that we are still referring to the
> same object although we've changed it, and no, in the case of
> immutable objects, we may not, and must exchange it if we want a
> different "value" (a word too fraught with ambiguity in this context
> to use unquoted!).

That's sort of true; it would seem to be more accurate to say that
whenever a name is assigned to an object and subsequently reassigned,
the name no longer is associated with the original object.  In the
case of mutable objects, the object can be changed by performing an
assignment of *part* of the object through its original name, i.e.
strings may be mutable, but the following code still produces two
different objects:

  a = 'hello'
  a = 'goodbye'

The first object so created is orphaned; it's been given the Russian
non-person treatment.  It still exists, but the authorities (i.e. the
python interpreter) don't acknowledge it and provide the rest of the
world no way to communicate with it, and eventually it is reaped by
the garbage collector. :)

What the Python community often overlooks, when this discussion again
rears its ugly head (as it seems to every other hour or so), is that
its assignment model is BIZARRE, as in it's conceptually different
from virtually all other languages substantially taught in
undergraduate computer science programs.  And for that matter, it's
pretty unintuitive generally.

That is, in what I'll call "normal" computer languages, a variable
name is thought of as the address of a bin where some data is stored,
and the name is inexorably tied to that bin.  You can change what's in
the bin, but the name you gave the bin always points to the same bin.
This tends to be conceptually true even if it might technically not be
true in a given implementation of a language.

Python is very different from this.  Names are not addresses of bins;
they are instead simply ephemeral labels which are given to bins,
where the bin is a Python object which contains specific data at the
time of assignment.  A second assignment of that name doesn't change
what's in the original bin; it actually (probably) first creates a new
bin, then removes the name from the original bin and assigns it to 
the new one.  Intuitively, it's a bit like saying your kitchen table
is no longer a kitchen table, and now the thing where you wash your
dishes is a kitchen table.  It doesn't really make a lot of sense
(whether or not it's so for good reason), and it makes describing the
assignment model necessarily convoluted, whereas the "named bins"
model from the majority of other languages people are likely to have
been exposed to is simple and sensible.  

It's small wonder that neophytes try to cram Python behaviors into
terms and computing concepts they already understand from learning
other languages, and that they fail to do so.  What's mystifying is
that when Pythonistas reply to their messages, they universally seem
confused at how this could possibly happen, and often enough actually
seem offended (or at least offensive) when it inevitably does happen...

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20090102/5a781ec1/attachment.pgp>


More information about the Python-list mailing list