[Python-Dev] PEP 334 - Simple Coroutines via SuspendIteration

[Clark C. Evans]

On Wed, Sep 08, 2004 at 02:08:17PM -0400, James Y Knight wrote:
| >This proposal assumes that a corresponding iterator written using
| >this class-based method is possible for existing generators.  The
| >challenge seems to be the identification of distinct states within
| >the generator where suspension could occur.
| 
| That is basically impossible. Essentially *every* operation could 
| possibly raise SuspendIteration, because essentially every operation 
| can call an arbitrary python function, and python functions can raise 
| any exception they want.

If the SuspendIteration() was raised in an arbitrary Python function,
it would close-out the function call due to exception semantics.  So,
a brain-dead situation would have to make each time a function is called
a separate state. The proposal is not implying that this would be
converting arbitrary functions into generators, if they happened to
raise SuspendIteration().

| I think you could still make the proposal work 
| in CPython: if I understand its internals properly, it doesn't need to 
| do a transformation to a class iterator, it simply suspends the frame 
| wherever it is. Thus, being able to suspend at any point in the 
| function would not cause an undue performance degradation.

Ok.

| However, I think it is a deal-breaker for JPython. From the generator 
| PEP: "It's also believed that efficient implementation in Jython 
| requires that the compiler be able to determine potential suspension 
| points at compile-time, and a new keyword makes that easy." If this 
| quote is right about the implementation of Jython (and it seems likely, 
| given the JVM), your proposal makes it impossible to implement 
| generators in Jython.

Ok, beacuse suspension points would now include not only 'yield'
statements, but potentially any function call.  So, it could be quite
inefficient, but it is not impossible.  For an optimization, you could
decorate a function if it could throw a SuspendIteration. If an
non-decorated function threw that exception, it would be a deal-breaker.

| Given that the advantage claimed for this proposal over stackless is 
| that it can be implemented in non-CPython runtimes, I think it still 
| needs some reworking.

Thanks for your feedback.

Best,

Clark