Possibly Pythonic Tail Call Optimization (TCO/TRE)
liik.joonas at gmail.com
Thu Jul 16 21:14:15 CEST 2015
On 16 July 2015 at 21:58, Steven D'Aprano <steve at pearwood.info> wrote:
> On Fri, 17 Jul 2015 03:34 am, Joonas Liik wrote:
>> Now i admit that it is possible to have infinite recursion but it is
>> also possiblew to have infinite loops. and we don't kill your code
>> after 1000 iterations of a while loop so why should we treat recursion
>> any differently?
> Because a while loop which repeats to many times is annoying but harmless,
> but a function that recurses too many times will blow up the stack and
> cause a seg fault, possibly executing arbitrary memory as code. You want
> malware and viruses to take over your system? That's how you get malware
> and viruses to take over your system.
That's just a buggy implementation, there are ways to extend the stack
that nears its capacity, safely.
>> Having a user defined maximum stack limit might be a good idea, eg if
>> my stack takes up 100MB its prolly broke, but it should be my duty as
>> a programmer to specify such a limit, not have it inflicted upon me
>> (worse, in a manner that cannot be changed!).
> You mean sys.getrecursionlimit() and sys.setrecursionlimit()?
... and that buggy implementation means that when you
sys.setrecursionlimit() you will overflow the stack and crash because
the recursion limit is an aritificial safeguard and the underlying c
buffer is not adjusted accordingly or at least so it would seem.
so as per the docs the programmer has no real control over how much
stack his program can have. all you can say is "let me ignore the
safeguard a little longer, i hope i wont crash the program" that is
not the same as "can i please have a stack depth of 20000..
You are giving the programmer a choice between "run out of stack and
crash" and "mutilate interpreter internals and crash or zero out the
hard drive" this is not a real choice..
More information about the Python-list