why cannot assign to function call

[Aaron Brady]

On Jan 14, 3:51 am, Mark Wooding <m... at distorted.org.uk> wrote:
> Aaron Brady <castiro... at gmail.com> wrote:
> > On Jan 13, 5:06 pm, Mark Wooding <m... at distorted.org.uk> wrote:
> > snip
> > > I'm going to move away from the formal semantics stuff and try a
> > > different tack.  Here's what I think is the defining property of
> > > pass-by-value (distilled from the formal approach I described earlier,
> > > but shorn of the symbolism):
>
> > >   The callee's parameters are /new variables/, initialized /as if by
> > >   assignment/ from the values of caller's argument expressions.
>
> > In other words, the same as assignment in that language.
>
> It's the same as assignment of /values/ to /fresh variables/.  It's
> important to specify that argument expressions are fully evaluated, and
> that nothing gets overwritten in the process.
>
> So the difference between Python and C is that C copies values during
> assignment, but Python doesn't.  Therefore the argument passing works
> the same way.

That interferes with Joe's claim that the value of a variable is a
memory address.  I think you'd have better luck sticking with "pass-by-
assignment".

A Java reference and a C++ reference are different things, somewhat
regrettably.

> > > Because its argument passing works the same way as its assignment.
>
> > That would be called pass-by-assignment.  But you've just postponed
> > explaining yourself.  Stop delegating and work.
>
> Huh?  I'm really at a loss to know what you want me to do.

You were remarkably civil about that.  I regretted it as soon as I
sent it.  You keep wanting to say "but it's just a reference, it's
just a reference".  But all that does is put more burden on the fellow
that explains what a reference is.  It took me years to grasp
pointers... possibly all the way up until comp. architecture class.
(As such, I find you're shirking.)

> I can't help it if people are confused over the phrase `pass-by-value',
> beyond trying to explain what it means using clear definitions.  The
> `value' part means that argument expressions are /evaluated/ (turned
> into values), which forces applicative-order semantics rather than (say)
> normal-order.

I can't believe it's taken this long, including October's discussion
(<name dropping> and especially with my dual (not duel, ha!) in
Philosophy </dropping>), but I'd finally like to quote the manuals.

"An object's identity never changes once it has been created."
"The value of some objects can change."
- http://docs.python.org/reference/datamodel.html

Therefore, an object's value is not its identity.  (Its identity is
something other than its value.)  You might get away with 'pass-by-
identity'.

After 'X= [1, 2, 3]', X refers to an object.  You can change two
things: (1) the fact that X refers to that object, (2) that object.

In 'X= None' and 'del X', you change the fact that X refers to that
object.  In 'X[:]= [4, 5, 6]' and 'X.pop()', you change the object.

Explanatory note: It really takes two sentences to say that.  'X
refers to an object.  You can change the object, or change the fact
that X refers to it.'  If you try to say it in one sentence, the
distinction collapses:  'You can change (1) the object that X refers
to, or (2) the object that X refers to.'  Irony!

'X' is a key in a namespace.

namespace[ 'X' ]= [1, 2, 3]
namespace[ 'Y' ]= namespace[ 'X' ]
del namespace[ 'X' ]

No matter how hard you try, if you don't have both of two things,
'namespace' and '"X"', you can't change namespace[ 'X' ].

And back to the OP (long since gone, naturally): You can do:
f()[:]= [1, 2, 3]
As well as:
f().replace( [1, 2, 3] )
As well as:
f().contents= [1, 2, 3]

The particular thing s/he wanted isn't one of these.

Lastly, I think it would do you and Joe good to ignore some details,
when thinking about beginners.