This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients Rosuav, gvanrossum, python-dev, schlamar
Date 2014-11-21.18:11:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJKzcSrN5ibKZyV95n+nDH39y1JUJ3RqA2a4XZ0UK3_SJg@mail.gmail.com>
In-reply-to <1416591886.03.0.79898423852.issue22906@psf.upfronthosting.co.za>
Content
If all examples were just using "raise StopIteration" instead of "return"
in a generator I would be very happy. Such code can be trivially fixed by
using "return" and the __future__ import will help the eventual transition.

It's sad that apparently this use of return hasn't been better advertised
-- it has existed since generators were first introduced.

On Fri, Nov 21, 2014 at 9:44 AM, Chris Angelico <report@bugs.python.org>
wrote:

>
> Chris Angelico added the comment:
>
> Yep, the question is whether any of the "raise StopIteration" lines are
> actually non-local flow control. If they're local, then it's easy:
> mechanical replacement with "return" and it becomes compatible with all
> versions (unless it has a value attached to it, as "return x" doesn't work
> in Py2). But if they're non-local, some refactoring will need to be done.
>
> In any case, my line of argument is: A generator function is not an
> iterator's __next__ method, ergo iterator protocol does not apply. Use of
> StopIteration is a hack that happens to work because of how generator
> functions are implemented (a thin wrapper around an iterator), but it's not
> part of the *concept* of a generator function.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22906>
> _______________________________________
>
History
Date User Action Args
2014-11-21 18:11:13gvanrossumsetrecipients: + gvanrossum, python-dev, schlamar, Rosuav
2014-11-21 18:11:13gvanrossumlinkissue22906 messages
2014-11-21 18:11:13gvanrossumcreate