On 7/14/2015 1:52 PM, Chris Angelico wrote:
On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:
I don't like the way integer overflows are explicitly undefined in
modern C.
Similarly, I don't like the way tail call behavior is undefined in
Python.
Where in the Python spec is it stated that tail call behaviour is
undefined? The behaviour of the 'return' statement is well defined: it
evaluates its expression (or None), *then* removes the top of the call
stack and passes control back to the caller:
https://docs.python.org/3/reference/simple_stmts.html#the-return-statement
I do not see anything there explicitly about call stacks.
This implies that during the evaluation of its expression, the current
function's call stack entry is still present. Tail call behaviour is
therefore well defined: it is identical to any other expression
evaluation, and then the final result is passed back to the caller.
In the blog post
http://neopythonic.blogspot.co.uk/2009/04/tail-recursion-elimination.html
that everyone discussing this issue should read, Guido said that if a
tail call is not within a try statement, tco would be fine except for
the implementation issue of helpful tracebacks, which he cares greatly
about. However, as both he and the linked doc say, a tail call within a
try: statement is not a tail call, in that more python code within the
function may yet be executed.
It is not hard to construct an example in which tco would mess up a
traceback message that is displayed.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
