[Python-ideas] A Continuations Compromise in Python

[Gerald Britton]

I think its about more than optimization.  It's also about being able
to code a solution using recursion without worrying about the stack.
The execution time may or may not change but the Python source may be
easier to read using recursion instead of iteration.

At the same time, I feel that some of the hoops one has to jump
through (like passing state in function arguments) can adversely
affect the readability and elegance of a recursive solution that is
trying to take advantage of TCO.  In general, I don't like coding
source a certain way because "I know" that the compiler will do
something "special" if I do.  What is "special" today may be not so
special (or even worse) tomorrow.

I suppose I would rather do the work of translating my recursive
solution into an iterative one rather than trying to code my recursive
function just right so that the compiler will do TCO for me, if the
stack is a concern.  With this approach, I can wind up with faster
execution and lower amortized memory costs as well.

On Sun, May 3, 2009 at 8:30 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Steven D'Aprano <steve at ...> writes:
>>
>> It's hardly "premature" to notice that recursive code in Python is
>> significantly slower and less efficient than in other languages. This
>> is a known problem, or at least issue, since some people consider that
>> the solution (tail-recursion optimization) is worse that the problem.
>
> Is there some evidence that this "known issue" has been popping up in real-world
> production Python code (I am not talking about Lisp, C, or any other language),
> rather than academic discussions?
>
> Premature optimization is trying to optimize something which is not a
> significant contributor to execution time.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton