3 ms·

A patch that implements TCO in Python with explicit syntax like 'return from f(x)' could likely get accepted, ending these hacks

by __s 9y ago

iainmerrick 9y ago
That would be great, especially as it doubles as an annotation/assertion that TCO is both expected and required at that specific point in the code.
shakna 9y ago
Would it? My impression is that Guido is fairly against any such thing occurring [0]. > So let me defend my position (which is that I don't want TRE in the language). If you want a short answer, it's simply unpythonic. [0] http://neopythonic.blogspot.com.au/2009/04/tail-recursion-elimination.html http://neopythonic.blogspot.com.au/2009/04/tail-recursion-el...
- __s 9y ago
  His primary concern is with implicit tail recursion I tried making such a patch in the past, got stuck in the much of trying to update the grammar file in a way that wouldn't complain about ambiguity Main thing to get from tail calls vs loops is the case of mutually recursive functions
  - shakna 9y ago
    His primary concern seems more to be stack traces. At the time, an explicit style, with patch, was proposed to python-ideas. [0] It was based around continuation-passing-style, and the conclusion reached then by the community was the same. TCO, explicit or not, isn't wanted in Python. > And that's exactly the point -- the algorithms to which TCO can be applied are precisely the ones that are not typically expressed using recursion in Python. - Greg Ewing [1] > <sarcasm>Perhaps we should implement "come from" and "go to" while we're at it. Oh, let's not leave out "alter" (for those of you old enough to have used COBOL) as well! </sarcasm> - Gerald Britton [2] Feel free to try again, maybe things have changed. To be clear, I wish Python did have a mechanism to express these sorts of problems, but I don't think the Python team themselves want them. This issue has come up more than a few times, and the dev team have never been satisfied that Python really needs it. [0] https://mail.python.org/pipermail/python-ideas/2009-May/004430.html https://mail.python.org/pipermail/python-ideas/2009-May/0044... [1] https://mail.python.org/pipermail/python-ideas/2009-May/004522.html https://mail.python.org/pipermail/python-ideas/2009-May/0045... [2] https://mail.python.org/pipermail/python-ideas/2009-May/004536.html https://mail.python.org/pipermail/python-ideas/2009-May/0045...
nullp0tr 9y ago
It's actually not likely at ALL. Guido van Rossum said[0] on multiple occasions that it's un-pythonic and it won't happen. Edit: I didn't see shakna's comment. [0] http://neopythonic.blogspot.de/2009/04/tail-recursion-elimination.html?m=1 http://neopythonic.blogspot.de/2009/04/tail-recursion-elimin...

A patch that implements TCO in Python with explicit syntax like 'return from f(x)' could likely get accepted, ending these hacks

by __s 9y ago

A patch that implements TCO in Python with explicit syntax like 'return from f(x)' could likely get accepted, ending these hacks

iainmerrick 9y ago

That would be great, especially as it doubles as an annotation/assertion that TCO is both expected and required at that specific point in the code.

shakna 9y ago

Would it? My impression is that Guido is fairly against any such thing occurring [0]. > So let me defend my position (which is that I don't want TRE in the language). If you want a short answer, it's simply unpythonic. [0] http://neopythonic.blogspot.com.au/2009/04/tail-recursion-elimination.html http://neopythonic.blogspot.com.au/2009/04/tail-recursion-el...

__s 9y ago
His primary concern is with implicit tail recursion I tried making such a patch in the past, got stuck in the much of trying to update the grammar file in a way that wouldn't complain about ambiguity Main thing to get from tail calls vs loops is the case of mutually recursive functions
- shakna 9y ago
  His primary concern seems more to be stack traces. At the time, an explicit style, with patch, was proposed to python-ideas. [0] It was based around continuation-passing-style, and the conclusion reached then by the community was the same. TCO, explicit or not, isn't wanted in Python. > And that's exactly the point -- the algorithms to which TCO can be applied are precisely the ones that are not typically expressed using recursion in Python. - Greg Ewing [1] > <sarcasm>Perhaps we should implement "come from" and "go to" while we're at it. Oh, let's not leave out "alter" (for those of you old enough to have used COBOL) as well! </sarcasm> - Gerald Britton [2] Feel free to try again, maybe things have changed. To be clear, I wish Python did have a mechanism to express these sorts of problems, but I don't think the Python team themselves want them. This issue has come up more than a few times, and the dev team have never been satisfied that Python really needs it. [0] https://mail.python.org/pipermail/python-ideas/2009-May/004430.html https://mail.python.org/pipermail/python-ideas/2009-May/0044... [1] https://mail.python.org/pipermail/python-ideas/2009-May/004522.html https://mail.python.org/pipermail/python-ideas/2009-May/0045... [2] https://mail.python.org/pipermail/python-ideas/2009-May/004536.html https://mail.python.org/pipermail/python-ideas/2009-May/0045...

nullp0tr 9y ago

It's actually not likely at ALL. Guido van Rossum said[0] on multiple occasions that it's un-pythonic and it won't happen. Edit: I didn't see shakna's comment. [0] http://neopythonic.blogspot.de/2009/04/tail-recursion-elimination.html?m=1 http://neopythonic.blogspot.de/2009/04/tail-recursion-elimin...