[Python-ideas] Raise StopIteration with same value on subsequent `next`s
leewangzhong+python at gmail.com
Mon Dec 11 18:21:07 EST 2017
What about hanging onto just the value, and creating new StopIteration
instances instead of raising the same one again?
On Mon, Dec 11, 2017 at 3:06 PM, Guido van Rossum <guido at python.org> wrote:
> IIRC we considered this when we designed this (PEP 380) and decided that
> hanging on to the exception object longer than necessary was not in our best
> On Mon, Dec 11, 2017 at 1:10 AM, Franklin? Lee
> <leewangzhong+python at gmail.com> wrote:
>> Consider the following code, which creates a generator that
>> immediately returns 1, and then catches the StopIteration twice.
>> def generatorfunction():
>> if False: yield
>> return 1
>> def get_return(gen):
>> except StopIteration as e:
>> return e.value
>> raise ValueError("Generator was not ready to stop.")
>> gen = generatorfunction()
>> get_return(gen) #=> 1
>> get_return(gen) #=> None
>> The first time StopIteration is raised, it contains the returned
>> value. If StopIteration is forced again, the value is missing.
>> What about keeping the return value for subsequent raises? Perhaps as
>> an attribute on the generator object? The main disadvantage is that
>> it'd add another reference, keeping the return value alive as long as
>> the generator is alive. However, I don't think you'll want to keep a
>> dead generator around anyway.
>> status quo: the return value is only available on the first stop. C#
>> does not have the concept of returning from an iterator.
>> Background: I made a trampoline for a toy problem, using generators as
>> coroutines to recurse.
>> When it came time to memoize it, I had to couple the memoization with
>> the trampoline, because I could not cache the answer before it was
>> computed, and I could not cache the generator object because it would
>> not remember its return value later.
>> I would have attached the returned value to the generator object, but
>> for some reason, generator and coroutine objects can't take
>> attributes. Maybe I should ask for that feature instead.
>> Either feature would allow the concept of a coroutine that is also a
>> Python-ideas mailing list
>> Python-ideas at python.org
>> Code of Conduct: http://python.org/psf/codeofconduct/
> --Guido van Rossum (python.org/~guido)
More information about the Python-ideas