On Sat, Nov 22, 2014 at 12:53:41AM +1100, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> <raymond.hettin...@gmail.com> 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 izip(iterable1, iterable2):
> > it1 = iter(iterable1)
> > it2 = iter(iterable2)
> > while True:
> > v1 = next(it1)
> > v2 = next(it2)
> > yield v1, v2
>
> Is it obvious to every user that this will consume an element from
> it1, then silently terminate if it2 no longer has any content?
"Every user"? Of course not. But it should be obvious to those who think
carefully about the specification of zip() and what is available to
implement it.
zip() can't detect that the second argument is empty except by calling
next(), which it doesn't do until after it has retrieved a value from
the first argument. If it turns out the second argument is empty, what
can it do with that first value? It can't shove it back into the
iterator. It can't return a single value, or pad it with some sentinel
value (that's what izip_longest does). Since zip() is documented as
halting on the shorter argument, it can't raise an exception. So what
other options are there apart from silently consuming the value?
Indeed that is exactly what the built-in zip does:
py> a = iter("abcdef")
py> b = iter("abc")
py> list(zip(a, b))
[('a', 'a'), ('b', 'b'), ('c', 'c')]
py> next(a)
'e'
--
Steven
_______________________________________________
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
