On 2020-04-22 11:08 a.m., Soni L. wrote:
On 2020-04-22 6:47 a.m., Steven D'Aprano wrote:
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> are there *any* solutions for getting partial results out of zip
with > different-length iterators of unknown origin?
No. If you want to continue getting results even when one or more of
the iterators is exhausted, `zip` is the wrong tool. Use `zip_longest`.
> >> 3. I feel like it makes intuitive sense for zip to return a
partial > >> result somehow, especially now that StopIteration and
return work > >together.
[...]
> it makes intuitive sense that there'd be some way to get the
iterator > elements silently swallowed by zip against the wishes of
the programmer.
If you use zip, it is because you want zip's behaviour, which is
explicitly documented as truncating on the shortest iterator. (Either
that or you don't pay attention to the docs.)
You can't say "its against the wishes of the programmer". Nobody is
forcing you to use zip except yourself. If you are hammering nails with
a screwdriver, that's not the screwdriver's fault.
As I said, if you want to continue collecting values even after one or
more iterators are exhausted, use zip_longest.
> there isn't. so we avoid it because it's useless for anything more
> advanced than the "you've checked the lengths beforehand" use-case.
I frequently use zip all the time with infinite iterators, or one
infinite iterator like itertools.count() and one or more finite
iterators, or more than one finite iterator, and I've never checked
their lengths ahead of time.
Your statement that zip is "useless" unless you have checked the
lengths first is simply nonsense.
I have, more than once, had a desire to use zip to partially consume
an iterator from a set of iterators, and then pass the rest onto
something else. it'd fit in with that.
it's a small quality of life improvement that'd make zip even more
useful than it is today, and I'm pretty sure it can't break anything
because zip (as is documented) already puts None in the StopIteration.
(whether the implementation follows that is another story, I haven't
checked, but that'd be even more of a reason to change this.) not sure
why so much pushback from you.
I'm gonna try to use zip_longest for my thing, but I don't see that
stopping me from pushing for this "return tuple(result)" change.
especially considering (as I just checked) that the CPython
implementation of zip() doesn't agree with the documentation.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5ATC4APJ6IBHBXT6FBJZMDNSSCMZJOCK/
Code of Conduct: http://python.org/psf/codeofconduct/
