why cannot assign to function call

[Lie]

On Jan 5, 9:03 am, Derek Martin <c... at pizzashack.org> wrote:
> On Sat, Jan 03, 2009 at 10:15:51AM +0000, Marc 'BlackJack' Rintsch wrote:
> > On Fri, 02 Jan 2009 04:39:15 -0600, 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.
>
> > What's the difference between Python and Java or C# here!?  Or are they
> > also "BIZARRE"!?
>
> I am happily ignorant of C#.  As for Java, take the following code:
>
>   a = 6;
>   a = 5;
>
> In Python, when you execute the equivalent code, it causes two
> different objects to spring into existence, the first of which may be
> cleaned up by the GC (except that since we're using small integers,
> that's not likely to happen).  Unless I'm misinformed (which is very
> possible, my experience with Java has been extremely limited) in Java
> that's not the case...  the storage is allocated to the name a when
> you execute its declaration, and the *same storage* is reused upon
> subsequent assignment.
>
> That behaves exactly like named bins.
>
> > > And for that matter, it's pretty unintuitive generally.
>
> > Names and objects are quite "natural" IMHO.  There are many real world
> > objects which we attach one or more names to, or refer to in sequences
> > like "please give me the third book on that shelve" (``shelve[2]``).
>
> Indeed, but the way we assign names to them does not behave as it does
> in Python.  Nor does Python's assignment work like it does in algebra,
> or anywhere else the Python student is particularly likely to have
> seen variable assignment before encountering it in Python.  Let's
> define intuitive, shall we?  From dictionary.com (choosing the
> definition which most easily makes my point):
>
>   intuitive: adj.  capable of being perceived or known by intuition.
>
> I'm going to go out on a limb and assert that there's NO POSSIBLE WAY
> a student could intuit Python's variable assignment behavior, having
> never been exposed to that same behavior prior.  It needs to be
> taught.

Which limb would you like to go with?

> > > 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 just call that "normal" or "intuitive" because that's what you
> > learned first.
>
> In a sense, yes... but isn't that what intuition really is?  You can
> figure something out whithout being told how it works...  That's
> either because it's immediately obvious from observing it, or it
> behaves like something you've seen before.  That is what intitive is.

No. You've just said it yourself, something is intuitive if "it
behaves like something you've seen before". People have different
experience, people deeply involved in mathematics would see "named
bin" is the obvious thing to go, however commoners (including
mathematician) will have different say: "Derek is the name of a human
object" instead of "Derek is a specific collection of atoms that
resembles human".

This is also why python community tend to avoid the use of "variable",
because python's name doesn't behave like variables in mathematics, it
behaves like "name". (heck, one would argue that even "variable" in
programming is not exactly the same as "variable" in mathematic
either)

> > I think the "bin model" is more complex because you don't just have a
> > name and an object but always that indirection of the "bin".
>
> I cheerfully disagree. :)  "Named bins" is essentially how algebra
> works, and how several generations of computer languages, not to
> mention the actual machine language those generated, behaved, before
> the current crop.  Those interpretations came first, because, much as
> in the evolution of any other science, that was the model which was
> most intuitive or easily explained.

No, it is neither the most intuitive nor easily explained, but indeed
it is the simplest to implement as humans at that time have limited
capability to design chips. In the early days, ease of use is not a
priority, simplicity is.

> But you need not take my word for it.  Simply read the archives and
> see for yourself how much confusion this has caused on this list.
> [Please include the closely related behavior of parameter passing in
> your search.]

The first time I used python, I didn't have any idea how the object
model works, and I don't have experience in similar programming
concept nor was python my first language, yet I have no difficulty in
understanding why things goes like it is. For me, at least, python's
object model is intuitive (do you remember about the limb?).