[Python-ideas] Tail Call Optimization (was Re: Tail recursion elimination)

Terry Reedy tjreedy at udel.edu
Mon Jan 20 02:28:46 CET 2014


On 1/19/2014 7:23 PM, Steven D'Aprano wrote:
> On Sun, Jan 19, 2014 at 07:12:16AM -0500, Terry Reedy wrote:
>
>> Are you willing to do any of the work needed to make the option
>> available, starting with a specification? If so, I have some ideas.

Since writing the above, I came across the 'return from' idea, which I 
think is the best so far, and better than any of the 'ideas' I was 
thinking of. See my 'return from' post.

> Given the amount of controversy over this, it would probably need a PEP.
> I might be able to start with a pre-PEP, time permitting, and see how
> that goes. (If those interminable bytes/unicode/2.8 threads on the
> Python-Dev list would start to die off, I might have more time to treat
> this seriously.)

>> A 'fork' could consist of a relatively small patch that could be
>> uploaded to, for instance, PyPI. I would not be surprised if 100-200
>> lines might be enough.
>
> Lines of *C* though, right?

Yes.

> Which means for anyone to use it, they would
> have to be willing to build Python from source, applying your patch, or
> the maintainer would have to volunteer to provide pre-built binaries.

A typical combination is source for *nix and a Windows installer.

> Neither of which is exactly a recipe for broad take-up.

Use of macropy.experimental.tco would give some indication of the 
popularity of the idea. Without using it, I do not know how close it is.

A 'return from' patch could start by copying the code that recognizes 
'yield from' and compiles it to a YIELD_FROM bytecode. (Or by looking at 
the part of the yield from patch that added the code.) Writing code to 
implement a RETURN_FROM bytecode, by modifying the RETURN_VALUE 
function, would be a separate step.

-- 
Terry Jan Reedy



More information about the Python-ideas mailing list