[Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython) (original) (raw)
Guido van Rossum guido at python.org
Sun Jul 25 05:21:03 CEST 2010
- Previous message: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
- Next message: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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)
- Previous message: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
- Next message: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]