On 2020-05-01 4:43 p.m., Chris Angelico wrote:
> On Sat, May 2, 2020 at 5:21 AM Soni L. <fakedme+py@gmail.com> wrote:
> >
> >
> >
> > On 2020-05-01 3:41 p.m., Chris Angelico wrote:
> > > On Sat, May 2, 2020 at 4:38 AM Soni L. <fakedme+py@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > On 2020-05-01 3:10 p.m., Brandt Bucher wrote:
> > > > > I have pushed a first draft of PEP 618:
> > > > >
> > > > > https://www.python.org/dev/peps/pep-0618
> > > > >
> > > > > Please let me know what you think – I'd love to hear any *new* feedback that hasn't yet been addressed in the PEP!
> > > >
> > > > What about using an optional kwarg for a handler for mismatched lengths?
> > > > I made a post about it on the other thread and it's not addressed in the
> > > > PEP. It'd make zip capable of doing zip_shortest, zip_equal (aka
> > > > zip(strict=True)) and zip_longest, it's not stringly-typed, and it's
> > > > user-extensible. Something along the lines of zip(foo, bar, baz,
> > > > and_then=lambda consumed_items, iters: ...).
> > > >
> > >
> > > YAGNI.
> >
> > examples:
> >
> > # iterates in chunks, e.g. a very large file that wouldn't fit all in RAM
> > zip(*[iter(x)]*32, and_then=lambda res, _: (yield res))
>
> I'm honestly not sure how useful this really is in practice. Iterating
> over a file is already going to be chunked. What do you gain by
> wrapping it up in an opaque zip call?
>
> > # strict zip
> > sentinel = object()
> > def zip_eq(res, iters):
> >    if res or any(next(x, sentinel) is not sentinel for x in iters):
> >      raise ValueError
> > zip(a, b, c, and_then=zip_eq)
> > # this would ideally be zip.strict e.g. zip(a, b, c,
> > and_then=zip.strict), but w/e.
>
> So.... a messier and noisier spelling of what's already in this proposal...
>
> > # normal (shortest) zip but using an explicit function
> > def no_op(*args, **kwargs):
> >    pass
> > zip(a, b, c, and_then=no_op)
> >
>
> ... and a messier and noisier spelling of what we already have.
>
> I say again, YAGNI. Give an actual use-case for the excessive
> generality of your proposal - namely, the ability to provide a custom
> function. And show that it's better with zip than just with a custom
> generator function.

we can finally push for the no_op function, for starters. but the main
benefit is, again, being able to get the iterated values which were
silently swallowed by zip when the iteration stopped.

also: I don't like booleans. they're not extensible, unless you consider
None. you either get it right the first time, add a new boolean argument
later, or use enum.Flag from the beginning. this callback-based API
sidesteps all these issues.

and just in case maybe zip(strict=True) should be zip(errors=True) and
we can later change it to zip(errors="replace", value=Foo) to get
zip_longest >.< (no really bools = bad please don't use them in new APIs)
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-leave@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/UAQGBSUUFSQJRE56VGTHVXAHCJHUAYTM/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/F43SYFQAK7O7TVUGLHMKIKJDESES4W25/
Code of Conduct: http://python.org/psf/codeofconduct/