On Wed, Oct 14, 2015 at 3:49 AM, Random832 <random...@fastmail.com> wrote: > My theory is that most circumstances under which this would cause a > RuntimeError are indicative of a bug in the algorithm consuming the > iterator (for example, an algorithm that hasn't considered iterators and > expects to be passed an iterable it can iterate from the top more than > once), rather than the current behavior being relied on to produce > the intended end result. > > This is essentially the same argument as PEP 479 - except there it was > at least *easy* to come up with code which would rely on the old > behavior to produce the intended end result.
Yeah. Hence my suggestion of a quick little replacement for the iter() function (though, on second reading of the code, I realise that I forgot about the two-arg form; changing 'thing' to '*args' should fix that though) as a means of locating the actual cases where that happens. Hmm. Actually, this kinda breaks if you call it multiple times. Calling iter() on an iterator should return itself, not a wrapper around self. So, new version: class iter: _orig_iter = iter def __new__(cls, *args): if len(args)==1 and isinstance(args[0], cls): # It's already a wrapped iterator. Return it as-is. return args[0] return super().__new__(cls) def __init__(self, *args): if hasattr(self, "iter"): return # Don't rewrap self.iter = self._orig_iter(*args) self.exhausted = False def __iter__(self): return self def __next__(self): if self.exhausted: raise RuntimeError("Already exhausted") try: return next(self.iter) except StopIteration: self.exhausted = True raise I don't have any code of mine that would be broken by this implementation of iter(). Doesn't mean it isn't buggy in ways I haven't spotted, though. :) ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com