[Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)

Guido van Rossum guido at python.org
Sun Jul 25 05:21:03 CEST 2010


On Sat, Jul 24, 2010 at 6:51 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote:
>>
>> - After seeing Raymond's talk about monocle (search for it on PyPI) I
>> am getting excited again about PEP 380 (yield from, return values from
>> generators). Having read the PEP on the plane back home I didn't see
>> anything wrong with it, so it could just be accepted in its current
>> form.
>
> I would like to reiterate (no pun intended) the suggestion of a special
> syntactic  form for the return, such as "yield return x", or "return with x"
> or something similar, to distinguish it from a normal generator return.
>
> I think that when people are getting used to the idea of generators, it's
> important for them to get the idea that the function's "return value" isn't
> really a value, it's an iterator object.  Allowing a return value, but then
> having that value silently disappear, seems like it would delay that
> learning, so, a special form might help to make it clear that the generator
> in question is intended for use with a corresponding "yield from", and help
> avoid confusion on this.
>
> (I could of course be wrong, and would defer to anyone who sees a better way
> to explain/teach around this issue.  In any event, I'm +1 on the PEP
> otherwise.)

Hm...  I somehow really like the idea that the return statement always
translates into raising StopIteration -- it seems so "right" when
writing the trampoline code.

I wonder if we could enforce this at runtime, by raising (e.g.)
TypeError if a StopIteration is caught with a value other than None in
a place where the value will be ignored. Such a check feels somewhat
similar to the check that .send() with a value other than None is not
used on a generator in its initial state.

Also I think that confusing "yield X" and "return X", while possible,
is relatively easy to debug, because things go so horribly wrong the
first time.

FWIW, the thing that was harder to debug when I tried to write some
code involving generators and a trampoline recently, was thinking of a
function as a generator without actually putting a yield in it
(because a particular version of a coroutine pattern didn't need to
block at all). Monocle uses a decorator to flag all coroutines which
fixes this up in the right way, which I think is clever, but I'm torn
about the need to flag every coroutine with a decorator -- Monocle
makes the decorator really short (@_o) because, as Raymond (not
Monocle's author but its advocate at EuroPython) said, "you'll be
using this hundreds of times". Which I find disturbing in itself.

> By the way, the PEP's "optimized" implementation could probably be done just
> by making generator functions containing yield-from statements return an
> object of a different type than the standard geniter.
[...]

Not a bad idea.

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-Dev mailing list