why cannot assign to function call

[Steven D'Aprano]

On Sun, 04 Jan 2009 20:03:11 -0600, Derek Martin wrote:


> 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.

In the case of Java, that's because Java uses two assignment models: 
named bins for "primitives" like ints and floats, and the Python model 
for class instances, which is *nearly* everything in Java except a few 
primitive types.



>> > 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.

It doesn't? 

Oh my, you're going to be confused in a few weeks when The President of 
the USA ceases to be George W Bush and becomes Barack Obama. Same name 
(or rather, title), different object (person).



> Nor does Python's assignment work like it does in algebra,

Nor does any programming language, with the possible exception of 
computer algebra systems.


> 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.

Unless they've used Java, Perl, Ruby, or any number of other languages.

> It needs to be taught.

Exactly the same as the named bins assignment model needs to be taught.

But, really, you're exaggerating the differences. There are differences 
of course, but for somebody writing a simple programming with (say) 
mathematical expressions, there's little or no difference between the 
models.

x = 4
if y > 2:
    x = x-1
else:
    x = x+1
print x+y

will have the same effect whether you are using the named bins model or 
not.



[...]
> I cheerfully disagree. :)  "Named bins" is essentially how algebra
> works, 

I don't think so. Variables in algebra are quite different from variables 
in programming languages. Contrast the statement:

x = x+1

as a programming expression and an algebraic equation. As a programming 
expression, it means "increment x by one". But as an algebraic 
expression, it means "x is some value such that it is equal to one more 
than itself", and there is no solution to such an equation.

In algebra, a variable name (like x, or c) generally represents one of 
three things:

(1) an an unknown quantity to be solved for;

(2) a constant (either a known constant, or an arbitrary parameter); or 

(3) an alias, such as when you do a change-of-variable.

One thing which algebraic variables are not is a bucket or bin that you 
can set to some value, then modify over and over again.


> and how several generations of computer languages, not to mention
> the actual machine language those generated, behaved, before the current
> crop.

Sure. And?

> 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 no no no. That was the model that was most easily implemented!

Before the named bins model of assignment was pure machine code, where 
you didn't have bins at all, just bits, and there was no distinction 
between code and data. And before that was *wires* -- early programmers 
literally had to plug and unplug wires to change the state of the 
computer. And before that were purely mechanical devices, such as the 
Enigma Machine, old calculators, and the grand-daddy of them all, Charles 
Babbage's difference engine and it's precursors.



> 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.]

In my opinion, the cause of that confusion is nothing to do with Python's 
assignment model, and everything to do with the instance of some people 
to use named bins terminology when describing the Python model. If you 
keep the named bins terminology for describing the named bins model, 
you're fine; and if you keep the name/object terminology for describing 
languages with names/objects, you're fine. You only run into trouble when 
you mix them. That's when you get people confused because "Python is Call 
By Something, but it doesn't behave like Call By Something in language 
Foo I've used before".


-- 
Steven