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
pgp6S7INF1qUN.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
