[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