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):
        try:
            next(gen)
        except StopIteration as e:
            return e.value
        else:
            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.

Note: Javascript, which added generators, agrees with the Python
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 thunk.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/