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/
--
http://mail.python.org/mailman/listinfo/python-list
