In article <4dc7fa2f$0$29991$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: >On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing wrote: > >> Steven D'Aprano wrote: >> >>> Since you haven't explained what you think is happening, I can only >>> guess. >> >> Let me save you from guessing. I'm thinking of a piece of paper with a >> little box on it and the name 'a' written beside it. There is an arrow >> from that box to a bigger box. >> >> +-------------+ >> +---+ | | >> a | --+---------------->| | >> +---+ | | >> +-------------+ >> >> There is another little box labelled 'b'. After executing 'a = b', both >> little boxes have arrows pointing to the same big box. >[...] >> In this model, a "reference" is an arrow. Manipulating references >> consists of rubbing out the arrows and redrawing them differently. > >All very good, but that's not what takes place at the level of Python >code. It's all implementation. I think Hans Georg Schaathun made a good >objection to the idea that "Python has references": > > In Pascal a pointer is a distinct data type, and you can > have variables of a given type or of type pointer to that > given type. That makes the pointer a concrete concept > defined by the language. > >The same can't be said of "references" in Python. It's not part of Python >the language, although it might be part of Python's implementation. > > > >> Also >> in this model, a "variable" is a little box. It's *not* the same thing >> as a name; a name is a label for a variable, not the variable itself. > >That's essentially the same model used when dealing with pointers. I've >used it myself, programming in Pascal. The "little box" named a or b is >the pointer variable, and the "big box" is the data that the pointer >points to. > >It's not an awful model for Python: a name binding a = obj is equivalent >to sticking a reference (a pointer?) in box a that points to obj. >Certainly there are advantages to it. > >But one problem is, the model is ambiguous with b = a. You've drawn >little boxes a and b both pointing to the big box (which I deleted for >brevity). But surely, if a = 1234 creates a reference from a to the big >box 1234, then b = a should create a reference from b to the box a?
There are cleaner languages. Algol 68 , Forth. This is Forth. VARIABLE A VARIABLE B 1234 ( anonymous "object" created by the language ) A ! A @ B ! ( Copy the content, equivalent of B=A). Algol 68 B:=A compiler : THINK ! THINK ! A is a "ref int" so it can't be stored into b which is a "ref int" which is the name of a place where an int can be stored (not where a ref int could be stored.) Solution: Algol dereferences A into an int, by getting its content. But it is a rule, very explicitly explained in the language definition. (If you are that clean you can handle "ref ref int q" where q is the name of a place where a "ref int" can be stored.) "real a" is in fact an abbreviation of "ref real a=loc real" meaning "a" is a reference to a local real, that is anonymous. The = means that the connection between a and that real is an identity, i.e. the connection can't be broken. (Forget about C++, "casting away const", yuck! ) In Forth and in Algol 68 storing a constant into a variable is very different from copying the content of a variable to some other variable. <SNIP> > >-- >Steven Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
