Finding the instance reference of an object

[Steve Holden]

Steven D'Aprano wrote:
> On Fri, 07 Nov 2008 00:44:21 -0500, Steve Holden wrote:
> 
>> Steven D'Aprano wrote:
>>> On Thu, 06 Nov 2008 09:59:37 -0700, Joe Strout wrote:
>> [...]
>>> And by definition, "call by value" means that the parameter is a copy.
>>> So if you pass a ten megabyte data structure to a function using
>>> call-by- value semantics, the entire ten megabyte structure is copied.
>>>
>>> Since this does not happen in Python, Python is not a call-by-value
>>> language. End of story.
>>>
>>>
>>>
>>>> Without knowing that, you don't know what assignments to the formal
>>>> parameter will do, or even what sort of arguments are valid. Answer:
>>>> it's a copy of it.
>>> Lies, all lies. Python doesn't copy variables unless you explicitly ask
>>> for a copy. That some implementations of Python choose to copy pointers
>>> rather than move around arbitrarily large blocks of memory instead is
>>> an implementation detail. It's an optimization and irrelevant to the
>>> semantics of argument passing in Python.
>> [...]
>>
>> Are you sure you meant to write this?
> 
> I'm not sure I understand what you're getting at. The only thing I can 
> imagine is that you think there's some sort of contradiction between my 
> two statements. I don't see why you think so. In principle one could 
> create an implementation of Python with no stack at all, where everything 
> lives in the heap, and all argument passing is via moving the actual 
> objects ("large blocks of memory") rather than references to the objects.
> 
> I don't mean to imply that this is a practical way to go about 
> implementing Python, particularly given current computer hardware where 
> registers are expensive and the call stack is ubiquitous. But there are 
> other computing models, such as the "register machine" model which uses a 
> hypothetically-infinite number of registers, no stack and no heap. With 
> sufficient effort, one could implement a Python compiler using only a 
> Turing Machine. Turing Machines don't have call-by-anything semantics. 
> What would that say about Python?
> 
> Alternatively, you're commenting about my comment about copying pointers. 
> I thought I had sufficiently distinguished between what takes place at 
> the level of the Python VM (nothing is copied without an explicit request 
> to copy it) and what takes place in the VM's implementation (the 
> implementation is free to copy whatever pointers it wants as an 
> optimization). If I failed to make that clear, I hope I have done so now.
> 
> Pointers do not exist at the level of the Python VM, but they clearly 
> exist in the C implementation. We agree that C is call-by-value. CPython 
> is (obviously) built on top of C's call-by-value semantics, by passing 
> pointers (or references if you prefer) to objects. But that doesn't imply 
> that Python's calling semantics are the same as C's.
> 
> Algol is call-by-name. Does anyone doubt that we could develop an Algol 
> implementation of Python that used nothing but call-by-name semantics at 
> the implementation level? Would that mean that Python was call-by-name?
> 
> The point is that Joe's argument is based on a confusion between the C 
> implementation (calling a function with argument x makes a copy of a 
> pointer to x and puts it into the stack for the function) and what 
> happens at the level of the Python language.
> 
> 
> 
I am probably egregiously misunderstanding. The practical difficulty
with the "moving huge blocks of data" approach would appear to emerge
when a function that gets passed an instance of some container then
calls another function that references the same container as a global,
for example.

Again, I don't think we disagree about how Python actually works, but it
seemed to me that your statement obscured rather than helped.

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/