[Python-Dev] genexps slow?

[Tim Peters]

[Tim Peters]
>> There's a twist there:  the functions synthesized for generator
>> expressions get to take the quicker-than-general "fast_yield" exit
>> path. Hmm!  It looks like tests against WHY_YIELD before the
>> fast_yield label can no longer succeed, but are still there to slow
>> down non-generator cases.

[Michael Hudson]
> Hmm.  I *think* I agree with you.  I also think the tests against
> WHY_YIELD in the code for END_FINALLY are unnecessary,

I meant that one too:  all tests against WHY_YIELD physically preceding the
fast_yield label appear unnecessary now.  The only obvious assignment of
WHY_YIELD to "why" appears in YIELD_VALUE now, and that jumps immediately to
fast_yield, from which there's no going backwards.  do_raise() can't return
WHY_YIELD either.

> as we (syntactically) don't allow yields when there are finally:
> statements in play.

Even if we did, a yield doesn't collapse any pending block structure.

>  If I'm wrong about that, then you're wrong too :-) It's all
> a bit subtle, to be sure.

Na <wink>.  I'll toss in some asserts and check it in if nothing blows up.

> Once again, I wonder if there was someway we could have two
> eval_frames: one with tracing support, one without.  Unfortunately, I
> don't think this can fly (how do you *start* tracing?).  Maybe we
> could have a '-notrace' command line flag?  But I suspect that this is
> a silly over-complication.

Me too.