why cannot assign to function call

[rurpy at yahoo.com]

Joe Strout wrote:
> rurpy at yahoo.com wrote:
>
>>>>   a = array (1,2,3)
>>>>   b = a
>>>>   a[1] = 4
>>>>   print b
>>>>
>>>> C, C++, VBA, Fortran, Perl:  1, 2, 3
>>>> Python:  1, 4, 3
>>> You are mistaken
>>
>> I don't think so.
>> See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f869b96
>> The code I quoted there was tested.
>> In the C/C++ case, array-to-pointer coercion confuses
>> the issue so I embedded the array in a struct which
>> is more like an "object".
>
> No, that's cheating (IMHO).  Structs used directly (rather than via
> pointers) are the odd beast, and while they're certainly possible in C,
> they are far from the normal idiom.  And certainly embedding an array in
> a struct just to force it to be copied, avoiding the standard reference
> semantics, is an arbitrary trick.

It was intended as a purely rhetorical device to
avoid requiring a lot of verbiage to say why a
struct example is used for C and arrays for the
others and why that makes no difference to my point.
Actually, the whole code/results thing was purely
for effect since I presume most people reading already
understand how assignments work in these languages,
or that least that there are significant languages
using copy-like assignments.

> I never claimed that you *couldn't* have copy semantics in C; you can do
> almost anything you want in C (or C++).  But the *normal* usage of an
> array is via a pointer, in which case the semantics are exactly the same
> as in Python, Java, REALbasic, .NET, etc.

Arrays are the only datatype in C that don't use
copy-like assignment.  Everything else does.

>>(Keep in mind
>> my point was not to show the behavior of arrays, but to
>> show that several common languages *do not* use Python's
>> "*all* names are references" model -- though of course
>> this does not preclude their having some Python-like
>> assignments since they all have some way of doing
>> references.)
>
> Ah.  OK then, I guess I missed you're point.  You're absolutely right;
> many languages have both reference types and value types.  Python is a
> bit unusual in that it has only reference types.  I would have picked a
> different example to illustrate that, but it's true nonetheless.

If one accepts that there are a "lot" of people
who post in here that clearly are surprised by
Python's assignment semantics, and further appear
to expect assignment to have copy-like semantics,
then where is that expectation coming from?

How would anyone develop that expectation if (from
a different post in this thread), "[Python's] idea
of assignment is the same as anyone else's."

If you maintain that reference-like assignment
is very common and something every programmer is
accustomed to, then where are they getting the
copy-like assignment expectations from?

I agree that most of the time, when one is using
large (memory) composite "objects", and one needs
to pass, or access them by different names, one will
often use references to do so in order to avoid
expensive copies or to get desired "shared" behavior.
But (with the exception of C arrays [*1]), doing so
requires some special syntax in all the languages I
mentioned (AFAIK).

So it still seems to me that this is a likely
explanation to why there is frequent misunderstanding
of Python's assignments, and why responding to such
misunderstandings with, "Python's assignments are
the same as other languages'", is at best not helpful.

[*1]
I have often wished that C handled arrays the same
way it does structs.  I am sure that the pointer-array
pseudo-equivalence seemed like a very clever idea at
the time but I wonder if Dennis Richie ever had second
thoughts about it.