Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #88838

Re: Generarl programming question.

Show all headers | View raw

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.

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Generarl programming question. jonas.thornvall@gmail.com - 2015-04-11 08:00 -0700
  Re: Generarl programming question. Chris Angelico <rosuav@gmail.com> - 2015-04-12 01:15 +1000
    Re: Generarl programming question. jonas.thornvall@gmail.com - 2015-04-11 08:22 -0700
      Re: Generarl programming question. Chris Angelico <rosuav@gmail.com> - 2015-04-12 01:28 +1000
    Re: Generarl programming question. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-11 18:23 +0200
      Re: Generarl programming question. Terry Reedy <tjreedy@udel.edu> - 2015-04-11 14:47 -0400
        Re: Generarl programming question. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-11 21:19 +0200
          Re: Generarl programming question. Terry Reedy <tjreedy@udel.edu> - 2015-04-11 17:12 -0400
            Re: Generarl programming question. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-12 00:05 +0200
              Re: Generarl programming question. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-12 15:04 +1000
  Re: Generarl programming question. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-12 01:25 +1000
    Re: Generarl programming question. jonas.thornvall@gmail.com - 2015-04-11 08:36 -0700

csiph-web