> On Nov 21, 2014, at 11:31 AM, Ethan Furman <et...@stoneleaf.us> wrote: > > On 11/21/2014 05:47 AM, Raymond Hettinger wrote: >> >> Also, the proposal breaks a reasonably useful pattern of calling >> next(subiterator) >> inside a generator and letting the generator terminate when the data stream >> ends. >> >> Here is an example that I have taught for years: >> >> def [...] >> it1 = iter(iterable1) >> it2 = iter(iterable2) >> while True: >> v1 = next(it1) >> v2 = next(it2) >> yield v1, v2 > > Stepping back a little and looking at this code, sans header, let's consider > the possible desired behaviors: > > - have an exact match-up between the two iterators, error otherwise > - stop when one is exhausted > - pad shorter one to longer one > > Two of those three possible options are going to require dealing with the > StopIteration that shouldn't escape -- is the > trade of keeping one option short and simple worth the pain caused by the > error-at-a-distance bugs caused when a > StopIteration does escape that shouldn't have? >
I don’t have an opinion on whether it’s enough of a big deal to actually change it, but I do find wrapping it with a try: except block and returning easier to understand. If you showed me the current code unless I really thought about it I wouldn't think about the fact that the next() calls can cause the generator to terminate. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ 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
