On Jan 14, 3:51 am, Mark Wooding <m...@distorted.org.uk> wrote: > Aaron Brady <castiro...@gmail.com> wrote: > > On Jan 13, 5:06 pm, Mark Wooding <m...@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. -- http://mail.python.org/mailman/listinfo/python-list
