On 19 November 2015 at 18:19, BartC <b...@freeuk.com> wrote: >>> >>> if you write A=B then something of B needs to have been copied into >>> A, even if it's just the reference that B contains. Otherwise it would be >>> difficult to get A to refer to the same object as B. >> >> Please, PLEASE, go and read/watch Ned's PyCon talk (the one I linked >> you to earlier). Don't post another word on this subject until you >> comprehend what he is saying. > > I looked through the long article (I don't remember seeing a link to a > video), and followed it up to about 3/4 of the way through, then it got a > bit heavy. > > But what is it about my remarks above that isn't right?
It's not necessarily incorrect (just focussing on the remark quoted above) but you'll find it easier to understand the model if you adopt the same terminology that is usually used. When talking of "copying" in a Python context something different is implied than what happens with A=B. The statement A=B (assuming A and B are names and not expressions) simply binds the name A to the same object that the name B is bound to. In the implementation of CPython the names are associated with pointers and the value of the pointer associated with B is copied to the pointer associated with A. Another implementation may not use pointers but there will in some way be a "reference" that is "copied" over if you like to view it that way. However in a Python context when someone talks of "copying" they will mean something different: creating a new object which is distinct from, but has the same value as, some previously existing object. It is important in Python to distinguish between operations that create/mutate objects and operations that rebind names. This distinction has semantic implications that are not hard to understand if you think about them carefully and consistent use of terminology really helps. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
