Chris Carlen <[EMAIL PROTECTED]> writes: > Excellent description. This understandable to me since I can > envision doing this with pointers.
It would be better if you thought in terms of "refrences". Python names are unlike pointers in that they don't "store" anything. The *only* thing to do with them is refer to an object; don't think of them as a C pointer, because Python names don't need to be (and, indeed, can't) be "de-referenced". > But I have no idea how Python actually implements this. It also > appears that I am being guided away from thinking about it in terms > of internal implementation. Yes. This is a good thing, because Python has multiple implementations that are allowed to differ in their internals where it makes sense to do so. There are some guarantees at a lower level, that you can find in the language reference; but the main advantage of stopping at a certain level of abstraction is that the implementation programmers are free to *change* the implementation underneath that abstraction when it will improve the implementation. Meanwhile, the Python programmer is free to work at the abstraction level provided by the language, and isn't forced to be always mindful of the inner workings if the current implementation. -- \ "To me, boxing is like a ballet, except there's no music, no | `\ choreography, and the dancers hit each other." -- Jack Handey | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
