Interesting. I very much like the "return from" syntax. It's explicit and consistent enough with "yield from".

When using coroutines, it currently also happens that at some points you have a choice to drop certain frames from the stack. Take for instance the following:

@coroutine
def a():
    result = yield from b() # 'b' is another coroutine
    return result

or often written as:

@coroutine
def a():
    return (yield from b())


You could write it as:

def a():
    return b()


In the last example, you delegate to another coroutine, removing 'a' from the stack.
(see this discussion: https://groups.google.com/forum/#!topic/python-tulip/5xW44wh5Krs )











2014/1/20 Nick Coghlan <ncoghlan@gmail.com>


On 20 Jan 2014 11:16, "David Mertz" <mertz@gnosis.cx> wrote:
>
> I was mostly disliking the idea of TCO during this discussion.  However, the idiom of 'return from' seems sufficiently elegant and explicit--and has exactly the semantics you'd expect from 'yield from'--that I am actually +1 on that idea.

I agree that a PEP for "return from" would be interesting. It also gives debuggers something to latch on to in order to handle the new scenario (just as they needed some adjustment to handle "yield from").

"return from" could also be explicitly disallowed in try blocks and with statements (since those inherently conflict with the idea of reusing the current frame for a different call).

By keeping a list of references to the ellided calls (perhaps using counts for more efficient handling of recursive calls), you could even partially reconstruct the missing parts of the traceback.

> Being an explicit construct, it definitely becomes a case of "consenting adults" not of implicit magic.  I.e. you are declaring right in the code that you don't expect to see a frame in a stack trace, which is fair enough.  I mean, if you *really* wanted to you could muck around with 'sys._getframe(N).f_whatever' already which would give inaccurate tracebacks too.  Probably there would be a way to removed frames from the stack even, using some such trick in current python.

Yep, we do that (from C) in importlib to try to reduce the infrastructure noise in the tracebacks shown to users.

Cheers,
Nick.

>
>
> On Sun, Jan 19, 2014 at 3:13 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>>
>> Proposal (mostly not mine): add 'return from f(args)', in analogy with 'yield from iterator', to return a value to the caller from an execution frame running f(args) (and either reuse or delete the frame that ran 'return from'). The function name 'f' would not have to match the name of the function being compiled, this would actually be TCO, even if it were nearly always used for recursive tail calls. That does mean that is would work for mutually tail recursive functions.
>>
>> On 1/19/2014 6:57 AM, Joao S. O. Bueno wrote:
>>>
>>> OTOH, since we are at it, we'd better check
>>> 2009 BDLF's opinion on the subject:
>>>
>>> http://neopythonic.blogspot.com.br/2009/04/tail-recursion-elimination.html
>>
>>
>> I read throught the comments and near the very end, in July 2013, Dan LaMotte said... '''
>> Definitely seems to be complicated/impossible to determine a function is tail recursion 'compliant' statically in python, however, what if it were an 'opt in' feature that uses a different 'return' keyword?
>>
>>     def f(n):
>>     if n > 0:
>>     tailcall f(n - 1)
>>     return 0
>> '''
>> In additional paragraphs, he noted, among other things, that this makes the feature 'opt-in' on a function by function basis.
>>
>> Guido replied "Dan: your proposal has the redeeming quality of clearly being a language feature rather than a possible optimization. I don't really expect there to be enough demand to actually add this to the language though. Maybe you can use macropy to play around with the idea though?"
>>
>> 水逝云飞 then suggested 'return from'. My only contribution is to point out the analogy with the new, and initially strange, 'yield from'.
>>
>> Guido seems to have said that if a) someone tries out the idea with macropy, and b) someone demonstrates enough demand, he might consider adding such a feature. So this seems to me the best option to pursue to get something into CPython. I also think it is the best proposal so far.
>>
>> As for a), I have not looked as macropy, but:
>> On 1/19/2014 4:33 PM, Haoyi Li wrote:> MacroPy's @tco decorator is about as easy as you could ask for. 'pip
>> > install macropy', 'from macropy.experimental.tco import macros, tco' > is about as easy as you could ask for. Works for arbitrary tail-calls > too, not just tail recursion.
>>
>> That leaves b) for those of you who want the feature.
>>
>> Any PEP should admit that the feature might be abused. Someone might write
>>   return from len(composite)
>> Unless return from refuses to delete the frame making a call to a C function, the effect would be to save a trivial O(1) space as the cost of deleting the most important line of a stack trace should len() raise. But I think this falls under the 'consenting adults' principle. A proposed doc should make it clear that the intended use is to make deeply recursive or mutually recursive functions run and not to replace all tail calls.
>>
>> --
>> Terry Jan Reedy
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/