On Fri, Mar 27, 2009 at 8:45 PM, P.J. Eby <p...@telecommunity.com> wrote: > At 12:53 PM 3/28/2009 +1200, Greg Ewing wrote: >> Guido van Rossum wrote: >>> Perhaps the crux is that *if* you accidentally use "return <value>" in >>> a vanilla generator expecting the value to show up somewhere, you are >>> probably enough of a newbie that debugging this will be quite hard. >>> I'd like not to have such a newbie trap lying around. >> >> Okay, so would you be happy if the for-loop were to >> raise an exception if it gets a StopIteration whose >> value is not None? > > Wouldn't it have to be more than just for-loops? What about list(), map(), > ...? > > It seems a lot simpler to just make it use a different exception, as nothing > else has to change for that to work correctly; the new construct can just > catch it, and everywhere else it's an error.
Exactly. Making StopIteration() with a non-None value invalid is not backwards compatible. The new exception could either be a designated (built-in) subclass of StopIteration, or not; I haven't thought enough about which choice would be more useful or easier. I think in either case a check in PyIter_Next() would cover most cases -- though there are probable a few other places in the interpreter where tp_next is called that should also have this check added. -- --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
