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