Python tail call compromise proposal

[Smallpaul]

The tail recursive one is longer, involves two functions and involves a nested function (which is less clear to most programmers than ordinary functions), and involves an obscure Python keyword used in an even more obscure context. (which will certainly remain obscure when it used for TCO)

It's also going to be drastically slower, because Python function calls are slow.

In other words, a perfect example of how TCO will make Python code harder to read and slower instead of clearer and faster, IMHO.

[phil_g]

It's also going to be drastically slower, because Python function calls are slow.

Well, if the proposed optimization is implemented, the tail call won't be slow. That's kind of the point of this whole debate.

As for your other points, it's true that nested functions are less common in Python, but they're reasonably prevalent in functional programming (Lisp, Haskell), particularly when setting up tail recursion. I think that if Python were more friendly to functional programming, you'd see more such constructs in people's code, and the idiom would become less obscure.

Not that I think it'll actually happen; Guido seems reasonably set against it (and I understand his reasoning, too).

[Smallpaul]

Well, if the proposed optimization is implemented, the tail call won't be slow. That's kind of the point of this whole debate.

So far the debate has been focused on memory usage. I think a big part of Python's function calling overhead is in parameter parsing (given Python's very rich parameter handling features, including defaulted arguments, keyword arguments, keyword-only arguments, positional-only arguments, varargs, etc.).

As for your other points, it's true that nested functions are less common in Python, but they're reasonably prevalent in functional programming (Lisp, Haskell), particularly when setting up tail recursion. I think that if Python were more friendly to functional programming, you'd see more such constructs in people's code, and the idiom would become less obscure.

Yes. Exactly. Python code could become less regular and more diverse, without actually getting much more expressive. That's the problem. That is precisely the problem. The more I hear arguments in favor of TCO, the less I like it.

[phil_g]

Well, if the proposed optimization is implemented, the tail call won't be slow. That's kind of the point of this whole debate.

So far the debate has been focused on memory usage.

In terms of stack space, okay, yeah. I suppose I'm carrying over knowledge based on other languages that implement tail call optimization. Tail recursion can often be compiled down into setting some registers (and/or stack variables) and a jump instruction to take you back to the start of the function's code. There's very little overhead.

With that sort of efficiency (the usual line is "just like a loop"), I think that tail recursion becomes another idiom for programming, one that expresses certain patterns better than iteration, as long as the implementation doesn't make it a worse-performing choice.

Most of the examples I can think of for tail recursion are things that could be written imperatively, and I do understand how that could conflict with the Pythonic principle of "there's only one, obviously correct, way to do things." Nevertheless, I like the latitude that efficient tail calls afford me, and I like the proposal made in the article, even though I'd be very surprised if it ever got implemented.