On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote: > On Jan 7, 2:02 am, Steven D'Aprano > <ste...@remove.this.cybersource.com.au> wrote: > >> In Python code, there are no references and no dereferencing. > > The why does CPython keep track of reference counts?
Two different levels of explanation. At the level of Python code, you don't see reference counts. You never manipulate reference counts directly. The gc module does expose them, if you want to see them, but the gc module deliberately peaks behind the curtains. It's special. At the implementation level, CPython uses references so it needs reference counts. Jython doesn't keep reference counts at all, because it uses Java's garbage collection (or so I understand). And the hypothetical Distributed Python uses clones of objects and a daemon which keeps them in sync, and hence there are no reference counts because each clone is attached once and once only. >> You can't, because Python doesn't have references. In a language with >> references, that's easy. > > Python does not 'pass-by-reference' as Fortran or Pascal do. That's right. But sadly, if you tell people that Python uses references, many people will say "How do I pass a reference to this object to a function?". >>>> a = 123456789 >>>> b = [a] >>>> c = [a] >>>> d = [a, a] > >>>> b[0] is a > True >>>> c[0] is a > True >>>> d[0] is a > True >>>> d[1] is a > True > > Where is the object 'a' stored? Somewhere in memory, floating free, where it is referred to under the name 'a'. In CPython, it will be in the heap, unless it has been paged out to disk. In the lists 'b', 'c' and (twice) 'd'. I don't have a problem with objects being in two places at the same time. It's just a mental model. I understand that, underneath, the memory for the object is in *one place*, somewhere, because distributed storage is a hard problem and no existing Python does it. But I also understand that underneath, *everything* is just mutable bytes. There are no ints or strings or lists or dicts, they're just an abstraction. If you keep looking behind the curtains, looking at the implementation of each level of abstraction, eventually you'll get to bytes, and then electrons. If you go there, then you'll conclude that the object 'a' isn't anywhere. I'm happy with a high-level abstraction where Python objects can be in more than one place at once. Now, how do you implement such an abstraction? The easiest way is to have the object in one (hidden?) place, and have everywhere else use a pointer or reference to it. But that's a lower level of description than you can reach from Python code, because you can't access those pointers. You can only infer that they are there because otherwise you have to accept that objects can be in two places at once. Or because you've read the source code, but that's implementation. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
