why cannot assign to function call

[Steven D'Aprano]

On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote:

> On Jan 7, 2:02 am, Steven D'Aprano
> <ste... at 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