Hi Armin, I don't see why a new bytecode would be needed. I'm not sure exactly how Python functions are called, but this is based off what I know of X86 assembly and from what I gathered from Laurie's blog. Why not push the new arguments onto the stack and then jump back to the beginning of the function so as to reuse its stack frame? Which could all be done with the current bytecodes.
From a bigger picture perspective this and other compiler optimizations which change the traceback may be a good fit for use under the "-O" flag. Default behavior will be unchanged, and they can be added when wanted. Best, J Hi John, On 8 July 2014 22:57, John Smith <4u5vj...@gmail.com> wrote: > Yes. But tail-call optimization is a performance optimization, so it goes > well with PyPy. I wanted to suggest to Travis that he not be discouraged > from his idea and give him another idea for getting tail-call more widely > used compared to making his own fork of PyPy. Yes, that sounds like an idea --- which I wouldn't call a *good* idea because I still think that tail call optimization is a bad idea in Python, but that's a personal issue. If you want to implement such a pure Python compiler modification, you can; but it's a bit unclear what kind of alternate Python code or bytecode to emit. We could consider adding an experimental bytecode to the standard PyPy, even if it is normally never used, as long as it's extensively tested. Designing the bytecode correctly is an open question. A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev