On Sat, Mar 28, 2009 at 4:34 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > I still think raise is out due to the fact that it would trigger > subsequent except clauses. Guido has (sensibly) ruled out raising > StopIteration and complaining if it has value in old code, since there > is too much code which cases StopIteration *without* performing such a > check. > > If those two points are accepted as valid, then that leaves the two > options as being: > > 1. Add a new GeneratorReturn exception that will escape from existing > code that only traps StopIteration. The only real downside of this is > that either "return" and "return None" will mean different things in > generators (unlike functions) or else "return None" will need to be > special cased to raise StopIteration in the calling code rather than > raising GeneratorReturn(None). The latter approach is probably > preferable if this option is chosen - any code for dealing with > "generators as coroutines" is going to have to deal with the possibility > of bare returns and falling off the end of the function anyway, so the > special case really wouldn't be that special.
It seems so indeed. > 2. In addition to the "yield from" syntax for delegating to a > subgenerator, also add new syntax for returning values from > subgenerators so that the basic "return X" can continue to trigger > SyntaxError. > > Since option 2 would most likely lead to a bikeshed discussion of epic > proportions, I'm currently a fan of option 1 ;) Me too. It also seems option 2 doesn't help us decide what it should do: I still think that raising StopIteration(value) would be misleading to vanilla users of the generators. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
