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 josh.r
Recipients cool-RR, josh.r, rhettinger, terry.reedy
Date 2014-07-03.22:02:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1404424952.06.0.0149359311256.issue20663@psf.upfronthosting.co.za>
In-reply-to
Content
+1; I've had several cases where I'd have used something like this (for the exact purpose mentioned, to destructively consume an input iterable). I don't think it's more or less useful than the sentinel version, which is convenient for iterating a file by blocks instead of by line, e.g.:

from functools import partial

with open('...', 'rb') as f:
    for block in iter(partial(f.read, 4096), b''):
        ...

But it would still nice to be able to destructively iterate sequences, particularly in CPython, where doing it at the C level can get you atomicity without relying on anything beyond the GIL (and without wrapping infinite while loops in try/except: pass blocks, which is pointlessly verbose).

One issue: You can't just make the second argument allow exception types as well, since it's possible (however unlikely) for an exception type to be a legitimate return type from a function. Making it keyword only would solve that problem though.
History
Date User Action Args
2014-07-03 22:02:32josh.rsetrecipients: + josh.r, rhettinger, terry.reedy, cool-RR
2014-07-03 22:02:32josh.rsetmessageid: <1404424952.06.0.0149359311256.issue20663@psf.upfronthosting.co.za>
2014-07-03 22:02:32josh.rlinkissue20663 messages
2014-07-03 22:02:31josh.rcreate