Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!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.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; '16,': 0.03; '"as': 0.07; 'stack.': 0.07; 'cc:addr:python-list': 0.09; 'debugger': 0.09; 'exception,': 0.09; 'frameworks,': 0.09; 'happens.': 0.09; 'stderr': 0.09; 'exception': 0.13; 'stack': 0.13; 'useful,': 0.13; 'explicitly': 0.15; 'thu,': 0.15; 'variables': 0.15; 'clear.': 0.16; 'dropping': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'stuff,': 0.16; 'sure.': 0.16; 'wrote:': 0.16; 'frameworks': 0.18; 'programmer': 0.18; '>>>': 0.20; '2015': 0.20; 'cc:2**0': 0.20; 'cc:addr:python.org': 0.20; 'fine,': 0.22; 'trace': 0.22; 'variables.': 0.22; 'am,': 0.23; 'header:In-Reply- To:1': 0.24; "doesn't": 0.26; 'chris': 0.26; 'helpful': 0.27; 'fri,': 0.27; 'message-id:@mail.gmail.com': 0.27; 'said,': 0.27; 'values': 0.28; 'subject:/': 0.30; 'code': 0.30; 'generally': 0.32; 'good.': 0.32; 'though,': 0.32; 'lets': 0.33; 'traceback': 0.33; 'true.': 0.33; 'info': 0.34; 'list': 0.34; 'received:google.com': 0.35; 'done': 0.35; 'something': 0.35; 'level': 0.35; 'but': 0.36; 'should': 0.36; 'there': 0.36; 'possible': 0.36; 'pm,': 0.36; 'subject:: ': 0.37; "won't": 0.38; 'drop': 0.38; 'stuff': 0.38; 'mean': 0.38; 'whatever': 0.39; 'application': 0.39; 'some': 0.40; 'show': 0.62; 'more': 0.63; 'information': 0.63; 'grab': 0.64; 'jul': 0.72; 'chrisa': 0.84; 'pardon': 0.84; 'stronger.': 0.84; 'unclear': 0.84; 'to:none': 0.91; 'drops': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=6Oudi3rtSw4HQKgubKBuQHjm3s5+zq7rAguO0WII7bY=; b=k5NILRUSsx5svNoeuT+cXdqOMcxKX1l5Wbm+TwM/huSGT8+jnJ6h//50xwbpRdJvGu 4+t7ZkDFUulsgFUoQ7oxXtRE6uW29PjfFs34576YUoaHocCU1/PvFpR4JsLR3YkTW/gQ KBGXTTMNPvXmQefXjy8aZE7OK8Dl+wUMoAgc2GtrqNOkgbjQ4VCKFbvS6T+iNoKWWc9G ZfNPyBvJFFYwh93UCFJaJ0K+Y9gjNB3UYlmQRVAYHHmYJvnRxCnTKlntuq4ZZvIdr+mR 9nLeDCmS/XNQq4BEZpjtDxczYMA7ISj4YDkCIP7ELtmdMcoj5FZ/cE8GEaV0uqLt2Pz2 8ofw== MIME-Version: 1.0 X-Received: by 10.50.134.196 with SMTP id pm4mr4770135igb.6.1437065009568; Thu, 16 Jul 2015 09:43:29 -0700 (PDT) In-Reply-To: <55A7C094.7060604@rece.vub.ac.be> References: <55A3C366.6060602@rece.vub.ac.be> <87fv4r1fre.fsf@jester.gateway.sonic.net> <87bnff1eks.fsf@jester.gateway.sonic.net> <87d1zunctp.fsf@elektro.pacujo.net> <87k2u2eu67.fsf@elektro.pacujo.net> <55A51662.4090007@rece.vub.ac.be> <55A75DE0.1070101@rece.vub.ac.be> <55A7B80B.6090905@rece.vub.ac.be> <55A7C094.7060604@rece.vub.ac.be> Date: Fri, 17 Jul 2015 02:43:29 +1000 Subject: Re: Possibly Pythonic Tail Call Optimization (TCO/TRE) From: Chris Angelico Cc: "python-list@python.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ 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: 29 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1437065013 news.xs4all.nl 2883 [2001:888:2000:d::a6]:39305 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:93935 On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon wrote: > On 07/16/2015 04:00 PM, Chris Angelico wrote: >> On Thu, Jul 16, 2015 at 11:56 PM, Antoon Pardon >> wrote: >>> Fine, I should have been more clear. >>> >>> The stack trace as it is generally produced on stderr after an uncought >>> exception, doesn't contain the values of the variables on the stack. >> Sure. So you catch it at top level and grab whatever info you need. In >> some frameworks, this is already done for you - an uncaught exception >> from application code drops you into a debugger that lets you explore >> and even execute code at any level in the stack. > > What is unclear about "as it is generally produced on stderr"? That you > can do a whole lot of stuff, doesn't mean that this whole lot of stuff is > part of what generally happens. When people on this list ask a person > to include the stacktrace with the description of the problem, they > don't mean something that includes the values of the variables. True. That said, though, it's not a justification for dropping stack frames; even in the form that's printed to stderr, there is immense value in them. It may be possible to explicitly drop frames that a programmer believes won't be useful, but a general and automated dropping of tail-call information will do more harm than good. The fact that some frameworks can show _even more_ helpful information out of a traceback only makes this stronger. ChrisA