Wow i didn't knew that. Thanks for clarifying it :) .
l.
On 10/07/14 17:12, John Smith wrote:
Hi Eleytherios,
It looks to me like this is already done. Using the `dis` module and a
simple generator you can see that POP_BLOCK is only called when the
loop ends (which it never does in this example) but it remains after
each value is yeilded (YIELD_VALUE).
def f():
while True:
yield 3
dis(f)
2 0 SETUP_LOOP 15 (to 18)
>> 3 LOAD_GLOBAL 0 (True)
6 POP_JUMP_IF_FALSE 17
3 9 LOAD_CONST 1 (3)
12 YIELD_VALUE
13 POP_TOP
14 JUMP_ABSOLUTE 3
>> 17 POP_BLOCK
>> 18 LOAD_CONST 0 (None)
21 RETURN_VALUE
Best,
J
On Thu, Jul 10, 2014 at 9:52 AM, Eleytherios Stamatogiannakis
<est...@gmail.com> wrote:
Hi all, and sorry for interjecting.
Concerning the concept of leaving a function's stack in place.
Can the same idea be used for generators? So when we yield (return) from a
generator, we don't erase its stack but leave it in place to be reused for
the next call to it.
l.
On 10/07/14 16:39, John Smith wrote:
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
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
