[Python-ideas] return from (was Re: Tail recursion elimination)

Mon Jan 20 16:57:48 CET 2014

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 at gmail.com>

>
> On 20 Jan 2014 11:16, "David Mertz" <mertz at 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 at 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 at 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 at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140120/9b3fb09f/attachment-0001.html>