Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.087 X-Spam-Evidence: '*H*': 0.84; '*S*': 0.01; 'debugging': 0.07; 'calls.': 0.09; 'optimizing': 0.09; 'reached.': 0.09; 'subject:while': 0.09; 'limit,': 0.16; 'subject:recursion': 0.16; 'wrote:': 0.18; 'stack': 0.19; 'adds': 0.24; 'header:In-Reply- To:1': 0.27; 'function': 0.29; 'specifically': 0.29; 'am,': 0.29; 'message-id:@mail.gmail.com': 0.30; 'depth': 0.31; 'call.': 0.33; 'fri,': 0.33; 'could': 0.34; 'case,': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'doubt': 0.36; 'possible': 0.36; 'to:addr:python-list': 0.38; 'fact': 0.38; 'to:addr:python.org': 0.39; 'called': 0.40; 'eventually': 0.60; 'ian': 0.60; 'benefit': 0.68; 'limit': 0.70; 'increase': 0.74; 'allowable': 0.84; 'irrelevant': 0.84; 'hand,': 0.93; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=46hU6Bw8Gpi4AIvR0su01wwSRos3ClcteRG3ADpDhMI=; b=pxxWVIuGfIItqKVSBM8sn70LFoMXps3h+73L1WWYTpHcLUAyhbsj1ErzexR8mMfuGn gajbfjsPqKksgaUaQrVgbEjof9OZPxj+KRwJ8MoDc2KahzKGHigzmN3ZREycYDXgjF7j VNEktZpyRAmDS+w6LYj0wf7XH2bnYflHZKYLBspiZ6HjMwbtwx1FagEKjGKAY4EA4qyT sOqE5wPH3pM9ukLyNisgBPOir15g2gOGl4YWCbpsuZyWJq0U7RXlihTIB7zfz/LHwKnk uvjaBrSZ7OKO2etYoAeZRIxG/41a70Mqj/l2IFOo0F3rT7BUVEi02CfHIW2zXzr5uGta KsdQ== X-Received: by 10.68.101.225 with SMTP id fj1mr13825292pbb.8.1380883620409; Fri, 04 Oct 2013 03:47:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <87had0axxy.fsf@dpt-info.u-strasbg.fr> From: Ian Kelly Date: Fri, 4 Oct 2013 04:46:20 -0600 Subject: Re: Tail recursion to while iteration in 2 easy steps To: Python Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 19 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1380884079 news.xs4all.nl 15864 [2001:888:2000:d::a6]:49215 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:55472 On Fri, Oct 4, 2013 at 4:41 AM, Ian Kelly wrote: > There is no doubt that it's a tail call. Whether it is recursion is > irrelevant to optimizing it. The reason we talk about "tail call > recursion" specifically is because the recursive case is the one that > makes the optimization worthwhile, not because the recursion is > necessary to perform the optimization. > > It is possible that fact is recursive but that some_decorator adds > additional stack frames that are not tail calls and not optimizable. > If this were the case, then the recursion would still eventually hit > the stack limit, but there would still be benefit in optimizing the > "fact" frames, as it would increase the allowable depth before the > stack limit is reached. So I see no reason to check the identity of > the called function before optimizing the tail call. On the other hand, if you start optimizing every tail call and not just the recursive functions, then I can see where that could start to get problematic for debugging -- as arbitrary functions get removed from the stack traces just because they happened to end in tail calls.