[Steven's message hasn't reached my server, so I'll reply to it here. Sorry if this is confusing.]
Aaron Brady <castiro...@gmail.com> wrote: > On Jan 8, 1:45 am, Steven D'Aprano > <ste...@remove.this.cybersource.com.au> wrote: > > On Wed, 07 Jan 2009 10:17:55 +0000, Mark Wooding wrote: > > > > > The `they're just objects' model is very simple, but gets tied up in > > > knots explaining things. The `it's all references' model is only a > > > little more complicated, but explains everything. > > > > But it *over* explains, because it implies things that "everybody knows" > > about references in other languages that aren't true for Python. I addressed this elsewhere. Summary: `pass-by-reference' is a different thing to `all you manipulate are references': Python does pass-by-value, but the things it passes -- by value -- are references. (The `pass-by-*' notions are confusingly named anyway. Pass-by-name doesn't actually involve names at all.) > > Of course it's not literally true that "everybody knows" that you > > can use references to implement a swap(x, y) procedure. But people > > coming from a C or Pascal background tend to assume that everything > > is like C/Pascal, and there are a lot of them. If C was a rare, > > unfamiliar language, my opposition to using the term "reference" > > would be a lot milder. Maybe in another five years? I agree with the comment about Pascal, but C is actually pretty similar to Python here. C only does pass-by-value. If you want a function to modify your variable, you have to pass a pointer value which points to it. Python has no pointer values, so you need a different hack. The hack usually involves lists. (Though it's easier in the main to return compound data objects like tuples. I don't suppose that a proposal for true multiple return values would go down well here. No, didn't think so...) > > Okay, the abstraction has leaked again... are the paperweights references > > to the objects, or the names we've bound objects to? I'm confused... They're the references to the objects. You don't bind names to objects. You bind names slots in which you store references. This discussion -- I'd call it an argument, but that might give the wrong impression, because I think we're being remarkably civil and constructive by the standards of Usenet arguments! -- hasn't started on the topic of variable bindings or environments yet. > > How do we deal with anonymous objects in your model? > > > > -- > > Steven > > Mark, hi, Steven, pleasure as always. Hello. ;-) > Neither side is perfect or wild; (Do admit it); It's true. > How do we decide what is best for newcomers to Python, depending on > background? That I really don't know. I'm not good at teaching total beginners (does it show?) because I'm too enmired in the theory. (It doesn't help that I go off on tangents about how language X does something similar but subtly different all the time, though my rich background comes in very useful all over the place and that's something I think is worth sharing.) It probably doesn't help that I came to Python with a thorough understanding of Scheme (among many others) under my belt, because many Scheme concepts carry over directly, including the data model (it's all references) and the variable model (nested, mutable, lexical environments with closures). What I am pretty sure of is that references are going to have to enter the picture at some point, because other models get too complicated. Oh, while I remember: the `distributed Python' model, with auto-updating copies, only works for sharing. Circular structures still require actual references or a Tardis. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
