On Thu, 15 Jul 2004 18:01:25 -0400, Tim Peters <tim.peters at gmail.com> wrote:
> [Jeremy Hylton]
> > ...
> > Getting a useful traceback after tail call optimization seems like an
> > awfully important quality of implementation issue.
>
> Indeed, in delegation-heavy designs, when an error occurs the
> delegation path you took to reach the failing code often *is* "the
> error".
Well, since optimizing only when -O is specified was rejected, and
from __future__ import tail_call seems like a similarly bad idea, why
not something like 'sys.optimize_tail_calls()' to enable the alternate
mechanism? This can be done in such a way that programs not using it
won't even notice a change in execution speed (e.g. using a different
eval loop when it's enabled).
I'd then place this mechanism in the same category as such other
implementation-altering functions as gc.disable(), psyco.full(), and
sys.setrecursionlimt(1e9). Since it's explicitly enabled by the
programmer, he'd know the consequences of enabling it. The only
downside is a little extra glue code would be needed to replace it
with an appropriate sys.setrecursionlimit() call on Pythons that don't
support it:
import sys
try:
sys.optimize_tail_calls()
except AttributeError:
sys.setrecursionlimit(10000)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4