[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4