Terry Reedy wrote:
> On 4/11/2015 12:23 PM, Thomas 'PointedEars' Lahn wrote:
>> Chris Angelico wrote:
>>> The 'x' inside each function is completely separate, no matter how
>>> many times they get called. They're usually stored on something called
>>> a "call stack" - you put another sheet of paper on top of the stack
>>> every time you call a function, local variables are all written on
>>> that paper, and when you return from a function, you discard the top
>>> sheet and see what's underneath.
>>
>> Thank you for that description; I shall use it from now on when teaching
>> laymen about the call stack.
>
> What Chris is describing is one local namespace (sheet of paper) per
> function *call*.
I *know* what he is describing: the *call* stack.
> In early Fortran (at least the first version I used),
> there was one local namespace (sheet) per *function*.
The names in such namespaces are now called static variables. AFAIK, Python
does not have them, but PHP, for example, has:
function foo ()
{
static $bar = 1;
$bar *= 2;
return $bar;
}
The variable $bar then keeps its last value for subsequent calls of foo().
> The call stack was a stack of (pointers to) functions.
It would appear that the commonly used definition of “call stack” has
considerably changed since then, since I have been programming computers for
more than two decades now (not including FORTRAN, though) and never heard of
your definition before.
> It has been proposed that Python use a hybrid model. Function objects
Interesting. I did not know that functions are objects in Python, too.
> would have space for local variables for the first call, but there would
> also be a mechanism to allocate additional 'sheets' for recursive calls.
> The idea is that most functions are not called recursively, so the
> overhead of allocating and freeing the per-call space is usually not
> needed. I do not believe that anyone has implemented the idea to test
> feasibility and the actual speedup in relation to the additional
> complexity.
ISTM that such static variables are the remains of non-object-oriented
programming. In a language where functions are first-class objects, you
would use a closure instead. And in OOP you would solve the problem with an
object holding the value in a property that survives exiting the execution
context of the function/method. It is not a good idea to reintroduce
obsolete concepts into Python.
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--
https://mail.python.org/mailman/listinfo/python-list
