your understanding is correct - this is about handling StopIteration inside generatorn. So the proposal is if inside your generator a StopIterations is about to buble out, it will be replaced with RuntimeError and this will cause error when you call next() on your generator.
This may happen if you have iterator
Your code in first post is exactly example how the PEP will affect older code. Note that you get RuntimeError, not StopIteration. That is the new behavior in accordance with the PEP - StopIteration error inside generator is replaced with RuntimeError. Thus you need to handle it inside your generator. But in this case you don't have to raise it artificially in the first place.
This may happen if you have iterator
some_iterator
and you call unguarded next(some_iterator)
. when it is exhausted it will raise StopIteration
error. So, you should not allow this to happen and you need to handle it inside your generator. This is exactly the opposite to raisng it your self. There is even an example that says wrong as comment after raise StopIteration inside generator.Your code in first post is exactly example how the PEP will affect older code. Note that you get RuntimeError, not StopIteration. That is the new behavior in accordance with the PEP - StopIteration error inside generator is replaced with RuntimeError. Thus you need to handle it inside your generator. But in this case you don't have to raise it artificially in the first place.
If you can't explain it to a six year old, you don't understand it yourself, Albert Einstein
How to Ask Questions The Smart Way: link and another link
Create MCV example
Debug small programs
How to Ask Questions The Smart Way: link and another link
Create MCV example
Debug small programs