On Fri, 06 Jan 2006 20:49:06 +1100 "Steven D'Aprano" <[EMAIL PROTECTED]> wrote: > On Thu, 05 Jan 2006 22:18:39 -0600, Terry Hancock wrote: > >> Consider this: > >> > >> def do_nothing(x): > >> pass > >> > >> huge_tuple = (None,) * 10000**4 > >> do_nothing(huge_tuple) > >> > >> If Python made a copy of huge_tuple before passing it > >to > the function, you would notice. > > > > Which succinctly demonstrates precisely why a newbie > > *should* be told that Python passes references instead > > of values. > > "I don't like Chinese food, and pizza gives me gas. Let's > have a burger," says I. > > And Terry helpfully answers: "Pizza gives you gas? Well > there you go then, that's precisely why we have to have > Chinese food."
An annoyingly banal, off-topic, and incorrect analogy. > I have never suggested that we should tell newbies that > Python is call by value, and I deny that the only two > possible choices for usefully describing Python's > behaviour is by CBV and CBR. The fact that Terry could > read this thread and still imagine that there is such a > dichotomy is worrying. I didn't say you did, and it's very worrying that you could read my post and not understand that. You want to get tetchy? I can *be* tetchy, if that's what you want. ;-) As far as I am concerned "call by object" which is what you *did* propose implies "call by value" to anyone who is just learning the language, and that is the audience we're talking about. I mean, *I* know what you mean when you say "Python is 'call by object'" just as *you* know what I mean when I say "Python is 'call by reference'", but where does that leave Mr. Newbie? Sorry, but the burgers give him gas, too. > > But it should probably also be made clear that > > "reference" means a label assigned to an object, and not > > a variable containing a memory location (which is what a > > C "pointer" is). > > > > The reference is usually a simple name, but it can also > > be an container expression following list, dictionary, > > or class instance (spam, spam[0], spam['eggs'], or > > spam.ham, for example). Not tuple or string because > > they are immutable, and so don't have assignable > > references. > > Are you seriously suggesting that you can't include tuples > in a list, or pass them to functions? Because that's what > it sounds like you're saying: "Python passes references. > The reference is usually a simple name, but it can also be > a container... Not tuple or string because they are > immutable." > > If you don't mean to say that Python can't pass strings to > functions, what do you mean to say? No, don't be intentionally thick. I mean that you cannot dereference a string or tuple in order to assign elements of them -- which is another way of saying they are immutable. > I'll tell you what I say: Python passes objects to > functions or assignments. > > Does this mean that the object is copied? No, I didn't say > it copies objects. I left the nature of the passing > mechanism unspoken, which is how it should be because it > is an implementation detail. And that is where we part ways, my friend. Because "implementation details" do matter when they make a difference between execution in 10 seconds and executions in 10 days. Even a newbie is going to be hesitant to do things that look like they are going to do the latter. He still needs to have a reasonably correct mental model of what his program is going to do. > Does this mean that the object can be modified in place? > Certainly not, since that depends on the object, not on > the nature of Python's high-level behaviour. It emphasises > the object oriented nature of Python, and by its very > language warns the reader not to assume that Python > behaves identically to other languages. It invites further > questions, rather than lulling the reader into jumping to > false conclusions. Chigaimasu! It just leads to *different* false conclusions. > The emphasis is on the *object*, not the passing > mechanism.[...] > In Python, whether or not you can change an object depends > on the object, not the language itself: it is a data > issue. True, but the passing mechanism still makes a difference in understanding how Python programs operate. Of course, this conversation is starting to get extremely silly. Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- http://mail.python.org/mailman/listinfo/python-list