why cannot assign to function call

[Dan Esch]

Wait a sec...

I think I get this...

In essence, the implication of immutability for Python is that there is only
one "parrot", one "spam,"in fact one anything. (This seems like it must hold
for data primitives - does it hold for complex objects as well? It seems it
must...) In addition there is only one 1, and one 2 etc.  We may or may not
have realized that string in a memory address to which variable names can be
bound, but should we do so, there is only one "parrot"

Python, is in fact, a Platonic programming language.  Weird.  If I've got
this right, worth chewing on....


On 1/2/09, Derek Martin <code at pizzashack.org> wrote:
>
> 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
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090107/56806e98/attachment-0001.html>