why cannot assign to function call

[Steve Holden]

Derek Martin wrote:
> On Tue, Dec 30, 2008 at 02:21:29PM +0000, John O'Hagan wrote:
[...]
> 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.
> 
I'd definitely argue against bizarre. It's actually very easy to
understand, and Python is by no means the only language to have used it.

> 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.
> 
I'd argue that this approach is out of date and overly-restrictive,
requiring data copying not required by the Python data model and running
the risk, in the absence of such copying, of returning invalid
references (the C++ "dangling pointer" issue being the best-known
manifestation of such problems).

> 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.  
> 
I'd instead say that Python uses ephemeral names for long-lived objects,
where other languages use the addresses of ephemeral objects. Your ideas
of "simple" and "sensible" are being conditioned by your experience.

> 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...
> 
Generally speaking we try not to be offensive first on this list.

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/