On 2006-08-01, danielx <[EMAIL PROTECTED]> wrote: > Gerhard Fiedler wrote: >> On 2006-07-30 09:54:14, Antoon Pardon wrote: >> >> > Aren't you looking too much at implementation details now? >> >> Possibly, but at this point I'm still trying to understand how Python does >> these things, and what the useful abstraction level is for me. I also still >> have very little experience how I'll put the things we've been discussing > > Sorry I've been away from this sub-thread for a while (even though I > kinda started it :P). Yes, I'm also wondering what difference this big > huge argument makes on how I logically follow Python. > > Personally, I find this metaphor in "Head First Java" from O'Reilly > Press really helpful for both Python and Java. Before anyone sends me a > letter bomb that says "Python != Java", let me say this: have phun :P. > > Anyway, the metaphor goes something like this: variables (for objects, > not primitives) are like cups (just wait, it gets better). You can put > a remote control IN a cup. The remote control controls a "real" object > on the heap (ie, the data for the object is there). > > Unfortunately, some of the effect of the metaphor is lost because I > cannot reporduce the very nice illustrations which came in the book :P. > > Other than the fact that you declare variables in Java (going down > another letter-bomb-laden slippery slope), which means they stick > around even when they have no "remote controls", I pretty much think of > Python variables the same way: each variable LOGICALLY contains a > reference (ie, without regard to what the mechanics are) to some > amorphous glob of data, sitting on the heap. Therefore, when I do an > assignment, I am simply replacing the reference my variable is holding. > According to the metaphor, we are replacing the remote control our cup > is holding. > > If an object is no longer visible (because all the references have > disappeared), then it should get garbage collected eventually. But > until the magical garbage-collecting angle of death makes is way > through the heap, our orphaned objects are PHYSICALLY still there until > they are forcefully evicted from memory. Logically, however, they were > gone as soon as we lost sight of them. > > Java aside, My question is this: how will using this metaphor break the > way I logically follow Python?
I don't think it will cause you problems. The confusion from explaining Python variables in terms of C-like references comes from the fact that in Python both assignment and argument passing are reference passings. In code like the following: def foo(x): x = x + 1 a = 0 f(a) print a A number of people expect to see 1 printed. They remember that x will be a reference of a and so expect a to be incremented by 1 after the call. They forget that the assigment to x will cause x to refer to a different integer and not cause it to refer to the same "object" whose value is increased. An other problem is that people don't realise that an assignment to a simple identifier in a function, has a declarative effect. So (unless the identifier was declared global) from the moment there is some line like: ident = ... in a function, all occurences of ident in that function will refer to the local variable. So this works: def foo(): b = a a = 1 foo() This doesn't: def foo(): b = a a = 2 * b + 1 a = 1 foo() Even this doesn't: def foo(): if False: a = 1 else: b = a a = 1 foo() Yet seems to work (which I think is an error in the optimisation; replacing 0 by [], () or None shouldn't make a difference but it no longer works in those cases): def foo(): if 0: a = 1 else: b = a a = 1 foo() -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list