why cannot assign to function call

[rurpy at yahoo.com]

Mark Wooding wrote:
> rurpy at yahoo.com <rurpy at yahoo.com> wrote:
>
>> If one accepts that there are a "lot" of people who post in here that
>> clearly are surprised by Python's assignment semantics,
>
> But one should not accept that.  One might accept that there are many
> who post who claim that they are surprised by Python's assignment
> semantics.  Such people are wrong, however, since what they are
> surprised by is Python's data model, and one reason that they are
> surprised by Python's data model is because it's not actually explained
> very well.

Agreed.  I think the docs, especially those that develop
the conceptual model of how Python work at runtime, could
use some major attention.

>> and further appear to expect assignment to have copy-like semantics,
>
> This expectation is justified and, indeed, satisfied.  Python does, most
> definitely, copy on assignment.  What it copies is references, however.
> This might be clearer if the data model were explained better.
> ...
>> 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."
>
> Because they've fundamentally misunderstood the data model.  The very
> fact that their confusion is ascribed to the wrong thing is strongly
> indicative of this.
>
>> 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?
>
> But it's not just assignment that deals with references.  It's argument
> passing and storage of compound data as well.  (See PLR 3.1.)
>
> They expect that assignment copies stuff, because that's what assignment
> does.  Everywhere that I can think of -- except C++, which leaves
> assignment semantics in hands of the programmer.  What they're confused
> about is what, precisely, it is that gets copied.  And that, really, is
> a result of an inadequate understanding of the data model.
...
>> 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.
>
> That's why I'm not just saying that assignment is the same.  I'm also
> saying that the data model is most definitely not the same as C.

I would be willing to bet that most of the confused
posters do not distinguish between assignment operation
(AO) and data model (DM).  Their conceptual box is
labeled "assignment behavior" and includes both AO and
DM.  They expect that AO+DM in Python will produce the
same results in Python as they are used to in the other
languages they've used.  That the discrepancy comes from
the DM part rather than the AO part is pretty irrelevant
to them given that world view.

So responding to the cry, "Python assignment is bizarre!"
with an indignant, "No, it is the same as other common
languages", is talking with different vocabularies, unless
it's also accompanied with all the other information presented
in this thread about how Python treats all names as references
(which *is* different that some other languages).

I notice there is not even an FAQ on the subject of assignment
despite the frequency which which people ask about it.

>> 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.
>
> Probably.  But I think the idea was actually inherited from BCPL, via B.
> In BCPL, memory is divided into words.  Depending on which operator you
> use, you can treat a particular word as an integer, a floating-point
> number, or a pointer.  An array in BCPL is represented as a pointer to
> its first element -- always -- and you index it by an expression of the
> form p!i (a notation inherited by BBC BASIC and Haskell of all things).
> The array->pointer decay is a compromise position between the BCPL
> notion of array-as-pointer and the desire to allocate such things with
> automatic storage duration and have sizeof and so on work properly.

Interesting tidbit, thanks.