On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> I've
> recently posted my code on this list, something about a class
> LogAndCompare[1]. it's horrible. a bit of zip and it could be a bit
> nicer. but I need those partial results.
>
> [1]
>
On 04/22/2020 07:08 AM, Soni L. wrote:
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
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
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
On 22.04.20 11:19, Steven D'Aprano wrote:
On Wed, Apr 22, 2020 at 10:52:44AM +0200, Dominik Vilsmeier wrote:
You can basically use the code from this StackOverflow answer (code
attached below) to cache the last object yielded by each iterator:
https://stackoverflow.com/a/61126744
Caching the
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
On Wed, Apr 22, 2020 at 10:52:44AM +0200, Dominik Vilsmeier wrote:
> You can basically use the code from this StackOverflow answer (code
> attached below) to cache the last object yielded by each iterator:
> https://stackoverflow.com/a/61126744
Caching the result of iterators is unsafe if the
On 22.04.20 06:43, Soni L. wrote:
On 2020-04-21 7:12 p.m., Steven D'Aprano wrote:
On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote:
> 1. see the other thread (strict zip), especially the parts where
they > brought up the lack of peekable/unput iterators in the context
of > getting
22.04.20 08:11, Greg Ewing пише:
I don't this should be a guarantee, in this or any similar
situation. The only purpose for the value in a StopIteration
is to provide a return value for yield-from when the thing
being delegated to is a generator. If you're yielding from
something that's not a
On 22/04/20 3:15 am, Chris Angelico wrote:
Currently, it retains any value that was already
in it - so if the shortest iterable is a generator, then its return
value will be in the propagated StopIteration. Not sure if that's a
guarantee and therefore covered by backward compatibility.
I don't
On 2020-04-21 7:12 p.m., Steven D'Aprano wrote:
On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote:
> 1. see the other thread (strict zip), especially the parts where they
> brought up the lack of peekable/unput iterators in the context of
> getting a count out of an iterator.
I've
On Wed, Apr 22, 2020 at 8:20 AM Steven D'Aprano wrote:
>
> On Wed, Apr 22, 2020 at 01:25:14AM +1000, Chris Angelico wrote:
>
> > That'd make it show up as the exception's 'value', not in its args. If
> > indeed there's no guarantee, then I would fully support this change -
> > should be a
On Wed, Apr 22, 2020 at 01:25:14AM +1000, Chris Angelico wrote:
> That'd make it show up as the exception's 'value', not in its args. If
> indeed there's no guarantee, then I would fully support this change -
> should be a non-breaking change and could be convenient.
Convenient for what?
--
On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote:
> 1. see the other thread (strict zip), especially the parts where they
> brought up the lack of peekable/unput iterators in the context of
> getting a count out of an iterator.
I've seen it, as far as I can tell there are already good
On 2020-04-21 12:48 p.m., Serhiy Storchaka wrote:
21.04.20 17:10, Soni L. пише:
I feel like zip could return partial results:
try:
next(zip([0], []))
except StopIteration as exc:
assert StopIteration.args == (0,)
how much would this break?
Why do you need this feature?
3 reasons:
21.04.20 17:10, Soni L. пише:
I feel like zip could return partial results:
try:
next(zip([0], []))
except StopIteration as exc:
assert StopIteration.args == (0,)
how much would this break?
Why do you need this feature?
___
Python-ideas
On Wed, Apr 22, 2020 at 1:22 AM Soni L. wrote:
> looking further into it, zip() already guarantees the StopIteration isn't
> gonna preserve the original StopIteration, so this should be a non-breaking
> change:
>
> https://docs.python.org/3/library/functions.html#zip
>
I'm sorry, I'm not sure
On Wed, Apr 22, 2020 at 12:25 AM Eric V. Smith wrote:
>
> On 4/21/2020 10:14 AM, Eric V. Smith wrote:
> > On 4/21/2020 10:10 AM, Soni L. wrote:
> >> I feel like zip could return partial results:
> >>
> >> try:
> >> next(zip([0], []))
> >> except StopIteration as exc:
> >> assert
On 2020-04-21 12:01 p.m., Soni L. wrote:
On 2020-04-21 11:20 a.m., Eric V. Smith wrote:
On 4/21/2020 10:14 AM, Eric V. Smith wrote:
On 4/21/2020 10:10 AM, Soni L. wrote:
I feel like zip could return partial results:
try:
next(zip([0], []))
except StopIteration as exc:
assert
On Tue, 21 Apr 2020 at 15:25, Eric V. Smith wrote:
> > In your proposal, what would next(zip([0], [], [0])) result in?
> >
> This point still stands.
... and for an even more non-obvious case,
next(zip(itertools.cycle([0]), [], [0])) (do we just return *one*
element that's not been consumed, or
On 2020-04-21 11:20 a.m., Eric V. Smith wrote:
On 4/21/2020 10:14 AM, Eric V. Smith wrote:
On 4/21/2020 10:10 AM, Soni L. wrote:
I feel like zip could return partial results:
try:
next(zip([0], []))
except StopIteration as exc:
assert StopIteration.args == (0,)
how much would this
On 4/21/2020 10:14 AM, Eric V. Smith wrote:
On 4/21/2020 10:10 AM, Soni L. wrote:
I feel like zip could return partial results:
try:
next(zip([0], []))
except StopIteration as exc:
assert StopIteration.args == (0,)
how much would this break?
It would break a lot of code, and so it won't
Which of these would you consider correct?
try:
next(zip([0], []))
except StopIteration as exc:
assert StopIteration.args == (0,)
vs
try:
next(zip([], [0]))
except StopIteration as exc:
assert StopIteration.args == (0,)
On Tue, Apr 21, 2020 at 10:14 AM Soni L. wrote:
> I feel
On 4/21/2020 10:10 AM, Soni L. wrote:
I feel like zip could return partial results:
try:
next(zip([0], []))
except StopIteration as exc:
assert StopIteration.args == (0,)
how much would this break?
It would break a lot of code, and so it won't happen.
You can use itertools.zip_longest
24 matches
Mail list logo
