andrew cooke wrote: > Steven D'Aprano wrote: >> On Mon, 23 Feb 2009 08:14:34 -0300, andrew cooke wrote: >> >>> Steven D'Aprano wrote: >>>> On Sun, 22 Feb 2009 13:37:27 -0300, andrew cooke wrote: >>>> >>>>> as far as i understand things, the best model is: >>>>> >>>>> 1 - everything is an object >>>>> 2 - everything is passed by reference >>>> >>>> Except that is wrong. If it were true, you could do this: >>> [pointer swapping] >>> >>> i was thinking of how the stack is used; i would have called what you >>> are talking about "pointer semantics". however, on reading around a >>> little, it seems that i'm in a very small minority (which is a pity, >>> because if you restrict the meaning to how values are handled on the >>> stack then you get a lot closer to having just values and references, >>> rather than the whole pile of different terms that are apparently in >>> use). >>> >>> sorry for the confusion, >> >> Why is it a pity to have a whole pile of different terms to describe a >> whole lot of different behaviours? I would suggest the real confusion >> would be if we had two terms to describe a dozen different parameter- >> passing conventions. > > because: > > (1) it's often useful to explain things as (simpler) orthogonal components > rather than globbing everything under one term;
"One term"? If you look at this Wikipedia page: http://en.wikipedia.org/wiki/Evaluation_strategy you should be able to count no fewer than thirteen different terms for different evaluation strategies, and "call-by-value" itself is described as a family of strategies. Who is gobbing everything under one term? Certainly not me. If anything, your preferred tactic is to gob everything under one of two terms, call-by-value and call-by-reference. That's not my preferred tactic. > that lets you more easily > carry across knowledge from previous experience. That's only useful if that previous experience *clarifies* rather than *confuses*. This very thread demonstrates that people's prior knowledge of call-by-whatever doesn't clarify Python's behaviour. > (2) while using a term that has (according to wikipedia) "widespread usage > in the Python community" helps you save time and avoid confusion, it > doesn't necessarily explain best to someone from outside that community > what is happening. And you think call-by-reference does? Python demonstrably does not behave like call-by-reference in other languages. I do not agree that it is wise to hammer the round peg of Python's actual behaviour into the square peg of newbies' concept of call-by-reference. > in this particular case you are getting dangerously > close to having a term that is used only for one language So what? What if Python was the only language that used the term? That doesn't make it inappropriate. If the users of other languages that use call-by-object semantics (Java, RealBasic, etc) choose to prefer a misleading name over a descriptive name, that's no reason for Python users to follow down their path. > and which, > therefore, is at risk of meaning little more that "the way python does it" > (which is, i think you'll agree, more tautological than helpful). No at all. Do you imagine that call-by-name means "the way Algol does it"? Algol is the only major language that uses call-by-name, it may even be the only language of any size, but that doesn't mean that call-by-name can't be defined and described independently of Algol. There's even a test, Knuth's "Man Or Boy Test", for testing how well a language implements call-by-name semantics. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
