RetroSearch Browse

Thu Jul 15 22:04:00 CEST 2004 · http://mail.python.org/pipermail/python-dev/2004-July/046228.html

On Thu, 15 Jul 2004 21:08:24 +0200, "Martin v. Löwis"
<martin at v.loewis.de> wrote:
> Michael Chermside wrote:
> > No... that answer applies to *language features*, but not *implementation
> > details*. The recursion limit (the value of it anyhow) is an
> > implementation detail.
> 
> No, it is not. In standard Python, the program
> 
> def rec(n):
>    rec(n-1)
> 
> n=1
> while 1:
>    try:
>      rec(n)
>    except RuntimeError:
>      break
> print "The recursion limit is", n
> 
> will terminate. In the modified Python, it will not terminate.
> It is a change in behaviour, and thus a language feature.

I would describe this "feature" as an implementation-dependent one. 
An implementation is free to raise RuntimeError if the recursion limit
is exceeded.  The fact that setrecursionlimit is in sys suggests that
it isn't part of the language proper.

I could imagine a Stackless implementation that merely raised
MemoryError when it ran out of heap space for activation records.

> > This doesn't bother me as much as it apparently bothers you. But for
> > that matter, we hardly care about performance if we're going to be
> > generating a stack trace, so we could probably construct the stack
> > trace after-the-fact if needed.
> 
> No, you can't: You forgot already what all the local variables where.

Getting a useful traceback after tail call optimization seems like an
awfully important quality of implementation issue.

Jeremy

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-July/046228.html below:

[Python-Dev] Proper tail recursion