[PATCH] py3: catch StopIteration from next() in generatorset
Martin von Zweigbergk
martinvonz at google.com
Tue Jun 20 18:26:23 EDT 2017
On Tue, Jun 20, 2017 at 3:24 PM, Martin von Zweigbergk
<martinvonz at google.com> wrote:
> On Tue, Jun 20, 2017 at 2:53 PM, Sean Farley <sean at farley.io> wrote:
>> Martin von Zweigbergk via Mercurial-devel
>> <mercurial-devel at mercurial-scm.org> writes:
>>> # HG changeset patch
>>> # User Martin von Zweigbergk <martinvonz at google.com>
>>> # Date 1497992441 25200
>>> # Tue Jun 20 14:00:41 2017 -0700
>>> # Node ID f86d21c457209f5f5a139bcc808be33fbd930424
>>> # Parent 0906385672d754f13a512fe70759f0463a069f1e
>>> py3: catch StopIteration from next() in generatorset
>>> IIUC, letting the StopIteration through would not cause any bugs, but
>>> not doing it makes the test-py3-commands.t pass.
>>> I have also diligently gone through all uses of next() in our code
>>> base. They either:
>>> * are not called from a generator
>>> * pass a default value to next()
>>> * catch StopException
>>> * work on infinite iterators
>>> * request a fixed number of items that matches the generated number
>>> * are about batching in wireproto which I didn't quite follow
>>> I'd appreciate if Augie or someone else could take a look at the
>>> wireproto batching and convince themselves that the next(batchable)
>>> calls there will not raise a StopIteration.
>> I was just thinking of doing something like this. Shouldn't we just
>> 'return None' in Mercurial instead of 'raise StopIteration'?
> I thought "return" was just short for "return None". Are you just
> saying that we prefer "return None" in Mercurial? Should I send a v2?
Oh, never mind. You're of course talking about not using "raise
StopIteration" in general, not specifically about this patch. Yes,
that's probably true. I think there were just a few more cases of
"raise StopIteration" to deal with.
Anyway, that won't fix this case, because next() itself raise StopIteration.
More information about the Mercurial-devel